The 3 Ground Rules for Writing HTML

Published on October 27, 2009 (↻ February 5, 2024), filed under Web Development (RSS feed for all categories).

This and many other posts are also available as a pretty, well-behaved ebook: On Web Development.

1. Respect Syntax and Semantics

In other words: Validate your code and use markup according to its purpose. For validation there are validators, and both syntax and semantics are explained in specifications. Many advantages spring out of respecting syntax and semantics. Most notably, avoiding a few accessibility pitfalls and being professional.

2. Don’t Use Presentational or Behavioral Markup

In other words: Avoid presentational and behavioral elements and attributes, avoid presentational and behavorial ID and class names, avoid linking off to too many style sheets and scripts, avoid screwing up file names, &c. pp. Markup changes continue to be most expensive. Separation of concerns is the only option you have to write markup that is reusable and maintainable.

3. Leave Everything Out That Is Not Absolutely Necessary

In other words: Leave everything out that is not absolutely necessary. Question everything. Just using the markup you need sounds easy but, unfortunately, it’s not. It requires experience and expertise. When questioning everything and omitting even more, look into syntactical opportunities, too (protocol-less URLs, optional tags, unquoted attribute values, &c.). Once comfortable with the techniques, welcome not only performance but also maintainability benefits.

Bonus

At the end of the day, however, web development is about finding the right balance. Implementation issues, special accessibility requirements, client pressure, more substantial understandability needs, temporary experiments, and many more things can make us choose a different approach that affects the rules above. For a professional web developer it’s crucial not to go overboard with exceptions, and to keep the rules in mind all the time.

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 meiert.com I share some of my views and experiences.

Comments (Closed)

On October 27, 2009, 23:16 CET, Neovov said:
Mmm… For me, specifications are not for a learning purpose, but for implementors. Something is missing for teaching how to use the semantics.

Your second point can be discussed, if someone try to learn HTML 4 and you tell him “don’t use because it is a presentational element” then he try to learn HTML5 and ba-zing! He’s lost with which is now semantic 😊.

You may know, but I’m not quite right with the third point.

If I’d have to summarised your points with words : 1) be coherent, 2) think future, 3) KISS
On October 27, 2009, 23:38 CET, Christian Leon Christensen said:
What do you mean by ‘avoid presentational and behavorial ID and class names’?

No [div id=menu]?
On October 28, 2009, 0:05 CET, Craig Reville said:
Spot on,

All three points valid in there own right.

First one is a must for me, I must have an as close to validating code as possible (Not always possible when using blogging streams)

Second one, I agree, I have seen some people adding fancy coding and element descriptions, that are not required, they make the file size larger.

Third one, ALWAYS keep the code simple and not over bulk it. By keeping elements simple, you are making it easier to upgrade in the future so does not require additional future coding now!!

Well presented, nice and simple….thank you

Regards

Craig
On October 28, 2009, 0:07 CET, Five Minute Argument said:
Maybe it’s just me, but ‘menu’ seems more structural than either presentational or behavioural.
On October 28, 2009, 1:01 CET, DefunktOne said:
thank you for sharing this!
On October 28, 2009, 1:11 CET, Mike said:
Great summary Jens! I completely agree. I think you should expand a bit on the importance of landing on the logical structure and then building upon it with semantic, consistent class names. I think too many developers start with bad markup and try to correct it with unnecessarily complicated CSS and JavaScript.
On October 28, 2009, 3:47 CET, Ruben S said:
In a perfect world these would all be great, but until all contemporary browsers see the same code and render the same output as a result, there will be a need to bend these rules. I’m looking specifically at a company in Redmond!

HTML5 with its more semantic tags seems to be another step in the right direction, but it seems to me we’ve still got a LONG way to go yet.
On October 28, 2009, 6:39 CET, anon said:
“In other words: Leave everything out that is not absolutely necessary. ”
- Can someone please teach that to the people who wrote the Microsoft Word “Save as HTML” bit !!!!
On October 28, 2009, 7:41 CET, Neovov said:
Well, of course the “small” tag was removed from my example…
On October 29, 2009, 10:06 CET, Jens Oliver Meiert said:
Nicolas, yet specs usually explain meaning and purpose, along with examples. And every site between specs and you is a potential error source. (Short story. 😊)

Christian, with presentational ID and class names I mean stuff like red, w1024, clear, &c.

Craig, thanks!

Five Minute Argument (and Christian again), I agree.

Ruben, things will definitely continue to be exciting, yes.

Anon, 😊

Nicolas again, small is actually a case for which you can argue it’s not presentational. Think “small print,” which usually refers to certain legal contents, and this is how HTML 5 puts it at least.
On November 4, 2009, 9:16 CET, Niels Matthijs said:
Smart and concise write-up, though I’m not quite sure about point 3.

As you already stated yourself in point 2 mark-up changes are the most expensive ones, so providing a perfectly tailored html document for a certain site will obviously hinder maintainability (design reworks etc etc), as it will almost always result in costly mark-up changes over time (you know, call the company who handled the Drupal implementation + go through a whole lot of error checking cycles). You might not actually be hinting at removing all structural elements you don’t need, but I’m quite sure many people will read it like that.

The reason why I don’t actually disagree with point 3 is based on the fact that I believe that “structural elements” like div class=”header” (in html replaced by the header element) are not “unnecessary”, even if they are not used for styling or behavior. They have a clear structural function enriching your document. I know that I’m one of the few who think like this, so point 3 could use some extra explaining if you ask me 😊
On November 5, 2009, 1:03 CET, David S said:
Best distillation of “best practices” I’ve seen on HTML. I agree completely, and I think that you’ve covered most objections people may have by including the Bonus at the end.

It is difficult to completely follow these basic rules (and there’s only 3!), but certainly you’ll make a better site if you at least keep these fundamentals in mind as you work.

Many thanks for your “validators” link–great lists you have there!
On November 9, 2009, 11:38 CET, Richard said:
As you say balance is important, and being a pragmatist I am not going to stop using CSS to control what happens when a mouse hovers over a link (which is clearly behavioural). Yes, I could do it all in JavaScript instead but so long as it works in CSS I will continue to do it that way. It’s an anomaly but to my mind a welcome one.

It’s interesting too that WCAG 2.0 doesn’t require markup to be validated (unlike WCAG 1.0 which does), it only requires the code to be well-formed, which is better from an accessibility point of view because in testing I no longer have to fail a checkpoint because of an unencoded ampersand. Of course it makes testing easier if the code does validate.
On May 10, 2010, 15:28 CEST, Webstandard-Blog said:
Most of the Webdevelopers or persons who “make HTML” have problems with think about semantic, because they don’t think about the meaning of the content. That’s the reason why I can advise your 3 basic rules to everybody before he or she starts writing HTML!
On May 13, 2010, 16:34 CEST, Justin said:
After reading the comments I have gained confidence in your “3 Basic Rules” I have recently found myself having to research various information on writing HTML. I am not great with it but it has been increasingly necessary since I own multiple sites. Owning a site and being incompetent with html can be quite stressful at times.

To be honest I am not 100% clear on this even though they are basic rules but I will be sure to use it as reference in the near future.
On June 30, 2010, 9:25 CEST, Bernhard said:
The theses are correct! I look forward to html5 and css3!
On April 7, 2011, 11:01 CEST, kokogo.de said:
I think most of the Webmasters have problems with think about semantic, because they don’t think about the meaning of the content. That’s the reason why I can advise your 3 basic rules to everybody before he or she starts writing HTML!
On March 12, 2013, 17:49 CET, vente bois said:
Hi,
It’s interesting too that WCAG 2.0 doesn’t require markup to be validated (unlike WCAG 1.0 which does), it only requires the code to be well-formed, which is better from an accessibility point of view because in testing I no longer have to fail a checkpoint because of an unencoded ampersand. Of course it makes testing easier if the code does validate.