On Writing Better Markup
Post from October 16, 2019 (↻ June 2, 2022), filed under Web Development (feed).
As HTML is so important and yet also so easy, everyone writes HTML, and everyone says they can write HTML. And with that they don’t just mean they’re able to write HTML, but that they write good HTML, where “good” means “high quality.”
The most important one, a very good reason, is that HTML isn’t actually that easy, because it really is complex. Want an example?
HTML 5.2, which is the latest HTML recommendation over at the W3C (as opposed to the WHATWG, where HTML really is written—so normally, look at that spec), contains 111 elements alone. 111. How many do you know? How many does the average web developer know? Or the median web developer? And what does that mean for their HTML if they don’t even know all the elements?
Want another example? When people talk about HTML elements like, for example,
<p>, then most of the time they do mean elements. But what they then talk about is “tags.” Google, as of September, 2019, finds 25 million occurrences of “html tags” alone. HTML elements, what people mean, but don’t call by name? 2.4 million hits, a tenth. So this one begs the question how well developers understand HTML if they’re not sure about the difference between elements and tags.
Another one? In a few years, HTML will celebrate its 30th birthday. Very cool! So we will certainly have maxed out all options to reduce HTML payload, to improve performance? Well, no. One of the major options at our disposal to reduce HTML payload is not to write HTML that can be left out without a document turning invalid (please validate, by the way). But almost no one uses that option. Web developers have concerns, yes, but the point is that the method is so under-utilized, we cannot speak of HTML mastery here, either.
We could go on, adding data and anecdotes to how HTML is both important and yet not well-understood, nor well-used. But the route I want to take now is to take 10 examples, from the wild, to show simple improvements to the respective HTML code. That code, then, has been anonymized, for this book is not about pointing fingers, but to simply look at HTML and see what else we can do, how we can improve it, how we can: upgrade it.
The unedited initial introduction for my next (super-short) book, and book series: Upgrade Your HTML.
Oh, yes, that image there, that’s pretty much going to be the cover indeed.
I’m Jens, and I’m an engineering lead and author. I’ve worked as a technical lead for Google, I’m close to W3C and WHATWG, and I write and review books for O’Reilly. I love trying things, sometimes including philosophy, art, and adventure. Here on meiert.com I share some of my views and experiences.
If you have a question or suggestion about what I write, please leave a comment (if available) or a message. Thank you!
Maybe this is interesting to you, too:
- Next: Upgrade Your HTML (the Booklet)
- Previous: The Developer’s Fallacy of Close Collaboration With Designers
- More under Web Development, or from 2019
- Most popular posts
Looking for a way to comment? Comments have been disabled, unfortunately.
Get a good look at web development? Try The Web Development Glossary (2020). With explanations and definitions for literally thousands of terms from Web Development and related fields, building on Wikipedia as well as the MDN Web Docs. Available at Apple Books, Kobo, Google Play Books, and Leanpub.