The Most Important Thing Is to Get the HTML Right
Post from September 26, 2008 (↻ December 5, 2021), filed under Web Development (feed).
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 the most 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 stuff and avoid maintenance traps. What mastering HTML does, then, is move complexity over to styling and scripting, meaning that in order to write efficient HTML, even more solid understanding and experience of CSS and DOM is required in order to achieve the presentation and behavior that are desired.
We keep in mind: Changing documents is always more expensive than changing style sheets and scripts because there are more documents and templates than style sheets and scripts. Thus, writing the best HTML possible contributes to challenges and complexity on the styling and scripting ends.
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.
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!
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: camendesign.com/code/using-abbr
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.
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: firstname.lastname@example.org. 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.
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.
On August 16, 2011, 7:38 CEST, Niels Matthijs said:
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).
Maybe this is interesting to you, too:
- Next: Web Standards at Google
- Previous: When Guidelines Should Be Descriptive or Prescriptive
- More under Web Development, or from 2008
- 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.