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.
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.
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.
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.
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.
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.
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.
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>?
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.
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.
<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).
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!
<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 m² grass" then that line is taller than all the other lines, which makes it rather ugly.
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.
> <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 m² 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.
> 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.)
<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].
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.
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/
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.
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.
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
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.
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).
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.
[+] [-] donatj|3 years ago|reply
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...
[+] [-] sebazzz|3 years ago|reply
[+] [-] inasmuch|3 years ago|reply
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
[+] [-] psyklic|3 years ago|reply
https://www.spacejam.com/1996/cmp/souvenirs/souvenirsframes....
[+] [-] flkiwi|3 years ago|reply
[+] [-] dopidopHN|3 years ago|reply
Half of it was outputted by dreamweaver 3.0 but it needed a lot of manual touch up.
[+] [-] ttfkam|3 years ago|reply
[+] [-] cantSpellSober|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] franga2000|3 years ago|reply
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|3 years ago|reply
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.
[+] [-] commandlinefan|3 years ago|reply
[+] [-] clairity|3 years ago|reply
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.
[+] [-] sebazzz|3 years ago|reply
Also applies to progress, for which you need to use obscure browser-specific CSS rules.
[+] [-] statico|3 years ago|reply
[+] [-] bawolff|3 years ago|reply
Easier now that plugins are dead and <object> is basically equivalent to <iframe>
[+] [-] cantSpellSober|3 years ago|reply
[+] [-] vehemenz|3 years ago|reply
[+] [-] chrismorgan|3 years ago|reply
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.
[+] [-] dynm|3 years ago|reply
[+] [-] spdustin|3 years ago|reply
[0] https://jsfiddle.net/spdustin/y4m3qd71/1/
[+] [-] missblit|3 years ago|reply
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).
[+] [-] derefr|3 years ago|reply
[+] [-] silvestrov|3 years ago|reply
So I automatically converts all m<sup>2</sup> and similar into the unicode symbols: https://en.wikipedia.org/wiki/Unicode_subscripts_and_supersc...
[+] [-] WorldMaker|3 years ago|reply
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|3 years ago|reply
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...
[+] [-] derefr|3 years ago|reply
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.)
[+] [-] Kwpolska|3 years ago|reply
[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
[+] [-] somat|3 years ago|reply
https://www.w3schools.com/Tags/att_img_ismap.asp
[+] [-] meigwilym|3 years ago|reply
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?
[+] [-] superkuh|3 years ago|reply
[+] [-] koala_man|3 years ago|reply
[+] [-] timw4mail|3 years ago|reply
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.
[+] [-] swyx|3 years ago|reply
[+] [-] mNovak|3 years ago|reply
[+] [-] nayuki|3 years ago|reply
[+] [-] parminya|3 years ago|reply
[+] [-] bawolff|3 years ago|reply
Basically let your users generate rsa keys so you could use mutual tls (i.e. client side certificates) instead of passwords.
[+] [-] moralestapia|3 years ago|reply
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).
[+] [-] fowlie|3 years ago|reply
[+] [-] solarkraft|3 years ago|reply
[+] [-] rekabis|3 years ago|reply
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.
[+] [-] keeganjw|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] sbf501|3 years ago|reply
SUP and SUB I find don't work very well with glyphs, but work fine with standard Latin characters.
[+] [-] poiuyytrewq|3 years ago|reply
=> "7 Cool HTML Elements [the author] Never Uses"
[+] [-] commandlinefan|3 years ago|reply