Chris’ Corner: HTML

Jump to Docs Navigation

I’m with Den Odell here in HTML’s Best Kept Secret: The <output> Tag. I have a real affinity for that tag, perhaps because of it’s lovely balance pairing with <input>. If you’ve got any sort of value you’re displaying that is derived from inputs, it’s the perfect tag. Not just semantically, but accessibly too.

Most have never touched it. Some don’t even know it exists.

That’s a shame, because it solves something we’ve been cobbling together with <div>s and ARIA for years: dynamic results that are announced to screen readers by default.

So imagine like two numbers inputs where you add the numbers together and show the result. Just an example meant to get you thinking about any sort of input/output scenario:

If you are working with specifically with <input type="number">, Ollie Williams has some nicely-explained and practical information in A complete guide to the HTML number input. I really dig Ollie’s binding of custom commands to the inputs.

<button commandfor="cost" command="--decrement">-</button>
<input id="cost" type="number" min="0.01" max="10" step="0.01" />
<button commandfor="cost" command="--increment">+</button>Code language: HTML, XML (xml)

Those things that look like CSS Custom Properties are custom identifiers that you can listen for in JavaScript and call you own function. They show up as event.command, and as Ollie shows:

const numberInputs = document.querySelectorAll('input[type="number"]');
numberInputs.forEach((input) => {
    input.addEventListener("command", (event) => {
        if (event.command === "--increment") {
        input.stepUp();
        } else if (event.command === "--decrement") {
        input.stepDown();
        }
    });
});Code language: JavaScript (javascript)

I guess we’re doing HTML now!

Speaking of HTML-focused APIs, Christian Heilmann has a reminder about one, if you’re like me, you didn’t even know was there despite being quite old. Abandonware of the web: do you know that there is an HTML tables API? Essentially if you have a reference to a literal <table> element in HTML you get methods you can call on it like .insertRow() (and .insertCell() if you’ve got a row). I mean, OK.

One of the great things about HTML, maybe even the very greatest, is that it’s resilient to problems. Like, you can and should produce valid HTML, but a mistake or presence of something the current browser doesn’t understand isn’t a show-stopper like it can be in other languages like JavaScript.

Patrick Brosset shows off this gnarly “complete” HTML document:

<html>
  <body marginheight=150 marginwidth=300 bgcolor=black text=white>
    <marquee>
      <b>Hello <i>HTML</b> World!</i>
    </marquee>Code language: HTML, XML (xml)

A validator isn’t going to like it, but as Patrick says: “the resulting page just loads and works fine in browsers.” Sure does.

Another element that probably doesn’t get used as much as it should is the <time> element, which is semantically appropriate for almost any sort of date/time. But maybe like Nolan Lawsons says: The <time> element should actually do something. I enjoy using it correctly, but it would be cool to incentivize it with something a little more meaty. Fair is fair though, there are screen reader implications:

Léonie Watson helpfully reports that the screen readers NVDA and Narrator actually do read out the timestamp in a human-readable format! So <time> does have an impact on accessibility (although arguably not a positive one).

I’ll end with mentioning that HTML Day is Saturday, August 8th, 2026.