The Most Important Thing Is to Get the HTML Right
Published on September 26, 2008 (↻ February 5, 2024), filed under Development (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.
About Me
I’m Jens (long: Jens Oliver Meiert), and I’m a frontend engineering leader and tech author/publisher. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m a contributor to several web standards, and I write and review books for O’Reilly and Frontend Dogma.
I love trying things, not only in web development (and engineering management), but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (Please be critical, interpret charitably, and give feedback.)
Comments (Closed)
-
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:
@Buzu
ⅰ 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: kroccamen@gmail.com. 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:
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).
Read More
Maybe of interest to you, too:
- Next: Web Standards at Google
- Previous: When Guidelines Should Be Descriptive or Prescriptive
- More under Development
- More from 2008
- Most popular posts
Looking for a way to comment? Comments have been disabled, unfortunately.
Get a good look at web development? Try WebGlossary.info—and The Web Development Glossary 3K. With explanations and definitions for thousands of terms of web development, web design, and related fields, building on Wikipedia as well as MDN Web Docs. Available at Apple Books, Kobo, Google Play Books, and Leanpub.