[HN Gopher] Cool HTML elements nobody uses
___________________________________________________________________
Cool HTML elements nobody uses
Author : nateb2022
Score : 210 points
Date : 2022-10-03 15:09 UTC (7 hours ago)
(HTM) web link (tapajyoti-bose.medium.com)
(TXT) w3m dump (tapajyoti-bose.medium.com)
| eimrine wrote:
| <marquee>
| dagurp wrote:
| This and <blink> were so overused that browsers started to show
| them without any animation
| dunham wrote:
| Decades ago, I disabled blink by loading my netscape binary
| into emacs and changing the tag name. Surprisingly marquee is
| still there, you can even go into the DOM and rename your top
| level elements "marquee" and the entire page scrolls.
| sli wrote:
| Just did that to HN's <center>. Got a good chuckle out of
| it, thanks.
| theandrewbailey wrote:
| I did that (via browser inspector), then wanted to upvote
| you. It was very hard. Eventually got it!
| yamtaddle wrote:
| A couple years ago I went looking for JS marquee replacements
| and zero of them I could find would deliver the same
| functionality as <marquee>
|
| Functionality's gone, it seems. Evidently it's hard to
| replicate all of it because none of the options I could find
| managed it.
| stonogo wrote:
| You don't need javascript to replace marquee tags. There
| are a plethora of implementations using CSS animation.
| yamtaddle wrote:
| If you just want stuff to scroll, sure, but it's got a
| lot of features:
|
| https://developer.mozilla.org/en-
| US/docs/Web/HTML/Element/ma...
|
| I just know that when I went to try to make a marquee
| using some of these features a couple years ago, I
| couldn't find _anything_ pre-made that could do what I
| wanted, which was nothing more than what <marquee> could
| do, so it was going to be a lot of custom work. Which
| surprised me, I expected someone to have perfectly re-
| created the whole tag just for giggles if nothing else.
| There were _tons_ of partial solutions, but nothing that
| was a complete replacement.
| moralestapia wrote:
| _sup_ and _sub_ are quite common, I think.
|
| _map_ and _area_ was how I was taught to write websites like 20
| years ago (whew!).
|
| Thanks a lot for _meter_ and _progress_ , though! I didn't knew
| about those, they will def. save me a lot of time in the future
| (I always end up implemented my own progres bar and it's a PITA).
| silvestrov wrote:
| <sup> and <sub> has the problem that they change the line height.
| So if you have an paragraph and one line contains "Nice ground
| with 42 m2 grass" then that line is taller than all the other
| lines, which makes it rather ugly.
|
| So I automatically converts all m<sup>2</sup> and similar into
| the unicode symbols:
| https://en.wikipedia.org/wiki/Unicode_subscripts_and_supersc...
| derefr wrote:
| > So I automatically converts all m<sup>2</sup> and similar
| into the unicode symbols
|
| Nice in theory, but only works for trivial cases. Most old-
| school use of <sup> is as a quick-and-dirty pre-MathML way of
| rendering equations as (accessible) text in browsers. (The
| people who didn't care about accessibility rendered TeX to an
| image and embedded it.)
| WorldMaker wrote:
| Though it useful to point out that the Unicode superscripts and
| subscripts were also originally intended to be
| ascenders/descenders (which in the strictest sense would also
| affect line height) are as represented in most fonts instead as
| roughly "numerator/denominator" numbers instead of "proper"
| superscripts and subscripts.
|
| The W3C recommends to prefer the markup versions, and various
| years the Unicode committee has also suggested not to use the
| Unicode versions except in backwards compatibility with old ISO
| codes and in certain semantically more meaningful situations as
| "single words" (chemistry formulas more so than math, for
| instance). Though the Unicode recommendations have waffled back
| and forth over the years. Both have recommended it in part
| because of metadata available to screen-readers for
| accessibility.
|
| Not that you always have to follow such recommendations from
| groups such as these, just that it is useful to know what the
| recommendations are. Also as others pointed out, some CSS
| stylesheets are better than others at line-height of sub/sup
| markup and while the default styles are kind of awful, it is
| useful to know there are CSS options.
|
| https://en.wikipedia.org/wiki/Unicode_subscripts_and_supersc...
| flanbiscuit wrote:
| > <sup> and <sub> has the problem that they change the line
| height. So if you have an paragraph and one line contains "Nice
| ground with 42 m2 grass" then that line is taller than all the
| other lines, which makes it rather ugly.
|
| normalize.css fixed this problem by setting the line-height to
| 0 and using position relative.
|
| https://github.com/necolas/normalize.css/blob/master/normali...
| sbf501 wrote:
| MAP and AREA have been around since the 90's, but METER/PROGRESS?
| I never noticed those sneak into HTML. I've been using Bootstrap
| for ages. Cool.
|
| SUP and SUB I find don't work very well with glyphs, but work
| fine with standard Latin characters.
| nayuki wrote:
| My favorite obscure useful HTML elements: <var>, <wbr>, <time>,
| <dl>/<dt>/<dd>, <thead>/<tbody>/<tfoot>/<th>.
| parminya wrote:
| I don't think tbody is really obscure to anyone writing with
| DOM. You can't embed a tr into a table: it has to be in a
| thead/tbody/tfoot. If you're writing HTML it's fine, the
| browser does it for you. But if you're writing DOM (directly or
| indirectly with e.g. React) you need to use the tbody tag or
| else it won't do you what you wanted.
| ironmagma wrote:
| I spent hours and hours playing with <MARQUEE />, had lots of fun
| putting a marquee within a marquee. Sad that there's no mention
| of it.
| francisofascii wrote:
| You can add these to your list of esoteric tech questions to ask
| during interviews. /s
| math0ne wrote:
| Abbreviations seems actually useful!
| spdustin wrote:
| My favorite (non-conforming, do-not-use) element is <xmp>. It
| switches the browser's parsing context to "generic raw text"; it
| emits any "child" markup as-is, without parsing it.
|
| [0] https://jsfiddle.net/spdustin/y4m3qd71/1/
| derefr wrote:
| I believe you can also just write <![CDATA[whatever]]>. (See
| https://stackoverflow.com/questions/3302648/should-i-use-
| cda...). It's normally only used to wrap non-HTML content
| inside <style> and <script>; but you could put "HTML that
| should be rendered as text" in there as well!
| missblit wrote:
| Note that CData can _only_ be used what HTML calls foreign
| content.
|
| So `<math><![CDATA[x<y]]></math>` will print x<7, but
| `<p><![CDATA[x<y]]></p>` will emit a `cdata-in-html-content`
| parse error (your compliant HTML parser is allowed to give up
| here if it's lazy) and is parsed as
| `<p><!--[CDATA[x<y]]--></p>` (your HTML parser will actually
| do this because giving up leads to poor user experience when
| no one else does)
| missblit wrote:
| <plaintext> is also fun. Unlike <xmp> you can't get out of it
| with a closing tag.
|
| Aside: plaintext is one reason browser DOM is a superset of
| HTML. By which I mean you can add <plaintext> to the middle of
| your DOM through JavaScript and everything is hunky-dory, but
| it's impossible to serialize the DOM to HTML so it'll HTML-
| parse back to the same DOM (at least if the serializer doesn't
| produce any JavaScript).
| fowlie wrote:
| <marquee>remember this tag?</marquee>
| solarkraft wrote:
| <center><blink>hello!</blink></center>
| donatj wrote:
| I am old enough to remember development when image maps were
| still common for things like headers and big hero homepage
| navigation images.
|
| I'd like to add <input type="image" src="..."> which acts like an
| img tag and submit button that submits the clicked X and Y
| essentially as two separate inputs
|
| Here's an MDN example showing X and Y position in GET string on
| click.
|
| - https://mdn.github.io/learning-area/html/forms/image-type-ex...
| psyklic wrote:
| The original Space Jam website had some great image maps, e.g.
|
| https://www.spacejam.com/1996/cmp/souvenirs/souvenirsframes....
| sebazzz wrote:
| Trip down memory lane: Internet Explorer didn't quite interpret
| the standard correctly and sent the coordinates as floating
| point numbers. If you had this input[type=image] on a ASP.NET
| WebForms page, this then caused ASP.NET WebForms to crash, as
| it tried to interpret the postback arguments of the X/Y
| coordinates as integers. I think this was later fixed by
| patching Internet Explorer.
| dylan604 wrote:
| Trip down memory lane: Internet Explorer didn't quite
| interpret the standard correctly. Full stop. Anything said
| after this is just using words for vanity ;-)
| yakshaving_jgt wrote:
| This was a fun one: https://jezenthomas.com/you-think-css-
| in-js-is-bad/
| dopidopHN wrote:
| I think using image map to make several area links from the
| same image was my first actual production of code.
|
| Half of it was outputted by dreamweaver 3.0 but it needed a lot
| of manual touch up.
| inasmuch wrote:
| Image maps unlocked expression on the web for me when I was a
| kid. I enjoyed coding websites, but felt creatively limited by
| what I knew to be possible with simple HTML and CSS. When I
| realized I could turn any graphics I made into live web
| elements without having to fit adjacent pieces into a layout I
| could simulate with tables, I felt I could finally make a
| website that reflected my artistic self.
|
| I think I published the last version of my personal website
| that I made with an image map in 2004 or so. I've been trying
| to think of a good use for one over the last couple years but
| haven't come up with anything yet.
|
| The last really cool image map-based website I remember was
| Margot's Room by Emily Carroll [1]. Dunno if she coded it, but
| it's her comic.
|
| [1] http://emcarroll.com/comics/margot/index.html
| stefs wrote:
| i remember slicing images into rectangles which could be fit
| into a table. stole some portrait photograph of a woman,
| maxed out contrast, color reduction + dithering, then drew
| the eyes shut and make the open/close frames into gifs with
| different timings. the result: an image of a women who
| blinked both eyes independently, without the use of css and
| js.
|
| the outcome wasn't planned, it just happened - but it was so
| funny i still have to laugh all those years later.
| cantSpellSober wrote:
| They still are, check out amazon dot com
| flkiwi wrote:
| I laughed (affectionately) when I saw image maps. That was a
| real 1997 moment.
| poiuyytrewq wrote:
| "7 Cool HTML Elements Nobody Uses"
|
| => "7 Cool HTML Elements [the author] Never Uses"
| commandlinefan wrote:
| Actually most of these are things that people used to use in
| the 90's, but stopped using because they didn't give you as
| much control as you needed.
| croes wrote:
| sub doesn't seem to work in Android Chrome
| mNovak wrote:
| There's a certain irony to me that this discussion of cool html
| elements is all embedded as images
| bawolff wrote:
| The one im sad never caught on was (the now removed from spec)
| <keygen>
|
| Basically let your users generate rsa keys so you could use
| mutual tls (i.e. client side certificates) instead of passwords.
| somat wrote:
| I have this unhealthy aversion to javascript. so when I make a
| web application it is in a very late 90's style. For my latest
| thing, I needed to select points on an image and did I do the
| sane thing and write two lines of javascript and be done with it,
| of course not, I went with server side image maps. in 2022. sigh,
| no, I don't know what is wrong with me either.
|
| https://www.w3schools.com/Tags/att_img_ismap.asp
| AlbinoDaffy wrote:
| Oh hey I know the 4th one! I use <details> and <summary> all the
| time for gitlab tag comments and releases!
| exabrial wrote:
| `<blink>` tag!
| [deleted]
| nashashmi wrote:
| + Marquee
|
| for image divs that websites keep using JS for.
| nashashmi wrote:
| https://codepen.io/hanihsdd/pen/KKaQxdX
| koala_man wrote:
| I didn't know about datalist, but now I'll start using it. I've
| been annoyed at the multitude of completion implementations that
| all behave slightly differently.
| swyx wrote:
| i think the problem with datalist is the default styles, and
| the lack of customizability (eg if you want multiple slections,
| or to display descriptions or images next to each choice, or
| you want fuzzy matching). most of the time you'll just want to
| go ahead and import a ComboBox component someone else has made
| timw4mail wrote:
| The problem is more the inconsistent behavior. Styling is
| also a concern, but why doesn't the Option element behave the
| same in a datalist as in a select? (I think only Firefox
| actually does this properly).
| timw4mail wrote:
| Yeah, it's really odd. Some browsers will only show the value,
| some will show the label and the value, and some will
| (properly) show the label when you have both a label and a
| value.
|
| It kind of drives me nuts that it doesn't work the same way as
| the select element, when you are using option elements as a
| list.
| dynm wrote:
| It's treated as an obvious thing in this document, but I was
| surprised to learn about the <var> tag for mathematical
| expressions: https://developer.mozilla.org/en-
| US/docs/Web/HTML/Element/va...
| rekado wrote:
| `details`/`summary` and `progress` have decent default styles in
| picocss. I was under the impression that these elements were used
| much more often in "modern" HTML than, for example, `map`/`area`
| or `object` (yuck!).
| Kwpolska wrote:
| <datalist> might sound like a good idea, but it tends to be
| inconsistent between browsers [1]. It also doesn't work on
| Firefox on Android (both Focus and standard). It was also broken
| in web views on Android for 1.5 years [2].
|
| [1]: https://chriswarrick.com/blog/2020/02/09/when-html-is-not-
| en... (disclaimer: my blog post, from 2 years ago, although most
| of the issues apply today) [2]:
| https://bugs.chromium.org/p/chromium/issues/detail?id=949555
| meigwilym wrote:
| > 4. map & area
|
| These take me back, but I'm trying to remember why I stopped
| using them. Did they go out of fashion? Or was it accessibility
| related?
| jiggywiggy wrote:
| Responsive reasons. Hardly ever can you do full absolute
| positioning.
| parminya wrote:
| I think they died well before responsive became a concern.
| Their heyday was really the time before not just CSS but even
| tables, at which time they were the only way to have links
| positioned in space rather than in flowing text. I don't
| think anyone liked imagemaps - it's just that there was no
| alternative.
|
| But their limitations were massive. Chiefly, in a period when
| dialup internet was becoming more common, an image map meant
| that before a user could interact with your website, they had
| to wait for a very slow download of a very large image that
| contained mostly text. You couldn't interact with them any
| more - no ability to select the text in them, or perhaps the
| reader had a different color/font preference? Tough luck.
|
| When tables came out, they began to face competition, but
| they weren't defeated. Aside from table-first designs that
| mixed images and text, you could mostly do without imagemaps
| by cutting the image up, eliminating table
| borders/cellpadding/cellspacing and making careful use of
| colspan and rowspan, with a part of the image in each cell.
| This had most of the same user-side problems as imagemaps,
| but was easier for many people to maintain (I'm not sure
| quite why: I assume some people have trouble with thinking in
| terms of x/y coordinates and regions).
|
| CSS thoroughly destroyed them. Everything an image map could
| do, tables+CSS and eventually CSS could do better. This was
| still ages before responsive became a concern, at a time when
| webpage maintainers would assume you used an 800x600 or
| 1024x768 screen with a maximized window and just ignore
| everyone who didn't match that.
|
| Nowadays, any time an image map might look like the solution,
| the actual solution is SVG, which gives you everything an
| image map had but is moreover correct.
| superkuh wrote:
| I think they went out of style because they weren't javascript.
| But many older websites still use them to create fast loading,
| universally supported, interactive data visualizations that JS
| would still struggle to match. One of my favorites is the
| dynamic space weather visualization from Lockheed Martin Solar
| and Astrophysics Laboratory,
| https://www.lmsal.com/solarsoft/latest_events/
| RedShift1 wrote:
| What's interactive about that example?
| the_third_wave wrote:
| It'll load detailed pages based on the location of the
| image you click. It might not be interactive in the modern
| CSS-animated way but it does provide interaction with what
| would otherwise be a static image.
| Brajeshwar wrote:
| I think because it was hard to write it manually unless you use
| something like Ultradev/Dreamweaver.
| otherme123 wrote:
| I remember wasting a lot of time making one fancy map, only
| to have people complaining about "where is the link to...?"
| chrismorgan wrote:
| They're not actually that useful in practice.
|
| The era of imagemaps was one where they were raster images at a
| fixed size, and when CSS wasn't particularly good for
| interesting positioning and layout. Once you acknowledge
| viewports are extremely variable in size, there's very little
| place left for imagemaps, and so people stopped making the
| kinds of designs that could benefit from it; and once you had
| alpha channels and better CSS and cross-platform vector
| graphics, there was even less place for traditional client-side
| imagemaps.
|
| (As for server-side imagemaps, ismap, no one ever really used
| them. A few years ago I deliberately used them in order to just
| barely support JavaScript-free operation on a toy just for the
| sake of it, but they're very much a solution looking for a
| problem these days.)
|
| I haven't used an actual client-side imagemap for years; what I
| _have_ done is used SVG as a form of better imagemap, not least
| because you can actually target the areas with styles. The
| imagemap in the article is approximately equal to this:
| <svg viewBox="0 0 400 379" width="400" height="379"
| fill="none"> <image href="workplace.jpg" width="400"
| height="379"><desc>Workplace</desc></image> <a
| href="computer.html"> <title>Computer</title>
| <rect x="34" y="34" width="270" height="350"/> </a>
| <a href="phone.html"> <title>Phone</title>
| <rect x="290" y="172" width="333" height="250"/> </a>
| <a href="coffee.html"> <title>Cup of
| coffee</title> <circle cx="337" cy="300" r="44"/>
| </a> </svg>
|
| But just think, now you can add rules like `a:hover { stroke:
| blue; stroke-width: 2px; } a:focus { fill: lime }` (maybe with
| some filter or mix-blend-mode).
| irrational wrote:
| Same. I remember using this feature extensively way back when.
| But I can't remember when I stopped using it and what replaced
| it. Hmm, now that I think about it, this was in the days before
| we started using Flash. But after the Flash era we didn't go
| back to using map.
| Minor49er wrote:
| They are still in use on Bandcamp for navigation in custom
| headers
| Agentlien wrote:
| I was thinking of this just a few weeks ago! When I made my
| first webpage in school (about 20 years ago) I used a sitemap
| made out of an image with map. I was thinking back to it and
| wondering whatever happened to that element.
| vehemenz wrote:
| You can still use them, but you need JavaScript calculations to
| make sure the map still works when the image shrinks. Not a big
| deal to be honest.
| chazeon wrote:
| In terms of <sub> and <sup>, I have to rely on them to write
| equations in Markdown on GitHub due to its buggy MathJax
| implementation (or previously, lack thereof).
| keeganjw wrote:
| I was literally just thinking about how to embed a PDF in a
| webpage yesterday! Thanks for the info! Probably going to start
| using most of these.
| vehemenz wrote:
| Here's one very few people know: <wbr/>
|
| It works like a line break, but it only kicks in if the word
| needs to be broken. Very useful for email/URL formatting on
| mobile (along with ­).
| chrismorgan wrote:
| A subtlety to point out about <wbr> when comparing it to its
| textual alternative ZWSP (U+200B ZERO WIDTH SPACE): if someone
| copies the text (as _text_ --if it's copied as formatted HTML,
| anything could happen), ZWSP will remain, whereas <wbr> will
| disappear. You could exclude the ZWSP with something like
| `user-select: none`. So really, <wbr> is kinda like <word-
| break-opportunity style="user-select:none">​</word-
| break-opportunity>. My experience is that <wbr> is almost
| always what you want rather than ZWSP.
|
| There are similar but more obscure considerations with the
| difference between <br> and a textual carriage return preserved
| by `white-space: pre`. Take the document
| data:text/html,<pre>a%0Ab<br>c</pre> (containing one carriage
| return and one manual line break), and
| document.body.textContent is "a\nbc" (the <br> disappears),
| while document.body.innerText is "a\nb\nc" (<br> becomes \n).
| As for removing the line breaks from what goes on the clipboard
| (which is desirable if you're choosing visually-optimal break
| points manually), well, that's unreliable. I've only ever tried
| it on Firefox, but tricks like `user-select: none` on a line
| break of either kind don't work, netting you _two_ line breaks
| for some reason; wrapping each line in something like <span
| style="display:block"> can work.
| rekabis wrote:
| SUB/SUP, MAP/AREA, and ABBR have all been in frequent use since
| the beginning.
|
| MAP/AREA in particular was extensively used before table-based
| layouts. It was only once tables were added to HTML that
| individual images could be arranged into one large seamless-
| looking image while each piece was surrounded by its own anchor.
| Before that point, using MAP/AREA was a developer's only option.
| mattlondon wrote:
| 1997 called, they want their cool elements back.
| Sohcahtoa82 wrote:
| Yeah, why use simple HTML elements when you can use a few
| thousand lines of JavaScript instead?
| franga2000 wrote:
| Having used all of these in the past, here's why this is the
| case:
|
| 1. meter/progress - default style looks dated, styling works
| different on different browsers, the color scale options are
| confusing
|
| 2. sup/sub & 7. abbr - these are only useful for page content (as
| opposed to site design), which is usually WYSIWYG or something
| like Markdown. Many editors/parsers don't support it, at least by
| default.
|
| 4. map/area - it's absolute positioning, which is unusable for
| the variety of devices we use today
|
| 5. detail/summary - it's also more content than design and has
| basically no support in content editors, but it has been growing
| in popularity in things like GitHub READMEs where only basic
| markup is allowed.
|
| 6. object - hard to know what filetypes will be supported and
| little feedback when they aren't. It usually safer to either
| include a JS reader with your site or just download the file.
| Gormo wrote:
| > default style looks dated
|
| Browser defaults for all HTML elements look "dated". The visual
| appearance of meter, as with all elements, is adjusted via CSS.
|
| > . map/area - it's absolute positioning, which is unusable for
| the variety of devices we use today
|
| It's relative to the image dimensions, not the page/viewport.
| cantSpellSober wrote:
| Until it's easier to add bloated animations to details/summary
| the designers will never let us use em
| sebazzz wrote:
| The problem with detail/summary is that in some browsers that
| element is hard to style correctly and always turns out to be
| so limited that you ask yourself why you don't fully develop
| this functionality manually and put some aria attributes on it
| for good WCAG2.1 measure.
|
| Also applies to progress, for which you need to use obscure
| browser-specific CSS rules.
| bawolff wrote:
| > object - hard to know what filetypes will be supported and
| little feedback when they aren't.
|
| Easier now that plugins are dead and <object> is basically
| equivalent to <iframe>
| clairity wrote:
| to keep track of all of these in my personal css framework, i
| made an entry in the base stylesheet for every html element,
| even including a couple deprecated but widely supported ones (i
| also keep a list of fully deprecated elements in comments),
| though not every element gets styled beyond the default.
|
| _meter /progress_ can be styled consistently, but it's tricky
| because of the browser inconsistencies you mention. it took a
| lot of playing around with weird vendor-prefixed pseudos to get
| these looking similar across platforms.
|
| _sub /sub/abbr_ just need to be normalized first -
| normalize.css is a good reference for this. _abbr_ can be
| useful for providing short "aside" info on a word/phrase in a
| semantic way.
|
| styling _detail /summary_ is relatively easy and they're pretty
| useful for FAQs and the like. i see web designers experimenting
| with more and more these days.
|
| _map /area_, i don't use, but have seen it used on
| experimental designs to neat effect. and _object_ is as you
| said, hard to predict for styling.
|
| ps - it looks like chrome (105) will finally support mathML
| along with firefox and safari, so perhaps that will impact
| sub/sup usage in the future.
| statico wrote:
| For some reason <object> makes me anxious. Is there some memory
| of the Flash/ActionScript days, or maybe ActiveX or something,
| that causes me to frown at seeing a mention of <object>?
| derefr wrote:
| <object> is supposed to be for exposing modules from hosted
| runtimes into the host execution-context as, well, objects
| (in the OOP sense. Or the COM sense, I suppose.)
|
| The original use-case would have been something like: imagine
| you code a game physics engine in Java, and deploy it as a
| Java applet. You can embed that physics engine into a page as
| an <object> -- and then _consume_ it as a local API using
| JavaScript embedded on the same page.
|
| (And yes, this is almost certainly the real reason JavaScript
| is called "JavaScript." When it was created, it was precisely
| positioned as a glue language for consuming/driving Java-
| applet APIs!)
|
| Java-applet-based APIs (and their Windows-proprietary ActiveX
| cousins) are dead, so there's no real reason to care about
| <object> any more. As long as the browser knows how to render
| the media if you navigate directly to its URL, you can just
| use an <iframe>.
| statico wrote:
| Ah ha! It was Java applets that makes me dread seeing
| <object>/<embed> tags again. Gotta support IE, you know.
| Netscape will crash anyway.
| cantSpellSober wrote:
| Probably, <object> to me will always be "the thing SWFObject
| used for rendering a Flash container"
| commandlinefan wrote:
| 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 wrote:
| Frames 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 wrote:
| That 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 wrote:
| Having 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 wrote:
| >but not returned to frames
|
| also, CSS Flex
| thiht wrote:
| Meter, progress and details/summary are from HTML5 so
| definitely not "very old"
| bshimmin wrote:
| I 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!
___________________________________________________________________
(page generated 2022-10-03 23:02 UTC)