▲ 257 points
back
108 comments
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...
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.
The original Space Jam website had some great image maps, e.g.
https://www.spacejam.com/1996/cmp/souvenirs/souvenirsframes....
I laughed (affectionately) when I saw image maps. That was a real 1997 moment.
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.
Honestly, once I learned about client-side image maps, I don't think I ever even thought to touch the form-based ones ever again.
They still are, check out amazon dot com
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.
> 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.
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>?
> 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>
Until it's easier to add bloated animations to details/summary the designers will never let us use em
Here's one very few people know:
<wbr/>
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.
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...
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).
<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.
So I automatically converts all m<sup>2</sup> and similar into the unicode symbols: https://en.wikipedia.org/wiki/Unicode_subscripts_and_supersc...
<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
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.
> 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?
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.
There's a certain irony to me that this discussion of cool html elements is all embedded as images
My favorite obscure useful HTML elements: <var>, <wbr>, <time>, <dl>/<dt>/<dd>, <thead>/<tbody>/<tfoot>/<th>.
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.
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).
<marquee>remember this tag?</marquee>
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.
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.
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.
"7 Cool HTML Elements Nobody Uses"
=> "7 Cool HTML Elements [the author] Never Uses"
`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!).
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).
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.
1997 called, they want their cool elements back.
Oh hey I know the 4th one! I use <details> and <summary> all the time for gitlab tag comments and releases!
You can add these to your list of esoteric tech questions to ask during interviews. /s
<details> is great, but somewhat difficult to style.
`<blink>` tag!
+ Marquee
for image divs that websites keep using JS for.
Abbreviations seems actually useful!
sub doesn't seem to work in Android Chrome
<marquee>