The 3 Basic Rules for Writing HTML

Jens Meiert, October 27, 2009 / November 6, 2009.

This entry is filed under Web Development.

1. Respect syntax and semantics

In other words: Validate your code and use markup according to its purposes. 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, etc. 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 really need sounds easy, but unfortunately it’s not. It’s about this expertise thing. When questioning everything and omitting even more, look into syntactical opportunities too (protocol-less URIs, optional tags, unquoted attribute values, etc.). Once comfortable with the mindset around the techniques, welcome not just performance but also maintainability benefits.

Bonus

At the end of the day though, 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 you choose a different approach that impacts the rules above. For a professional web developer it’s crucial not to go overboard with such exceptions, and to keep the rules in mind all the time.

This post is also available in German.

Enjoy the most popular posts, probably including:

Comments

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 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, etc.

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 - Accessible Web 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.

Jens Meiert