Cool HTML elements nobody uses | Hacker News Reader

Cool HTML elements nobody uses

tapajyoti-bose.medium.com

257 pointsnateb2022108 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.

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 ;-)

This was a fun one: https://jezenthomas.com/you-think-css-in-js-is-bad/

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.

https://github.com/lojjic/PIE

As painful as IE6 and IE7 were in the late 2000s/early 2010s, they were surprisingly polyfillable (at a speed cost).

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

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.

Choose prime numbers for the duration of those gifs and they will never close at the same time :)

Think this one through.

d₁ = 3, d₂ = 5

What happens at t = 15?

That makes sense. My bad. I think with coprime numbers it works as I intended.

https://en.wikipedia.org/wiki/Coprime_integers

They still are, check out amazon dot com

I laughed (affectionately) when I saw image maps. That was a real 1997 moment.

The original Space Jam website had some great image maps, e.g.

https://www.spacejam.com/1996/cmp/souvenirs/souvenirsframes....

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.

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.

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>?

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>.

Ah ha! It was Java applets that makes me dread seeing <object>/<embed> tags again. Gotta support IE, you know. Netscape will crash anyway.

Probably, <object> to me will always be "the thing SWFObject used for rendering a Flash container"

It's not needed anymore for audio or video — they have their own tags now — and plugins are dead.

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.

>but not returned to frames

also, CSS Flex

Frames 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.

> 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

At 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.

From 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.

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).

Meter, progress and details/summary are from HTML5 so definitely not “very old”

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.)

Until it's easier to add bloated animations to details/summary the designers will never let us use em

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.

> 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.

> 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>

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 ).

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.

[0] https://jsfiddle.net/spdustin/y4m3qd71/1/

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></p>` (your HTML parser will actually do this because giving up leads to poor user experience when no one else does)

<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).

Certainly it is possible. Try document.documentElement.outerHTML. Why would it be impossible?

<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...

> 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.)

> <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.

https://github.com/necolas/normalize.css/blob/master/normali...

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...

> 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.

<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.

https://www.w3schools.com/Tags/att_img_ismap.asp

> 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?

Responsive reasons. Hardly ever can you do full absolute positioning.

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.

> 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

Back then we also had the lowsrc attribute for images, so that large image should have been preceded by a much smaller 1-bit version.

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/

What's interactive about that example?

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.

I think because it was hard to write it manually unless you use something like Ultradev/Dreamweaver.

I remember wasting a lot of time making one fancy map, only to have people complaining about "where is the link to...?"

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 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.

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.

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).

They are still in use on Bandcamp for navigation in custom headers

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.

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).

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.

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>.

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.

Fun fact: `table > tr` is actually valid HTML.

> […] followed by either zero or more tbody elements or one or more tr elements […]

— https://html.spec.whatwg.org/multipage/tables.html#the-table..., the table element, content model.

Sure, the HTML syntax will imply it (and https://html.spec.whatwg.org/multipage/syntax.html#element-r... mentions this, how in HTML syntax `table > tr` is invalid), but this means that in XML syntax <table><tr><td/></tr></table> is actually valid.

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.

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>

<center><blink>hello!</blink></center>

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"

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.

`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.

Yeah, why use simple HTML elements when you can use a few thousand lines of JavaScript instead?

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.

https://codepen.io/hanihsdd/pen/KKaQxdX

Abbreviations seems actually useful!

sub doesn't seem to work in Android Chrome

This and <blink> were so overused that browsers started to show them without any animation

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.

Just did that to HN's <center>. Got a good chuckle out of it, thanks.

I did that (via browser inspector), then wanted to upvote you. It was very hard. Eventually got it!

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.

You don't need javascript to replace marquee tags. There are a plethora of implementations using CSS animation.

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.

Reply on news.ycombinator.com