1. Strict Doctype
Doesn’t matter which, HTML or XHTML, but use a strict doctype. There’s no need for Transitional DOCTYPES anymore as explained in Choosing the Best Doctype for your Website.
Transitional
Transitional was intended as a stepping stone to help web designers begin to improve their code. The starting point: horrible, invalid code. The end point: horrible, valid code. You can’t expect designers to completely change their coding methods overnight; nor can you expect browser CSS support to go from nearly non-existent to perfect. One step at a time.
Nowadays, browser support for CSS is much better. The only reason for using Transitional is that you’re stuck in old habits and don’t yet have time to learn better ways of coding. If you’re learning web design from scratch, use Strict. Please, oh please use Strict.
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> ..... <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
The short answer is: you should use Strict.
Strict is harder for beginners to get right, because you have to write better code. For example, you must remove presentational elements such as
tags, and use CSS instead to style the site. If you’re happy doing this, then you can skip the rest of this section: you’ve already made the right decision. If you’re still uncertain, read on.To understand the differences, we need to go back to the Bad Old Days, in the 1990’s, when web designers were writing horrible, bloated code, hardly anyone had heard about validation, and fewer cared. Browser support for CSS was rubbish, and the web standards movement was in its infancy.
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> ..... <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
2. Indent your markup
Indentation will not render your pages faster or make sure your site is #1 in Google, but it will help you with one thing: readability. When you have 2000 lines of HTML code, it’s very easy to get lost when it’s not indented properly or lose track of an un-closed div.
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html lang="en-US">
<head>
<title>Simple Designs :: A web design portfolio by Karinne Legault</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</meta></head>
<body>
<div id="branding">
<h1>Simple Designs</h1>
<h2>A web design portfolio by Karinne Legault</h2>
</div>
<div id="navigation">
<ul>
<li><a href="/">Home</a></li>
<li><a href="/company/about">About</a></li>
<li><a href="/services/">Services</a></li>
<li><a href="/portfolio/">Portfolio</a></li>
<li><a href="/contact/">Contact</a></li>
</ul>
</div>
Indenting should be an automaton when coding; when you change line, hit tab and off you go.
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html lang="en-US">
<head>
<title>Simple Designs :: A web design portfolio by Karinne Legault</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</meta></head>
<body>
<div id="branding">
<h1>Simple Designs</h1>
<h2>A web design portfolio by Karinne Legault</h2>
</div>
<div id="navigation">
<ul>
<li><a href="/">Home</a></li>
<li><a href="/company/about">About</a></li>
<li><a href="/services/">Services</a></li>
<li><a href="/portfolio/">Portfolio</a></li>
<li><a href="/contact/">Contact</a></li>
</ul>
</div>
3. Comments are always important
It’s easy and it saves you a lot of time when looking for a specific area in your code. No need to comment the little things but the big areas like header, navigation, content, posts, etc… the ones you’ll most likely be going back to quite often. Here’s how I like to do mine.
< !DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html lang="en-US">
<head>
<title>Simple Designs :: A web design portfolio by Karinne Legault</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</meta></head>
<body>
<!-- branding -->
<div id="branding">
<h1>Simple Designs</h1>
<h2>A web design portfolio by Karinne Legault</h2>
</div>
<!-- END OF branding -->
<!-- navigation -->
<div id="navigation">
<ul>
<li><a href="/">Home</a></li>
<li><a href="/company/about">About</a></li>
<li><a href="/services/">Services</a></li>
<li><a href="/portfolio/">Portfolio</a></li>
<li><a href="/contact/">Contact</a></li>
</ul>
</div>
<!-- END OF navigation -->
4. User the proper element for the job
When coming to grips with CSS, it’s easy to forget that numerous HTML elements exist with a pre-defined set of default CSS styles. The most common of these are the headings (i.e.
–
). Many new designers learning the ways of CSS often forget about these and start creating their own headings.
heading3 {
color: #c44d58;
font-size: 18px;
font-weight: bold;
margin: 5px 0 8px 0;
padding: 2px 0 4px 0;
}
<div class="heading3">Latest additions to the portfolio</div>
heading3 {
color: #c44d58;
font-size: 18px;
font-weight: bold;
margin: 5px 0 8px 0;
padding: 2px 0 4px 0;
}
<div class="heading3">Latest additions to the portfolio</div>
They exist, they are already bold and big and yes, they are GREAT for SEO purposes (search engine optimization).
h3 {
color: #c44d58;
font-size: 18px;
}
<h3>Latest additions to the portfolio</h3>
5. Tables aren’t bad
When used to display data that is. Do not confused the “Don’t use tables for your layout” to “Don’t use the table element at all” as many people seem to be doing.
From the W3C – 11 Tables
The HTML table model allows authors to arrange data — text, preformatted text, images, links, forms, form fields, other tables, etc. — into rows and columns of cells.
…
Tables should not be used purely as a means to layout document content as this may present problems when rendering to non-visual media. Additionally, when used with graphics, these tables may force users to scroll horizontally to view a table designed on a system with a larger display. To minimize these problems, authors should use style sheets to control layout rather than tables.
6. Nesting tags
Beside the obvious nesting show here:
<strong><em>Latest additions to the portfolio</em></strong>
We must also be careful of not nesting block elements inside inline elements. Tho most browsers will handle it fine, it’s semantically incorrect.
<a href="/portfolio/"><div>Latest additions to the portfolio</div></a>
Anchors are inline elements while div’s are block elements.
<div><a href="/portfolio/">Latest additions to the portfolio</a></div>
7. Validation
Validation should always be on your list of “things to do before launching” a website. Validating your site doesn’t mean that it will make it work automagically in all browser. Instead, think of the validating services as spell checkers and nothing more.
<h3>Portfolio <p>Check out my portfolio and if you like what you see, do not hesitate to <a href="/contact/">contact me.<p>
3 simple errors that, in a page of 500 lines of code can be easily missed! Let the HTML and CSS validators help you… that’s what they’re there for! For more on this, check out How important is HTML and CSS validation?
8. Keeping things separated
Make sure that your CSS and JS are separated from your mark-up. Just like PHP (or ASP) includes are great to separate sections that are common throughout your site, so is CSS and Javascript. Keeping them separate means that if you need to change the color of your text, you can do it in one place, your external stylesheet, instead of all your HTML files … a task that could be daunting if you have more than 50+ files.
<script type="text/javascript" src="/js/some-javascript-file.js"'></script> <link rel="stylesheet" href="/css/styles.css" type="text/css" media="screen" />
Great tips! Especially when you’re collaborating with someone else. Keeps it nice and clean.
@Mark – Totally agree. So much easier to find yourself in code when it’s nicely commented or indented.
@Pliggs – Like anything, it takes a while before you stop thinking about it and just “do it”. Most editors will do “some” indenting for you tho.
I learned to code by reverse engineering and reading the code of others–and had they not properly commented or tabbed their work, I would have had a MUCH tougher time understanding what was happening.
In a collaborative environment those two things are critical.
Thanks for the article.
Great tips!
Do you think that commenting a section as branding is important if you have good semantic id’s and classes? Commenting that something is the branding section, while identifying it as branding seems redundant to me.
Again, great article…thanks for posting!
Thank you so much for the tips! I guess one of the most important ones will be using proper indenting/tabbing to indicate the level of hierarchy. A few years back when I was still new to HTML, I didn’t know the importance of indenting and thought they are an utter waste of space, until I was frequently bothered by errors that shouldn’t happen – just because I forgot to close an open tag or etc.
Indenting helps me to keep track of the opened tags so that I will be reminded to close them later when I’m done with the section. I don’t usually use a lot of commenting in my layout, but I do add comments when an important tag is closed, such as <!– END header –> or etc. It’s not only useful for me when I check through my code and to pinpoint errors, but also to help visitors who are looking through the code.
Not to mention the using of proper elements. I’m not going to hop on the H1 header debate, but then again, using proper headers is just as important. I’ve seen people who’ve stuck to using spans and divs to style their titles, and for those who were wise enough to use H1, H2 and etc, fail to understand the semantics behind their names. Using proper headers allows search engines to index your site with greater ease and to keep things in order when your stylesheet was zapped (or when people chose to print in plain text).
Thanks again for this excellent article!
I’m guilty of not using strict doctype. But a helpful tip when I write code is to write the opening and closing tags at the same time and then to go back and fill it with content.
Developers always appreciate it when they can understand your code.
Hmmm, I disagree on the comments. Doesn’t make my job easier. You simply must understand, that something like this is ridiculous:
comment: navigation
code: id=”navigation”
What you need the comment for?
Great list! These should all be a part of your coding regimen. Learned these when I started out by making a conscious decision to execute them whenever possible. I say whenever because many of the WordPress themes out there are written in Transitional. I don’t use the themes for their visuals but rather for the features built into them that I don’t have the time to code myself. Regardless, anything I code within the site is done so as strict although the site will never validate as such. Plus you’re also subject to someone else’s idea of code (no indentions, weird indentions, no comments, etc) and I’m not going to correct an entire CMS worth of code to satisfy my OCD.
A little frustrating, but there are other far more important things in life to worry about. Thanks for the post!
Lots of good points here, but keep in mind that addition of white space (tabbed indentation) and code comments inflate overall document size, which may increase loading times and consume unnecessary bandwidth. For highly optimized sites, drop the indentation and replace comments with descriptive IDs and class names, as suggested in previous comments.
Great to see teddY in the house, btw!!
Useful article
@Patrick – Ah! That’s how I learned as well!
@JeremySkelly – I know that it might seem maybe redundant to comment a section that has a very good ID name but I just think it’s easier that way. You can quickly see where it starts. Plus in most editors where code is color-coded, the comments are in a different color so they pop right at you.
@teddY – Thank you! The amount of commenting is a matter of personal preference I believe but… it is needed. How ever much or little you put in, it just makes it easier to come back too.
@Pat Arlt – That’s a great tip … thankfully, my editor does that for me already
@Jonas – Working in a large company with hundreds of developer, commenting is a must. Sometimes you don’t get to work on the same project from start to finish. Things happen, you get an assignment somewhere else and then someone else has to come in and finish your code. Not everyone codes the same way so having comments here and there can help in the transition.
@Artboredom – No indentation OCD… I have that. Whenever I work on someone else’s code, I’m always going through and changing the indentation! A bit extreme I think! :p
Is it just me or is the source code in this article not readable in FF or Chrome? The left edge is chopped.
@Steven Black – Wow… that is really nuts! We are trying to fix this. Should be back to normal soon!
Sound advice from Karinne, as usual.
But I would like to pick you up on a detail:
You’ve confused semantics with syntax. Nesting block-level elements inside inline elements is syntactically incorrect: the validator will shout at you, because your markup is malformed. It has nothing to do with semantics (the meaning of elements).
@Jeff:
Whitespace in HTML is irrelevant in terms of performance, for two reasons. First, because components (images, css, js) have a much greater effect on load times than the document itself; and second, because activating GZIP squashes the HTML anyway.
See my Yslow article on TWS for more info.
WTF /w the code samples in FFx ?
@Dean – Sorry about that! We really don’t know what’s happening with the plugin. We hope to sort it out very soon!
Wow plug-in fail
I find that commenting like
Helps me, just because any program that does syntax highlighting makes comments different colour to code, making it easy to spot whilst just quickly scanning through a document.
Jack
@Mike Hopley: I beg to differ. Document size does affect performance. Anything that increases file size by any amount increases loading time and consumes resources. File compression is not universal, and therefore should not be assumed during optimization efforts.
Great tips. Many programmers and designers, even developers I work with simply do not understand the importance of clean semantic code. Its very frustrating.
Some great hints and tips here! A great article – thanks for sharing!