The Most Important Thing Is to Get the HTML Right

Published on September 26, 2008 (↻ February 5, 2024), filed under (RSS feed for all categories).

This and many other posts are also available as a pretty, well-behaved ebook: On Web Development. And speaking of which, here’s a short treatise just about managing the quality of websites: The Little Book of Website Quality Control (updated).

…meaning completely right when it comes to high quality web development.

Why? Because it’s the markup that makes for most of the code of a site and is hence key to cost efficiency and maintainability; because it carries meaning and is important for accessibility; because it often has an impact on performance; and because it is, with decent content, the prerequisite for online success.

What does that mean? While HTML syntax and semantics are not too hard, writing good HTML requires robust knowledge and experience to leave out irrelevant (optional) code and avoid maintenance traps. What mastering HTML does, then, is move complexity to styling and scripting, meaning that in order to write efficient HTML, even more solid understanding and experience of CSS and the DOM are required in order to achieve the presentation and behavior desired.

We need to keep in mind: Changing documents is more expensive than changing style sheets and scripts, because there are more documents and templates than style sheets and scripts. Writing the best possible HTML contributes to challenges and complexity on the styling and scripting ends—and that is worth it.

Regardless of whether you were aware, I had to stress this in more than one place. There are then other posts that explain HTML best practices in more detail, including the collection of popular posts on this site.

Was this useful or interesting? Share (toot) this post, or maybe treat me to a coffee. Thanks!

About Me

Jens Oliver Meiert, on September 30, 2021.

I’m Jens, and I’m an engineering lead and author. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m close to W3C and WHATWG, and I write and review books for O’Reilly and Frontend Dogma.

With my current move to Spain, I’m open to a new remote frontend leadership position. Feel free to review and refer my CV or LinkedIn profile.

I love trying things, not only in web development, but also in other areas like philosophy. Here on I share some of my views and experiences.

Comments (Closed)

  1. On September 28, 2008, 16:08 CEST, Kroc Camen said:

    I was finishing up an article very much about quality HTML when you posted this - so for the benefit of readers interested in the semantics of the abbr element, here’s my guide:

  2. On November 5, 2008, 22:36 CET, Buzu said:

    Kroc Camen, I read your article, and since there is no comments section, I’m forced to comment trough here. There are a couple of thinks that I disagree with. First, an acronym and an abbreviation are two completely different things, and there is an acronym element to describe acronyms. Abbreviations are not used to describe how something should be read.

    The example in which you use php is not a citation, it is an acronym. I think you should consider reviewing your article. Not everything is wrong, but some important points are. Just as Jens points out in this article, “While learning HTML is not that hard, writing good HTML requires robust knowledge and experience”. BTW, this is an example of a citation, and “BTW” is an example of an acronym.

  3. On November 7, 2008, 14:43 CET, Kroc Camen said:


    ⅰ You are not forced to comment here, you can easily email me, my email address is available throughout my site, and in case you were unable to find it: What you meant, I presume, is that you wanted to publicly comment—blogs can be had for free anywhere, which I note, you have one.

    ⅱ The acronym element was removed in HTML5. I only write HTML5 now. I am fully aware of the differences between abbreviations and acronyms.

    ⅲ The New Oxford American English Dictionary defines an abbreviation as “a shortened form of a word or phrase.”, which makes my article correct, given the markup.

  4. On April 28, 2011, 18:57 CEST, Heather said:

    Wow, you are so right. Thanks for posting this! I completely agree about needing to get the HTML right from the start.

  5. On August 16, 2011, 7:38 CEST, Niels Matthijs said:

    Hear hear!

    I’m working for a company that does no back-end implementations. That means we prepare the html code (in static templates), then ship those to one of our partners who implement this html. Changing html code later on comes at a pretty high cost. As for scripting or css, we can just start over from scratch, send two or three files when we’re done and ask them to override the existing files.

    The tricky part of this post is defining “good html” though, that all depends on your own priorities (size/performance, future flexibility, accessibility).