4 ms·
That was my first thought... if people don't use these very old elements any more, there's probably a good Chesterson's fence-type reason. Frames seemed really
by commandlinefan 4y ago
That was my first thought... if people don't use these very old elements any more, there's probably a good Chesterson's fence-type reason. Frames seemed really cool when I first saw them too, until I actually started trying to support them.
- dylan604 4y agoFrames died when AJAX became available. People were bastardizing frames so that they could change the content in a window without refershing the entire window.
- dspillett 4y agoThat was largely iframes, though they are still in use for some things like certain methods of ad delivery. frames/framesets were often about partial updates, but mostly where script wasn't wanted so AJAX (once available) wasn't an option either.
- WorldMaker 4y agoHaving lived through that era, Frames (and Framesets) were mostly killed by the proliferation of PHP on cheap hosts. A lot of Frames were used for building navigation elements without a lot of copy/pasting between HTML files (headers, footers, navigation bars, etc). The alternative to frames was either copy/pasting or ancient early static site generators. When PHP became common and cheap most people moved to server-side inclusions. These days we've come full circle back around to static sites but not returned to frames simply by how much static site generators have either become more common and/or easier/better to use.
- dylan604 4y ago>but not returned to frames also, CSS Flex
- iostream25 4y agoFrames made a side or top nav clearly separated from the content in the middle. Framesets were super useful, in that regard, in the era of dialup.
- perilunar 4y ago> When PHP became common and cheap most people moved to server-side inclusions. You don't (and didn't) need PHP for server-side includes. Apache has had them forever. A lot of cheap hosting is LAMP stack, so has PHP available, but you don't need to use it to get SSI. https://httpd.apache.org/docs/current/howto/ssi.html https://httpd.apache.org/docs/current/howto/ssi.html
- p_l 4y agoAt least from my experience it was easier to get PHP than SSI - often if you were getting SSI, it was in conjunction with basic PHP support. Mind you, I'm talking about cheapest hosting possible, where 20 MB was a "step up" option.
- dspillett 4y agoFrom my experience SSI was not enabled on many hosts. If it was you usually had CGI or PHP too. Or maybe even mod_perl. SSI was commonly enabled on university web servers IIRC, but not commercial hosts.
- WorldMaker 4y agoI did use SSI some. My impression at the time was that cheap hosts that rolled out Apache services and had SSI enabled also generally had PHP enabled and PHP was the "better" choice at that point because it was both more powerful and more portable given Apache's SSI was unique to it and not supported by other hosts (then or now).
- thiht 4y agoMeter, progress and details/summary are from HTML5 so definitely not “very old”
- bshimmin 4y agoI only bothered to check `details`, but that one dates back to at least the 2008 working draft of the HTML5 spec, which makes it ~14 years old - not absolutely ancient, but far from recent!
- chrismorgan 4y agoBut IE and EdgeHTML-based Edge never supported <details>, so you had to polyfill it somewhat imperfectly. So one of the major browsers only gained support for it in 2020. This was a significant dissuader, especially when you consider how you can’t transition the height (very often desirable) without added JavaScript. So <details> has really only been seeing much use in the last few years. (The minimum possible polyfill is just under 750 bytes, supporting IE9+/Edge, requiring <summary> to be provided, and disallowing text children of <details>. The typical polyfill was more like 2–3KB.)