HTML is fun to think about. The old classic battle of “HTML is a programming language” has surfaced in the pages of none other than WIRED magazine. I love this argument, not even for it’s merit, but for the absolutely certainty that you will get people coming out of the woodwork to tell you that HTML, is not, in fact, a programming language. Each of them will have their own exotic and deeply personal reasons why. I honestly don’t even care or believe their to be any truth to be found in the debate, but I find it fascinating as a social experiment. It’s like cracking an IE 6 “joke” at a conference. You will get laughs.

I wrote a guest blog post Relatively New Things You Should Know about HTML Heading Into 2025 at the start of the year here which had me thinking about it anyway. So here’s more!

You know there are those mailto: “protocol” style links you can use, like:

<a href="mailto:chriscoyier@gmail.com">Email Chris</a>

And they work fine. Or… mostly fine. They work if there is an email client registered on the device. That’s generally the case, but it’s not 100%. And there are more much more esoteric ones, as Brian Kardell writes:

Over 30% of websites include at least one mailto: link. Almost as many sites include a tel: link. There’s plenty of webcal: and fax:. geo: is used on over 20,300 sites. sms: is used on 42,600+ websites.

A tel: link on my Mac tries to open FaceTime. What does it do on a computer with no calling capability at all, like my daughter’s Fire tablet thingy? Nothing, probably. Just like clicking on a skype: link on my computer here, which doesn’t have Skype installed does: nothing. A semantic HTML link element that looks and clicks like any other link that does nothing is, well, it’s not good. Brian spells out a situation where it’s extra not good, where a link could say like “Call Pizza Parlor” with the actual phone number buried behind the scenes in HTML, whereas if it was just a phone number, mobile browser that support it would automatically turn it into a clickable link, which is surely better.

Every once in a while I get excited about the prospect of writing HTML email with just regular ol’ semantic HTML that you’d write anywhere else. And to be fair: some people absolutely do that and it’s interesting to follow those developments.

The last time I tried to get away with “no tables”, the #1 thing that stops me is that you can’t get a reasonable width and centered layout without them in old Outlook. Oh well, that’s the job sometimes.

Ambiguity. That’s one thing that there is plenty of in HTML and I suspect people’s different brains handle it quite differently. Some people try something and it if works they are pleased with that and move on. “Works” being a bit subjective of course, since works on the exact browser you’re using at the time as a developer isn’t necessarily reflective of all users. Some people absolutely fret over the correct usage of HTML in all sorts of situations. That’s my kinda people.

In Stephanie Eckles’ A Call for Consensus on HTML Semantics she lists all sorts of these ambiguities, honing in on particularly tricky ones where there are certainly multiple ways to approach it.

Should testimonials be in a figure or a blockquote or… both? (Honestly, when the heck should we even use figure or blockquote in general… does anyone really know? 😅)

While I’m OK with the freedom and some degree of ambiguity, I like to sweat the semantics and kinda do wish there were just emphatically right answers sometimes.

Wanna know why hitting an exact markup pattern matters sometimes? Aside from good accessibility and potentially some SEO concern, sometimes you get good bonus behavior. Simon Willison blogged about Footnotes that work in RSS readers, which is one such situation, building on some thoughts and light research I had done. This is pretty niche, but if you do footnotes just exactly so you’ll get very nice hover behavior in NetNewsWire for footnotes, which happens to be an RSS reader that I like.

They talk about paving the cowpaths in web standards. Meaning standardizing ideas when it’s obvious authors are doing it a bunch. I, for one, have certainly seen “spoilers” implemented quite a bit in different ways. Tracy Durnell wonders if we should just add it to HTML directly.