20 HTML Best Practices You Should Follow

20 XHTML Best Practices for Beginners

Most of the web pages you encounter is presented to you via HTML, the world wide web’s markup language. In this article, I will share with you 20 best practices that will lead to clean and correct markup.

1. Always Declare a Doctype

The doctype declaration should be the first thing in your HTML documents. The doctype declaration tells the browser about the XHTML standards you will be using and helps it read and render your markup correctly.

I would recommend using the XHTML 1.0 strict doctype. Some developers consider it a tough choice because this particular standard is less forgiving than loose or transitional doctype declarations, but it also ensures that your code abides strictly by the latest standards.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "">

2. Use Meaningful Title Tags

The <title> tag helps make a web page more meaningful and search-engine friendly. For example, the text inside the <title> tag appears in Google’s search engine results page, as well as in the user’s web browser bar and tabs.

Take for instance, the following example:

<title>Six Revisions - Web Development and Design Information</title>

The example above appears like the following image in Google’s search engine results page:

3. Use Descriptive Meta Tags

Meta tags make your web page more meaningful for user agents like search engine spiders.

Description Meta Attribute

The description meta attribute describes the basic purpose of your web page (a summary of what the web page contains). For each web page, you should place a consise and relevant summary inside the meta description tag.

For example, this description:

<meta name="description" content="Six Revisions is a blog that shares useful information about web development and design, dedicated to people who build websites." />

Shows up in Google’s search engine results page as follows:

Don’t try to spam your description with repeated words and phrases because search engines are intelligent enough to detect that. Instead, just try to be simple and straightforward in explaining the purpose of your web page.

Keywords Meta Attribute

<meta name="keywords" content="web design, web development" />

The keywords meta attribute contains a comma-separated list of key words and phrases that relate to your web page. These keywords make your web page even more meaningful.

Again, just like with the description meta attribute, avoid repetition of words and phrases; just mention a few words that aptly describes and categorizes your web page.

4. Use Divs to Divide Your Layout into Major Sections

Consider dividing your web page into major sections as the first step in constructing a website design.

Doing so from the start promotes clean and well-indented code. It will also help you avoid confusion and excess use of divs, especially if you are writing complex and lengthy markup.

5. Separate Content from Presentation

Your HTML is your content. CSS provides your content’s visual presentation. Never mix both.

Don’t use inline styles in your HTML. Always create a separate CSS file for your styles. This will help you and future developers that might work on your code make changes to the design quicker and make your content more easily digestible for user agents.

Bad Practice: Inline Styles

Below, you can see a paragraph element that is styled using the style attribute. It will work, but it’s bad practice.

<p style="color:#abc; font-size:14px; font-family:arial,sans-serif;">I hate to separate my content from presentation</p>

6. Minify and Unify CSS

A simple website usually has one main CSS file and possibly a few more for things like CSS reset and browser-specific fixes.

But each CSS file has to make an HTTP request, which slows down website load times.

A solution to this problem is to minify (take out unneeded characters such as spaces, newlines, and tabs) all your code and try to unify files that can be combined into one file. This will improve your website load times.

A problem with this approach is that you have to "unminify" (because it’s hard to read unformatted code) and then redo the minification process every time you need to update your code. So it’s better to do this at the end of your production cycle.

Online tools to minify and optimize CSS can be found on this list of CSS optimizers.

Also, always put your stylesheet reference link inside the <head></head> tags because it will help your web page feel more responsive while loading.

7. Minify, Unify and Move Down JavaScript

Like CSS, never use inline JavaScript and try to minify and unify your JavaScript libraries to reduce the number of HTTP requests that need to be made in order to generate one of your web pages.

But unlike CSS, there is one really bad thing about external JavaScript files: browsers do not allow parallel downloads, which means the browser cannot download anything while it’s downloading JavaScript, resulting in making the page feel like it’s loading slowly.

So, the best strategy here is to load JavaScript last (i.e. after your CSS is loaded). To do this, place JavaScript at the bottom of your HTML document where possible. Best practice recommends doing this right before the closing <body> tag.


Minify, Unify and Move Down JavaScript

8. Use Heading Elements Wisely

Learn to use <h1> to <h6> elements to denote your HTML’s content hierarchy. This helps make your content more meaningful for screen-reading software and search engines, as well as other user agents.


<h1>This is the topmost heading</h1>
<h2>This is a sub-heading underneath the topmost heading.</h2>
<h3>This is a sub-heading underneath the h2 heading.</h3>

For blogs, I really recommend using the <h1> element for the blog post’s title instead of the site’s name because this is the most important thing for search engines.

WordPress Code Example

<h1 class="entry-title"><?php the_title(); ?></h1>

9.Use the Right HTML Element at the Right Place

Learn about all the available HTML elements and use them correctly for a semantic and meaningful content structure.

Use <em> for emphasis and <strong> for heavy emphasis, instead of <i> or <b> (which are deprecated).


<em>emphasized text</em>
<strong>strongly emphasized text</strong>		

Use <p> for paragraphs. Don’t use <br /> to add a new line between paragraphs; use CSS margin and/or padding properties instead.

For a set of related elements, use:

Don’t use <blockquote> for indentation purposes; use it when actually quoting text.

10. Don’t Use Divs for Everything

Sometimes developers end up wrapping <div> tags around multiple <div> tags that contain more <div> tags, creating a mountain of divs.

Under the latest draft of the W3C HTML specification, a <div> is a meaningless element that should be used "as an element of last resort, for when no other element is suitable."

But many use it even for menial things like displaying inline elements as block elements (instead of the display:block; CSS property).

Avoid creating mountains of divs by using them sparingly and responsibly.

11. Use an Unordered List (<ul>) for Navigation

Navigation is a very important aspect of a website design and the <ul> element combined with CSS makes your navigation menus semantic (because, after all, a navigation menu is a list of links) as well as beautiful.

Also, by convention, an unordered list for your navigation menu has been the accepted markup.

An Example of an Unordered List

<ul id="main_nav">
<li><a href="#" class="active">Home</a></li>
<li><a href="#">About</a></li>
<li><a href="#">Portfolio</a></li>
<li><a href="#">Services</a></li>
<li><a href="#">Blog</a></li>
<li><a href="#">Contact Us</a></li>

CSS to Style the Unordered List into a Horizontal Navigation Bar

 #main_nav { position:absolute; right:30px; top:40px;}
  				 #main_nav li { float:left; margin-left:2px; }
  				 #main_nav li a{ font-size:16px; color:#fff; text-decoration:none; padding:8px 15px; -moz-border-radius:7px; -webkit-border-radius:7px; border-radius:7px;} 
  				 #main_nav li,
  			#main_nav li a:hover{  background-color:#0b86cb;  }


Use an Unordered List (<ul>) for Navigation

12. Close Your Tags

Closing all your tags is a W3C specification. Some browsers may still render your pages correctly (under Quirks mode), but not closing your tags is invalid under standards.


<div id="test">
<img src="images/sample.jpg" alt="sample" />
<a href="#" title="test">test</a>
<p>some sample text </p>

13. Use Lower Case Markup

It is an industry-standard practice to keep your markup lower-cased. Capitalizing your markup will work and will probably not affect how your web pages are rendered, but it does affect code readability.

Bad Practice

<IMG SRC="images/sample.jpg" alt="sample"/>
<A HREF="#" TITLE="TEST">test</A>
<P>some sample text</P>

Good Practice

<div id="test">
<img src="images/sample.jpg" alt="sample" />
<a href="#" title="test">test</a>
<p>some sample text </p>

14. Use Alt Attributes with Images

Using a meaningful alt attribute with <img> elements is a must for writing valid and semantic code.

Bad Practice

<img id="logo" src="images/bgr_logo.png"/>
<!-- has an alt attribute, which will validate, but alt value is meaningless -->
<img id="logo" src="images/bgr_logo.png" alt="brg_logo.png" />

Good Practice

<img id="logo" src="images/bgr_logo.png" alt="Six Revisions Logo" />

15.Use Title Attributes with Links (When Needed)

Using a title attribute in your anchor elements will improve accessibility when used the right way.

It is important to understand that the title attribute should be used to increase the meaning of the anchor tag.

Bad Practice

<!-- Redundant title attribute -->
<a href="" title="Click Here">Click here.</a>

When a screen reader reads the anchor tag, the listener has to listen to the same text twice. What’s worse is that it doesn’t explain what the page being linked to is.

If you are just repeating the anchor’s text or aren’t intending to describe the page being linked, it’s better not to use a title at all.

Good Practice

<a href="" title="A list of all articles.">Click here.</a>

16. Use Fieldset and Labels in Web Forms

Use the <label> element to label input fields. Divide input fields into logical sets using <fieldset>. Name a <fieldset> using <legend>. All of this will make your forms more understandable for users and improve the quality of your code.


    <legend>Personal Details</legend>
    <label for="name">name</label><input type="text" id="name" name="name" />
    <label for="email">email</label><input type="text" id="email" name="email" />
    <label for="subject">subject</label><input type="text" id="subject" name="subject" />
    <label for="message" >message</label><textarea rows="10" cols="20" id="message" name="message" ></textarea>

17.Use Modular IE Fixes

You can use conditional comments to target Internet Explorer if you are having issues with your web pages.

IE 7 Example

<!--[if IE 7]>
<link rel="stylesheet" href="css/ie-7.css" media="all">

IE 6 Example

<!--[if IE 6]>
<link rel="stylesheet" href="css/ie-6.css" media="all">
<script type="text/javascript" src="js/DD_belatedPNG_0.0.8a-min.js"></script>
<script type="text/javascript">

However, try to make your fixes modular to future-proof your work such that when older versions of IE don’t need to be supported anymore, you just have to update your site in one place (i.e. take out the reference to the ie-6.css stylesheet).

By the way, for pixing PNG transparencies in IE6, I recommend the DD_belated PNG script (the JavaScript method referenced above).

18.Validate Your Code

Validation should not be the end-all evaluation of good work versus bad work. Just because your work validates doesn’t automatically mean it’s good code; and conversely, a work that doesn’t fully validate doesn’t mean it’s bad (if you don’t believe me, try auto-validating Google or Yahoo!).

But auto-validation services such as the free W3C markup validation service can be a useful debugger that helps you identify rendering errors.

While writing HTML, make a habit to validate frequently; this will save you from issues that are harder to pinpoint (or redo) once your work is completed and lengthier.

19. Write Consistently Formatted Code

A cleanly written and well-indented code base shows your professionalism, as well as your consideration for the other people that might need to work on your code.

Write properly indented clean markup from the start; it will increase your work’s readability.

20. Avoid Excessive Comments

While documenting your code, the purpose is to make it easier to understand, so commenting your code logic is a good thing for programming languages like PHP, Java and C#.

But markup is very much self-explanatory and commenting every line of code does not make sense in HTML/XHTML. If you find yourself commenting your HTML a lot to explain what is going on, you should review your work for semantics and appropriate naming conventions.

Related Content

About the Author

Saqib Sarwar is a freelance web developer with over 7 years of web development experience. He specializes in XHTML, CSS, PHP and WordPress development. He loves to write well-structured and clean code that validates. Get in touch with Saqib through his freelance business/blog, 960Development as well as follow him on Twitter as @saqibsarwar.

This was published on Aug 16, 2010


Andre Aug 16 2010

Very good article! Thanks and greetings from germany,


ApolloNet Aug 16 2010

Always nice to review the basics.

Stefan Rynkowski Aug 16 2010

Simple overview. I like it ;)

Rhonda Aug 16 2010

Great tips! I’m always focused on number 19, especially when you’re on a team because having well formatted code is a time saver right from the beginning.

Dayle Rees Aug 16 2010

Nice clear article, not much new for me apart from the javascript at the bottom, but I am sure this will be very useful to someone!

Jason Aug 16 2010

Great article Saqib, although in #14 and #15 I’d like to point out that when using alt and title attributes with linked images, you should not use the same value for alt and link title. Search engines consider it the same as spamming your description from #3. Try to make each one a different value.

Johnboy Aug 16 2010

Sorry but this list just seems very out of date especially with the spread of html5.

Bram Van der Sype Aug 16 2010

21. Don’t use “click here” links.

At least that’s one of the major “SEO don’ts” I remember. Agreed, it’s not strictly HTML related, but I somehow feel like the example in 15 is a bit off…

Rob Jenkins Aug 16 2010

Great Article and a good introduction to (X)HTML, Saqib. Might I add one further thing? Closing tags can be further helped through labelling, particularly if the code gets complex. If, for example, you have a Div called ‘container’, put the comment “” next to the closing div element. That way you’ll always know you have closed your tags correctly. Saves endless time counting open and closed divs when troubleshooting. Saves even more tme if your HTML file finally ends up split into seperate php files.

Rob Jenkins Aug 16 2010

Apologies, publishing issues, last comment should read”< !–– #container–– >”. Hope this one publishes

Niubi Aug 16 2010

Yup, that’s pretty comprehensive. Did you see some of the coding over on the dubli websites? Shocking!

Nice list, thanks

It’s always good to review best practice, as it is always easy to fall into bad habits….

(Not that I have any bad habits of course, but I’ve heard that some people do have them! ;-))

Hannes Aug 16 2010

Nice Article, but google doesn’t always use the description from the meta element, in my experience in the most cases it wont … what works good is metadescription == first flowing text after the h1 ..something along those lines

Jacob Gube Aug 16 2010

@Johnboy: How does any of these best practices change with HTML5 specs?

@Bram Van der Sype: In terms of SEO, that’s true. It was used as a familiar example of what it means to write meaningless title attributes on links (in that example, it did not illuminate what “click here” meant by using “click here” in the title attribute as well). The example also illustrates that with a good title attribute, even a meaningless link like “click here” has more meaning by describing what the link is.

Fabian Aug 16 2010

Ok, you just reccomend “XHTML 1.0 strict doctype”, and the rule itself (Always Declare a Doctype)is right, but:
Using XHTML1Strict, because it’s the latest? And what about html5 then?

You should speak the language you reach the widest audience while not breaking it’s grammar. That could also be html4.1, arguably even transitional.

Rob Davis Aug 16 2010

I really like this article. Very well thought out and informative. I would argue one point in item #15, SEO best practices would say never you “click here” as anchor text. I am sure this was just for the example, just sayin’.


One thing that changes with HTML5 spec would be #4 (what with new nav tags and the like). And actually, I have made a practice of avoiding using div’s except when I absolutely need one as a ‘hook’ or if they greatly increase page organization or code readability.

From #10: ‘div is a meaningless element that should be used “as an element of last resort, for when no other element is suitable.”‘

Johnboy Aug 16 2010

The doctype declaration in step 1. Surely sixrevisions should be encouraging the use of

Also the sample code in step 4 with Surely that should just be

The code in step 11 seems like excessive mark up and the use of a block would be more forward thinking.

Johnboy Aug 16 2010

The doctype declaration in step 1. Surely sixrevisions should be encouraging the use of html5 doctype (tried to give example but the filters on the comments strip out my html)

Also the sample code in step 4 with the divs with ids of header and footer Surely that should use header tags and footer tags instead

The code in step 11 seems like excessive mark up and the use of a nav block would be more forward thinking.

Matt obee Aug 16 2010

One minor point of note: alt=”Six Revisions” would be more appropriate than alt=”Six Revisions Logo” in most contexts.

Zach Wingo Aug 16 2010

Browsers actually don’t care what version your Doctype is because they only use it to trigger Quirks, Standards, or Almost Standards mode. Everyone should be using the HTML5 doctype *now* because it triggers Standards mode in almost every browser. You should update this post to reflect this since there is almost no drawbacks to using it.

Doug S. Aug 16 2010

Just so you know, I and B are depreciated in XHTML but not HTML5. I and B are now used in situations where the mark is meant to be more of a stylistic one and not a semantic one. For example, the name of a play would be in an I tag.

RussellUresti Aug 16 2010

@Jacob Gube: The only thing I can see changing with the HTML5 spec is number 4 – Use Divs to Divide Your Content Into Major Sections.

With HTML5, there is specifically a section tag. Not to mention the header tag and footer tag for those specific sections.

To me, all the rest of it is very good advice.

Spicer Matthews Aug 16 2010

Great write up. I have been writing html for years and I learned a few things. It is easy to get lazy. Thanks for the refresher!!

Elf Sternberg Aug 16 2010

How would you reconcile your advise with the tidalwave of HTML5 that’s rolling over the web right about now?

Rupnarayan Bhattacharya Aug 16 2010

Really useful information. Using divs everywhere is really a common problem. A guideline should be published about the proper uses of html elements.

ddeja Aug 16 2010

Number 3 – META Description is always shown under title in google or other results? Or it depends on the phrase that we search?

Number 6 and 7 – Should we use this step from the beginning or at the and of the working project? Minified file is very hard to edit for the beginners…

Number 17 – Should we still support IE6 browsers? I’m tired of this nightmare…


folktrash Aug 16 2010


Jacob Gube Aug 16 2010

@Johnboy Ah so you’re saying because of two minor points — including a point that uses a new HTML5 element — everything is outdated. As much as I love HTML5 and promote its use, (I wrote about it in in 2008 on ReadWriteWeb before this year’s HTML hype with Google and Apple adopting some HTML5 into their site, and I continue to cover it here on Six Revisions), until HTML5 is final recommendation, it isn’t the current standard, it is the future standard.

If you want to be pragmatic, just looking at browser usage shows that over 51% of people still use browsers that don’t support HTML5. Nothing here is outdated; these are still current best practices for a majority of us. <nav> won’t be valid in the majority of our clients’ users’ browsers. So no, at this point, I — nor any professional web developer who doesn’t cater to building sites strictly viewed in the most current versions of FF, Chrome, Safari — would encourage the use of <nav> until at least IE9 rolls out. And divs, uls, etc. — you might be surprised — are still supported in HTML5 specs, so it’s future-proof. It seems to me like your follow up comment contains straw man arguments; an attempt to recover from an erroneous and rash comment. Hate to be brutally honest, but that’s how I feel. And if you decide to reply, please do leave a URL; if you can’t be confident enough with your assertions to attach your personal site or social network profile to it, I feel like there’s no point continuing this conversation. Thanks.

@Matt obee: But in this context the image is (hypothetically) the site’s logo, and the alt text should describe what the image is. Six Revisions logo, I guess is a bad example, since in actuality in the real web layout, it’s just a hyperlink using CSS background-image text replacement. Maybe I’m not comprehending your comment fully.

@RussellUresti: Right on! To those reading my reply to Russell, what I’m going to say next is a personal opinion, and you shouldn’t blindly follow what I’m about to say unless you understand the reason behind my belief. *Some* developers (i.e. me) might still continue to use divs if they don’t agree with the the name and semantics of the new HTML5 elements. I’d probably use <article> for main content just to be interoperable with web services that crawl the main content (and because I’m sure screen readers will detect that element to allow readers to skip right to the main content), even though I feel the element’s name should’ve been more flexible (like <maincontent>). Probably isn’t a good reason to break what will likely be best practice in the future, but that’s how I personally feel at this point of time.

Eric Wilson Aug 16 2010

You should note in the alt text for images section the importance of setting alt=”” for fluff images. This will let screen readers know that yes you are thinking of them but please just move along and don’t worry about this particular image.

IIRC JAWS doesn’t particularly care what type of heading you use (h1-h6), in it’s navigate by heading feature it lists them all in the order they are encountered and does not indicate what type of heading each item is.

Sverri Aug 16 2010

1. Doctypes. You should use the doctype that corresponds to the HTML/XHTML version you are using.

5. While not optimal, inline styling can be useful. Yes, it is more organized to keep all your CSS external to the HTML document, but it is generally fine for the rare one-time exceptions, temporary fixes, and for quick testing. Totally excluding its use is fine, but it is available and it works.

12 and 13. As a way of being consistent closing your tags and writing in lowercase is one way, but frankly, the HTML standard is not case sensitive and browsers do not give a toss about these things. You can even omit quotes if you want. I am not disagreeing with you, per se, but there is nothing wrong in not closing some elements and writing in uppercase.

Jens Scherbl Aug 16 2010

@Matt obee: Damn right you are! ;-)

Using alt-attributes like alt=”Six Revisions Logo” isn’t very good practice (actually that’s more of a title-attribute).

Instead, alt-attributes should contain alternative text that provide additional information when read in surrounding context by a screen reader.

Screen reader users shouldn’t notice any images at all, so it’s even better to leave the alt-attribute empty if you can’t provide useful alternative content.

Lopes Aug 16 2010

Great article, congratulations from Portugal.

Jacob Gube Aug 16 2010

@Sverri: About your comment with regards to inline styles: Yeah, but we’re talking about best practices here. If we were talking about performance, I agree with you. Sometimes performance and best practices don’t go hand-in-hand. If you created a stylesheet just for 1 style declaration, that’s 1 wasteful HTTP request that should be inline. And as long as you can justify the consequence of breaking best practices, like I’ve said before, it really doesn’t matter.

@Eric Wilson: Interesting! You sure about that? I might have to ask a screen reader user from the adaptive learning services I work with. That’s the first time I’ve heard that to be honest, but logically it makes sense.

Richard Darell Aug 16 2010

Brillaint points. I come across this daily and this was a great reminder what to think of. Good vs Bad practice is a great way of explaning the right solution. Simply brilliant. Thanks!

Jason Aug 16 2010

All very true points, and happy to know I follow them all (I should do, Front-End Dev is my career!).

@Jacob Gube
I have to agree with Eric Wilson and Jens Scherbl in regards to the alt attribute. I think Jens summarises it best with: “alt-attributes should contain alternative text that provide additional information when read in surrounding context by a screen reader.”

Alt attributes for images should always exist, but many scenarios it is best simply to leave it blank.

Jason Aug 16 2010

@Jacob Gube
6. Minify and Unify CSS
7. Minify, Unify and Move Down JavaScript

I’ve found that YSlow is a good Web Optimisation tool for both of these points. Using it, you can find out how many HTTP requests your page is making; with particular emphasis on CSS, JavaScript and Images.

For me, it opens my eyes to possible merging / unifying of JavaScript and CSS docs AND where the site would benefit from CSS Spriting (which I see you didn’t mention).

seriocomic Aug 16 2010

I’m with a few of the other commenter here. This is a good primer for those looking to start basic HTML in 2006 (i’m sure I could dig up a similar article from then or get it cobbled together from ALA). A few things jump out – the use of multiple JS scripts when you should be trying to reduce the number of HTTP requests (concatenation), the use of meta keywords which is now a defunct practice, etc.

I think more forward thinking coders will be looking at or

saqib sarwar Aug 16 2010

Thanks to all for valuable comments.

Specially Jacob Gube, for replying in my place. While I was sleeping ;)

saqib sarwar Aug 16 2010

@zach wingo thanks for suggestion and I will consider it.

@ddeja 1. Meta description always appears under title in search engine results. 2. For 6 and 7 its better to do this in the end after launching and testing your website. You might consider using some script like this (read comments before using). 3. Regarding IE6 support, I also hate it but supporting it depends upon what your target market is. For web developers you don’t need to support IE 6 because almost all of them use modern browsers like FireFox, Safari and chrome. But case could be different for some other general purpose web application. So make sure when needed your web application looks decent in old browsers.

Julian Aug 16 2010

Great article! Made me feel like a Rockstar because I practice most of the points mentioned.

A tip that could make #6 and #7 tip easier in regards to compression is practice is to keep a “src” for the original files. Example, you have the following structure on your website

/css/mainstyle.css (minified)
/css/src/mainstyle.css (uncompressed)

That way you don’t have to “uncompress” for every edit, simply edit the uncompressed very and run it through the compression engine of your choice. The same technique can be applied to JavaScript.

Oli Studholme Aug 16 2010

The title of this article should be “20 XHTML 1.0 best practices…” as several contain bad advice for writing HTML.

#1 I agree you should always use a doctype, but recommending an XHTML doctype is a bad idea; you can’t serve it using the correct mime type due to IE, it’s interpreted as text/html anyway, and the future is HTML not XHTML. Recommending an XHTML strict doctype is a very bad idea for any client site, or any site accepting comments. One incorrect contribution makes the page invalid, and if you’re serving the page correctly as application/xhtml+xml no content will display.

You should recommend using a validator ( and lint checker ( for validation purposes instead. You should also recommend using an HTML5 doctype as it is supported by all browsers, in that it activates standards mode in all browsers (which is the only browser-related function of doctype). At the very least as @Sverri states “use the doctype that corresponds to the HTML/XHTML version you are using.”

#4 It would be better to advise using semantically appropriate elements; refer to your own advice in #10.

#9 This title is better phrased as “Use the most semantically appropriate element”. Note b and i are not depreciated and have semantic meanings in HTML5; you can read more about them in this article:

#12 “Close your tags” is good advice, but “not closing your tags is invalid under standards” is incorrect.

#14 The title is incorrect, as presentation-only images should have blank alt text. Writing good alt text is much more nuanced than this.

#15 “Click here” as link text is laughably bad as a recommendation of good practice. This text should never be used.

#16 you forgot paragraph or list wrapper elements in your code sample, and I’d recommend wrapping the input in the label.

#17 breaks your advice in #7 by using inline JS and not unifying.

@Jacob Gube; while HTML5 is a working draft it contains far more advice for web designers on how to correctly code HTML than the XHTML 1.0 recommendation, which basically refers to HTML 4.01, which is also vague. It is also more relevant than HTML 4.01 (published 1999) or XHTML 1.0 (published 2002), and is what browser makers are using, so advising against it because it’s not a “standard” is misguided.

Your figure of 51% of browsers not supporting HTML5 is also incorrect — currently only Webkit trunk and Firefox 4.0 beta support the HTML5 DOM. Regardless, “support HTML5” has no meaning as it’s a sliding scale, and anyhow currently no browsers completely support either HTML 4.01 or XHTML 1.0. This is irrelevant in using *the supported parts* of HTML5 however — all browsers support the HTML5 doctype for example.

Hassan Raza Aug 16 2010

About 13 and 19, I am taking lowercase coding as a part of formatted coding. Even formatting doesn’t have that much concern with case sensitivity but here formatted means to me is what feels good to work with. What I believe, if I have to edit and work on a code which is in uppercase, it will not be that much hard to work with but it will surely decrease my working stamina.
As what I have observed by viewing the code of different developers, all of them like to code in lowercase. If you are not agree with “all of them” then it might be 99.9% of coders. :D

Dave Waite Aug 17 2010

Google no longer uses meta keywords in its algorithms.

designbyarm Aug 17 2010

Thanks you for share I like it.

vinod Aug 17 2010

Nice and Good article, Thanks Mr.Saqib Sarwar

“Use for emphasis and for heavy emphasis, instead of or

I think is quite the opposite

brainspills Aug 17 2010

About item number 9:

“9.Use the Right HTML Element at the Right Place…

..Use em for emphasis and strong for heavy emphasis, instead of i or b (which are deprecated).”

This is incorrect… HTML 5 has how given different meanings to em, strong, i, and b tags… check this out:

Horia Dragomir Aug 17 2010

I do agree on most points. HTML5 is not your thing, though; is it?

Joost de Valk Aug 17 2010

I agree with this entire article, in fact, I like it a lot. But one thing raises my back hairs: the meta keywords attribute is no longer supported by any major search engine. It’s not needed, please forget about it.

Prasanth Sekhar Aug 17 2010

Great write up… very useful for beginners :)

Samori Gorse Aug 17 2010

In example #7, it should read .

Then you’ll just have one http request, and parsing should be slightly faster too.

1) Using an XHTML doctype makes no sense unless you are serving XHTML. Using XHTML but not serving it as such is nothing but “tag soup” and will be interpreted as HTML anyway.

2) Closing tags by using the self-closing /> makes no sense in HTML either.

Jacob Gube Aug 17 2010

@Joost de Valk: Hey Joost, thanks for stopping by! If the concern is only for SEO, then I would agree with you.

But if we also factor in interoperability and giving a web page more meaning to web robots — it doesn’t necessarily have to be search engine crawlers, it could be a web app or a service like Delicious which helps users tag their bookmarks using meta keyword — then I agree with Saqib in that it should be included in all web pages.

Matt obee Aug 17 2010

@Jacob Gube: The alt attribute shouldn’t “describe what the image is”, but rather provide text representation of its meaning or purpose. The meaning of that image and the information conveyed by it is “Six Revisions”. The fact that it’s a ‘logo’ is inconsequential – it’s just extra noise :)

Mustapha NAJAH Aug 17 2010

why can’t i see my comment !!

mkitmedia Aug 17 2010

Good article. I have ideas to make web more,Thank you.

Captain Fatnutz Aug 17 2010

wow. what an original and groundbreaking list of things everyone knows.

basic knowledages but always are omited by both copy writter and developers. In fact, the all above are helpful a website to be clear and can be readable. NOT ONLY FOR SEO.

Danny van Kooten Aug 17 2010

I agree on all points, but like Joost said, no much use for meta keywords (SEO-wise). Although Jacob has a good point mentioning Delicious using keywords for tagging articles.

Anyway, thanks for listing these best practices. If I have to pick one for being most important (which I probably shouldn’t) i’d go for closing your tags! Always make sure your HTML is a “tree”! :)

Ann Donnelly Aug 17 2010

Good post and good comments. Nice to see an outline like this that isn’t completely SEO oriented, but does cover the main points – kinda showing that good SEO starts with good web development!

One question, being less technical than some: if you put the javascript at the end will it be loaded in time for it to work properly on the page? Many are saying it’s better to put Google Analytics at the top to be sure that it loads before any visitors take an action.

Pontus Ekman Aug 17 2010

Good practices indeed.

Joost de Valk Aug 17 2010

@Jacob: where do you see Delicious using that data? I don’t think they do, a quick test just now “proved” that to me. I know, seriously, of no use of the meta keywords tag. If that’s the case, it doesn’t belong in a best practices document.

kwerboom Aug 17 2010

You do realize that XHTML in any form is dead. The story is covered in “XHTML 2 Working Group Expected to Stop Work End of 2009, W3C to Increase Resources on HTML 5”. It is now HTML 5 all the way.

Jimmy Aug 17 2010

Great article! All front-end web developers should definitely follow most of these practices and make it a habit in their workflow. Although these types of articles are common and repeated many times, I do appreciate them being posted once in a while just to remind me that I’m still doing them.

Though I also don’t recommend an XHTML Strict DOCTYPE. If anything, everyone should start using HTML5 DOCTYPE (XHTML style or not), etc., especially since most of the non-new HTML tags are backwards compatible, and it promotes much cleaner HTML by disregarding the TYPE attribute for SCRIPT/STYLE.

Jacob Gube Aug 17 2010

@Joost de Valk: Interesting, I tested it now too and it doesn’t do it anymore. StumbleUpon used to also use the keywords meta to help tag your favorites.

In any event, like I said, if we are equating “web development best practices” to “what is good for SEO”, then sure, take out the meta keywords tag.

However, to me, and to a lot of web devs, SEO takes a back seat. Meta keywords increase interoperability with other web services, giving your web page more meaning; anything that increases meaning to a web page, which is what a markup language is supposed to do, is never a bad thing. It’s not a deprecated HTML element either, so there isn’t any harm that I see in including keywords.

Now when we talk about performance or “because it’s worthless for SEO,” that’s another story — but to me, this post is about web development best practices, not SEO best practices or performance best practices, which *sometimes* doesn’t go hand-in-hand.

My $0.02 — I’d love to hear what you and others think about that point of view.

Adil Shoukat Aug 17 2010

Very Nice and Good article

saqib sarwar Aug 17 2010

@Ann Donnelly in javascript we do most of the things after checking document is ready. so there should not be any problem regarding loading javascript in the end.

@Joost de Valk and @Jacob Gube, thanks for clarifying meta keywords tag.

Jason Aug 18 2010

I don’t think it is standard to close HTML5 tags like input fields with /> anymore, not according to the W3C documentation.

Could someone confirm?

david Aug 18 2010

Thanks for the post, very useful reminder of what standards compliant HTML should look like.

Jacob Gube Aug 18 2010

@Jason: Though at the moment, I can’t directly confirm what you’ve said, I do see that examples on HTML5 working draft specs show elements that are unclosed. For example, this img element, from this example, is unclosed:

<p><img src="shalott.jpeg" alt=""></p>

Shane Aug 18 2010

Nice article!!! I will be sure to bare all of these in mind!!!

Vincent Veri Aug 18 2010

These tips are very interesting. They cover many arguments like SEO, optimizing performance and other.
It’s always a good thing reading about best and worst practices.
I really liked this post.

Kirstine Vergara Aug 18 2010

Great post. It’s always nice to go back to the basics. Thanks for this!

Techozens Aug 18 2010

Wow, nice 20 points article.. you rock bro.

Skyrocket Labs Aug 18 2010

Very thorough. We can never lose sight of the basics.

The only item I would add is to try to refrain from loading too many separate JavaScript files if you can. It’s better for performance to load one 20KB .js file once when the page loads than five individual 5KB files. Use a common.js for global functions and separate files for the rest, if necessary. Even a little performance improvement is better than none. This is nitpicking, I know, but I try to use that practice whenever I can.

CodeMyConcept Aug 18 2010

We do this for a living so we cannot thank you enough for this very detailed article.

People understand good mark up, the world would be a better place.

Thank you.

mario Aug 18 2010

Repeating a lot of fallacies.

If you want your text to be green or red, use em or strong. If you want it to be bold for purely stylistic reasons, use the bold tag. It’s undeprecated.

It’s likewise retarded to close singular tags. HTML4 and HTML5 follow SGML, which is a perfectly cromulent standard. Closing the img tag is redundant. Using the proper SGML style is perfectly standards compliant, understood by all current and even the oldest browsers, and correctly parsed by any HTML parser or SGML toolkit.

Anybody deploying XHTML syntax without the proper MIME type or any desire to embed another XMLNS is just plainly a buzzword hipster, not a standards luminary.

Andrew Cooper Aug 18 2010

Ok, this comment is going to sound fairly harsh and I hate to say bad things, but at the same time I also hate wasting my time. My first critique is that you should have changed the title of the article to something more appropriate rather than “best practices you should follow” or changed the content to actually fit the title.

It’s hard for me to believe that you Saqib, have over 7 years of Web development experience, but here goes.

#1 – This isn’t a best practice, this is something that should be done. It’s like saying that if you want to output a paragraph of text on a screen then you should you the element…There is no other way of outputting a paragraph of standard text on a Web page without using the element. That is what it is there for. As for your recommendation, I think you should have given the reader the HTML 4.01 Strict, XHTML 1.0 Strict, and HTML 5 DOCTYPE example codes and said that either of these would be fine.

#4 – This doesn’t even make sense. It’s all jumbled up and mixes up the use of divisions in layout, what it promotes (and it doesn’t actually promote it at all, clean and well-indented code should be a best practice point on its own – THAT is a best practice), and what it helps to avoid (how can you say it avoids excess use of divisions? That is down to the individual coder. The use of divisions doesn’t help to avoid the excess use of divisions at all.)

#6 – The whole of this point has nothing to do with HTML best practice, what you’re talking about is CSS best practice. Only the last sentence has anything to do with HTML and you should have talked about linking to external CSS and JS files in one point as a best practice.

#7 – This isn’t a HTML best practice, this is a JavaScript best practice. The last paragraph of this point is the only thing that should have been included in the article.

#9 – This is the biggest mess you made in the article which prompted me to write this whole comment. Both the and elements are NOT deprecated in HTML 4.01, XHTML 1.0, or HTML 5. Please tell me, where in the lords name does any of the W3C Technical Recommendations state that the and elements are deprecated? Surely you’ve read the W3C HTML TR as you are a professional, right? Just confirming for the readers of this article – YOU CAN USE THE AND ELEMENTS IN ANY HTML DOCUMENT AS THEY ARE VALID HTML.

#10 – This is the best practice tip that people need to be aware of when using divisions in their Web pages. As I said for #4 it isn’t the use of divisions that helps avoid the excess of them, it’s up to the individual user as to how many divisions they use in their documents, this is a good point you’ve made, but it contradicts slightly with what was said in #4.

#12 – Closing all your tags is NOT a W3C specification; it is a syntax rule that is PART of a W3C specification. Beginners reading this may well end up searching for a “W3C Close Your Tags Technical Recommendation” document somewhere. Talk about confusing. Learning HTML can be hard as it is, this point just doesn’t help people. Not closing tags is invalid markup in some standards; it is a best practice to close all tags though – Most times not a requirement.

I have nothing to say about points that I’ve not said anything about, they’re fine. Hope that helps you to write in the future and hope it helps the readers of this article understand HTML a bit better :)

Andrew Cooper Aug 18 2010

My previous comment messed up because the HTML elements weren’t converted, nevermind, I’m sure you know what I’m talking about :) If you don’t I can clarify.

Deko Web Aug 18 2010

really nice article. thank you for sharing..


Could you be more specific why is a bad practice for “Bad Practice: Inline Styles”?

Thank you.

Kyle Hayes Aug 22 2010

It is worthy to note that whilst on the topic of minifying, those jQuery plugins that are being pulled in should be combined and minified as well. That’s 7 different requests! Woo howdy!

Lisa Thomason Aug 22 2010

Thanks for a great article easy to follow and covers good coding practice. LT

nice stuff

saqib sarwar Aug 26 2010

@Kyle Hayes, that is just for example to put script at bottom. you are right I should have given an example to put only one minified script at bottom..

Marry Aug 29 2010

HTML4 and HTML5 follow SGML, which is a perfectly cromulent standard. Closing the img tag is redundant. The only item I would add is to try to refrain from loading too many separate JavaScript files if you can.

@browninho Sep 11 2010

Invaluable article for anyone starting out in web design – like me!

yuvrajmetrani Sep 28 2010

Crisp, compact and cogent. Thanks a lot for sharing.

KatLilore Nov 10 2010

We’ve always been slightly nonplussed about 14 & 15. Is it best practice to use alt tags only w/ images, and title tags only w/ links? Do Google et al judge negatively for using both alt & title tags for both images and anchor tags? Please advise, and thanks for putting this together – very useful!

Yurishma Nov 17 2010

@johnboy – you have no clue what you are talking about, HTML 5 isn’t even the new standard and won’t be for almost ten years. You may be able to use some of it, but for good usablity stick with HTML 4 for now and don’t use new code unless Internet Explorer can handle it, otherwise you are wasting your time. Many people still use IE, not just the awesome browser that you, the code master uses. Thank you.

BlueBoden Dec 30 2010

Forget about IE6, no reason to support it.

The keywords meta tag is practically useless. I can’t be bothered by sites who still use it, because they are likely to clogged with spam anyway, for my sites to even be noticed.

For those saying theres nothing wring with being lazy around closing tags and attribute values. Well, there are cases where omitting closing tags and quotes on attribute names could mess up your site, so you might as well do things properly.

Anand Dec 31 2010

Good Article.. Nice

Renier Feb 05 2011

Love your suggestions. If everybody follow them the web will be a better place.

Kristin Feb 12 2011

I wish we could forget about IE6. We just had a Google Analytics meeting with our Internet Marketing Manager and she showed us the breakdown of the IE versions our customers are using. I work for a small eCommerce site. Surprisingly, $40K of our yearly sales are attributed to customers using IE6. The percentage of them might appear small when you compare it to later versions or even Safari or FF, but the dollar amount is significant enough where a small company like ours cannot afford to ignore IE6 altogether. I wish it were different….our site needs to modernize in a huge way anyway….

Muthu Apr 05 2011

Thanks a lot..! It was very useful.

Ramesh Vishwakarma Apr 09 2011

It is very helpful for me. Nice article…

Sindhu Jun 15 2011

Thanks for sharing tips.

Komikoyunlar Jul 09 2011

Closing the img tag is redundant. The only item I would add is to try to refrain from loading too many separate JavaScript files if you can.

motoroyunlari Aug 02 2011

Closing the img tag is redundant. The only item I would add is to try to refrain from loading too many separate JavaScript files if you can.

very good text.

kumarsapkota Sep 28 2011

Such articles is always inspiring for new persons like us to learn more. Thanks for your service.

Very useful, but given the amount of comments about HTML5, surely its not that hard to update it :)

Best practices for when to use article, section, nav and aside for one would be really nice.


VvaLL Oct 19 2011

Thank u very much for sharing this ‘must known basics’.

Krishna Oct 25 2011

Good one!

tyropel Oct 31 2011

really good article. Thanks a lot…

Mohd Saqib Nov 03 2011

Basic info but good to know…. I follow almost all points in my development but I consider now that I use too much comments in my code…. others are fine for me.. :)

thanks for sharing the info :)


Siraj Nov 22 2011

Superb posting, very useful for all the webies.

Vijay Kumar Chauhan Mar 15 2013

I am a beginner in web development.
Nice to find articles like this.

This comment section is closed. Please contact us if you have important new information about this post.