One of the running jokes and/or discussion I am sick and tired of is people belittling HTML. Yes, HTML is not a programming language. No, HTML should not just be a compilation target. Learning HTML is a solid investment and not hard to do.
I am not alone in this, Wired had a piece on HTML being a programming language and even for RAG training HTML makes a lot more sense than text.
HTML structures our content, makes it easier to index and gives us tons of accessible and easy to use interface elements. And it is straight forward to learn. The syntax is clear and the rules are only a few. And yet, nobody seems to even bother to look those up.
In last week’s Bytes newsletter there was a “spot the bug” challenge that looked like this:
<main>
<form onsubmit="handleSubmit(event)">
<fieldset>
<label for="name">Name:</label>
<input type="text" name="name" value="Tyler" />
<label for="age">Age:</label>
<input type="number" name="age" value="33" />
<button>Submit</button>
</fieldset>
<hr />
<form onsubmit="handleSubmit(event)">
<fieldset>
<label for="company">Company:</label>
<input type="text" name="company" value="ui.dev" />
<label for="employees">Employees:</label>
<input type="number" name="employees" value="33" />
<button>Submit</button>
</fieldset>
</form>
<script>
function handleSubmit(event) {
event.preventDefault();
const formData = new FormData(event.target);
alert([...formData.entries()]);
}
</script>
</main> |
<main>
<form onsubmit="handleSubmit(event)">
<fieldset>
<label for="name">Name:</label>
<input type="text" name="name" value="Tyler" />
<label for="age">Age:</label>
<input type="number" name="age" value="33" />
<button>Submit</button>
</fieldset>
<hr />
<form onsubmit="handleSubmit(event)">
<fieldset>
<label for="company">Company:</label>
<input type="text" name="company" value="ui.dev" />
<label for="employees">Employees:</label>
<input type="number" name="employees" value="33" />
<button>Submit</button>
</fieldset>
</form>
<script>
function handleSubmit(event) {
event.preventDefault();
const formData = new FormData(event.target);
alert([...formData.entries()]);
}
</script>
</main>
The bug described was that as the first form wasn’t closed, the script got the wrong content. But there is so much more in this small amount of HTML that is wrong, it made me flinch.
Fieldsets need legends
It uses fieldsets without legends – why? The idea of a fieldset is to to group form elements and give that group a name. If you omit the name, all you did was paint a hard to style border around them.
Pointless labels
It uses labels, which is a happy surprise, but fails to connect them to the right form elements. For a label to describe a form element, you need the element to connect to an ID, not a name. A name attribute is not unique, instead it clusters form elements together. So, you could have a few elements with the same name, but you need to have an ID on each to connect it to the label. When the form gets submitted, the names become form data (or URL parameters), the IDs are there for HTML parser internal use. And more. IDs are the few multi-dimensional things on the web, as they can be accessed via the browser (hash at the end of the URL), they connect HTML elements together (a link pointing to it, or a label with `for`), they are easy to use in CSS and in DOM scripting. One weird thing is that every element with an ID also becomes a global JavaScript hook on the window. This is a convenience method of browsers, not a standard though.
A great example of this is a radio group. I hardly see those in use, but they are a great way to offer a “pick one of many” interface without needing any JavaScript.
Check this Codepen to see a radio group in action.
<fieldset>
<legend>Record Label</legend>
<p><input name="recordlabel" type="radio" value="Trojan" id="company1">
<label for="company1">Trojan</label></p>
<p><input name="recordlabel" type="radio" value="Epitaph" id="company2">
<label for="company2">Epitaph</label></p>
<p><input name="recordlabel" type="radio" value="Hellcat" id="company3">
<label for="company3">Hellcat</label></p>
<!-- … -->
</fieldset> |
<fieldset>
<legend>Record Label</legend>
<p><input name="recordlabel" type="radio" value="Trojan" id="company1">
<label for="company1">Trojan</label></p>
<p><input name="recordlabel" type="radio" value="Epitaph" id="company2">
<label for="company2">Epitaph</label></p>
<p><input name="recordlabel" type="radio" value="Hellcat" id="company3">
<label for="company3">Hellcat</label></p>
<!-- … -->
</fieldset>
Notice that the name of the `ID` can be random, but needs to be unique, whereas the `name` makes sense to be human readable. This is even part of the spec :
Identifiers are opaque strings. Particular meanings should not be derived from the value of the id attribute.
As an extra, activate the `Toggle checkbox/radio` button to see that simply by changing the `type` attribute of an HTML input, you can allow users to either submit one or several values. By using properly connected labels, we also allow users to click/tap/hit space on the whole text to select instead of having to hit the small radio control.
HTML was and is fun!
HTML is – dare I say it – fun to me. The reason is that I started a long time ago. Building my first web site instead of creating things with Visual Basic or C builder was amazing. HTML appeared to me all powerful. I didn’t have to spend any money, install and understand a development environment. All it needed was an index.html file and writing the code using a text editor that came with the OS. I went to htmlhelp.com and downloaded the HTML spec as a zip and put it on a floppy to look things up. I was only online at work, my home internet connection came a lot later.
Unforgiving browsers
In the early days, making HTML mistakes was a problem as browsers would punish you for it. Netscape would not render tables that weren’t closed. And back then tables was the only way to create complex layouts. This was a bad use of HTML as it was non-semantic, but we had nothing else.
Later, when CSS became a thing there was still a lot of interference of HTML in the final product. Whitespace should not make a difference in HTML but it caused a lot of extra space in table cells and with images. The best advice I would give to designers back then that banged their head on the desk was to validate their HTML. The HTML Validator became my power tool to fixing issues for clients.
These days, HTML gathers less interest as with the HTML5 parser, things became a lot more lenient.
A lack of HTML interest and respect
As browsers bend over backwards to fix broken HTML, developers stopped caring about it. If it doesn’t break the build, it’s less important than getting those JavaScript packages bundled. But this, to me, is lazy development. Why rely on a platform to fix bugs that we could avoid if we put in a tiny bit of effort?
HTML has some exciting new features for us in 2025. A single element could replace a whole component library. Sure, the component might give us more predictable styling and more control. But it also is one more dependency, and could be a security, performance and maintenance issue. An issue we can’t fix as we don’t control it.
No matter how you create things for the web, the end product will be HTML. Either HTML generated on the server or with JavaScript. With AI search bots not rendering JavaScript yet maybe this is a good time to re-learn what HTML can do for you. It has not let me down in over 25 years, whereas lots of other “magical solutions” did.
