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.
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 ;-)
Ah, CSS expressions. So many memories of making IE6/7 polyfills in 2011. Without CSS expressions and behaviors, wonderful tools like CSS3PIE would never have been possible.
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.
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.
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.
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.
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.
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.
> 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.
I 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).
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!
But 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.)
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> 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>.
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!
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)
<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.
> represented in most fonts instead as roughly "numerator/denominator" numbers instead of "proper" superscripts and subscripts
My experience is that superscripts/subscripts are normally on a different line to numerators/denominators. A couple of very simple examples to test this: ¹½₂ ({superscript one}{vulgar fraction one half}{subscript two}), ²2⁄1₁ ({superscript two}{digit two}{fraction slash}{digit one}{subscript one}).
HN's font choice of Verdana, at least on Windows, shows all of those numbers lining up in your sample. The only noticeable difference is that the "1" in the "vulgar fraction one half" in this font has dropped the bottom "base" serif of the one.
> <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/
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.
I said dynamic, not interactive. The image and the image map are updated every few minutes. Within the image map there are links to external space weather resources you can click. These are updated in real time as they become available. The image is dynamic with time as are the links to the resources within and they're all displayed in a single unified time plot that loads instantly and displays on everything back to the 90s.
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:
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).
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.
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.
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.
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
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).
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.
I believe XHTML compatibility is the reason for this. But I have no real idea quite why XHTML 1.0 decided to allow (tbody+|tr+) (basically a mixture of HTML 3.2 and HTML 4) rather than tbody+ like HTML 4.
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.
`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).
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.
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.
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...