Menu Search
Jump to the content X X
Smashing Conf Barcelona

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

12 Principles For Clean HTML Code

Beautiful and clean HTML is the foundation of a beautiful website. When I teach people about CSS1, I always begin by telling them that good CSS can only exist with equally good HTML markup. A house is only as strong as its foundation, right? The advantages of clean, semantic HTML are many, yet so many websites suffer from poorly written markup.

Let’s take a look at some poorly written HTML, discuss its problems, and then whip it into shape! Bear in mind, we are not passing any judgment on the content or design of this page, only the markup that builds it. If you are interested, take a peek at the bad code2 and the good code3 before we start so you can see the big picture. Now let’s start right at the top. [Content Care Oct/31/2016]

Further Reading on SmashingMag: Link

1. Strict DOCTYPE Link

If we are going to do this, let’s just do it right. No need for a discussion about whether to use HTML 4.01 or XHTML 1.0: both of them offer a strict version that will keep us nice and honest as we write our code.

clean html

Our code doesn’t use any tables for layout anyway (nice!), so there really is no need for a transitional DOCTYPE.


2. Character set & encoding characters Link

In our <head> section, the very first thing should be the declaration of our character set. We’re using UTF-8 here, which is swell, but it’s listed after our <title>. Let’s go ahead and move it up so that the browser knows what character set it’s dealing with before it starts reading any content at all.

character example

While we’re talking about characters, let’s go ahead and make sure any funny characters we are using are properly encoded. We have an ampersand in our title. To avoid any possible misinterpretation of that, we’ll convert it to &amp; instead.


3. Proper indentation Link

All right, we are about three lines in and I’m already annoyed by the lack of indentation. Indentation has no bearing on how the page is rendered, but it has a huge effect on the readability of the code. Standard procedure is to indent one tab (or a few spaces) when you are starting a new element that is a child element of the tag above it. Then move back in a tab when you are closing that element.

indentation example

Indentation rules are far from set in stone; feel free to invent your own system. But I recommend being consistent with whatever you choose. Nicely indented markup goes a long way in beautifying your code and making it easy to read and jump around in.


4. Keep your CSS and JavaScript external Link

We have some CSS that has snuck into our <head> section. This is a grievous foul because not only does it muddy our markup but it can only apply to this single HTML page. Keeping your CSS files separate means that future pages can link to them and use the same code, so changing the design on multiple pages becomes easy.

external example

This may have happened as a “quick fix” at some point, which is understandable and happens to all of us, but let’s get that moved to a more appropriate place in an external file. There is no JavaScript in our head section, but the same goes for that.

5. Nest your tags properly Link

The title of our site, “My Cat Site,” is properly inside <h1> tags, which makes perfect sense. And as per the norm, the title is a link to the home page. However, the anchor link, <a>, wraps the header tags. Easy mistake. Most browsers will handle it fine, but technically it’s a no-no. An anchor link is an “inline” element, and header tags are “block” elements. Blocks shouldn’t go inside inline elements. It’s like crossing the streams in Ghostbusters. It’s just not a good idea.

nesting example

6. Eliminate unnecessary divs Link

I don’t know who first coined it, but I love the term “divitis,” which refers to the overuse of divs in HTML markup. Sometime during the learning stages of Web design, people learn how to wrap elements in a div so that they can target them with CSS and apply styling. This leads to a proliferation of the div element and to their being used far too liberally in unnecessary places.

divitis example

In our example, we have a div (“topNav”) that wraps an unordered list (“bigBarNavigation”). Both divs and unordered lists are block-level elements. There really is no need whatsoever for the <ul> to be wrapped in a div; anything you can do with that div you can do with the <ul>.


7. Use better naming conventions Link

This is a good time to bring up naming conventions, as we have just talked about that unordered list with an id of “bigBarNavigation.” The “Navigation” part makes sense, because it’s describing the content that the list contains, but “big” and “Bar” describe the design not the content. It might make sense right now because the menu is a big bar, but if you change the design of the website (and, say, change the website navigation to a vertical style), that id name will be confusing and irrelevant.

naming conventions example

Good class and id names are things like “mainNav,” “subNav,” “sidebar,” “footer,” “metaData,” things that describe the content they contain. Bad class and id names are things that describe the design, like “bigBoldHeader,” “leftSidebar,” and “roundedBox.”

8. Leave typography to the CSS Link

The design of our menu calls for all-caps text. We just dig how that looks, and more power to us. We have achieved this by putting the text in all-caps, which of course works; but for better, future extensibility, we should abstract typographic choices like this one to the CSS. We can easily target this text and turn it to all-caps with {text-transform: uppercase}. This means that down the road, if that all-caps look loses its charm, we can make one little change in the CSS to change it to regular lowercase text.

typography example

9. Class/id the <body> Link

By “class the body,” I literally mean apply a class to the body, like <body class=”blogLayout”>. Why? I can see two things going on in this code that lead me to believe that this page has a layout that is different than other pages on the website. One, the main content div is id’d “mainContent-500.” Seems like someone had a “mainContent” div at one point and then needed to alter its size later on and, to do so, created a brand new id. I’m guessing it was to make it larger, because further in the code we see <class=”narrowSidebar”> applied to the sidebar, and we can infer that that was added to slim down the sidebar from its normal size.

This isn’t a very good long-term solution for alternate layouts. Instead, we should apply a class name to the body as suggested above. That will allow us to target both the “mainContent” and “sidebar” divs uniquely without the need for fancy new names or class additions.

body class example

Having unique class and id names for the body is very powerful and has many more uses than just for alternate layouts. Because every bit of page content lies in the “body” tag, you can uniquely target anything on any page with that hook; particularly useful for things like navigation and indicating current navigation, since you’ll know exactly what page you are on with that unique body class.


10. Validate Link

Kind of goes without saying, but you should run your code through the ol’ validator machine to pick up small mistakes. Sometimes the mistakes will have no bearing on how the page renders, but some mistakes certainly will. Validated code is certain to outlive non-validated code.

validation example

If for no other reason, seeing that green text on the W3C validator tool just makes you feel good inside.


11. Logical ordering Link

If it is at all possible, keeping the sections of your website in a logical order is best. Notice how the footer section lies above the sidebar in our code. This may be because it works best for the design of the website to keep that information just after the main content and out of the sidebar. Understandable, but if there is any way to get that footer markup down to be the last thing on the page and then use some kind of layout or positioning technique to visually put it where you need it, that is better.

order example

12. Just do what you can Link

We’ve covered a lot here, and this is a great start to writing clean HTML, but there is so much more. When starting from scratch, all of this seems much easier. When trying to fix existing code, it feels a lot more difficult. You can get bogged down in a CMS that is forcing bad markup on you. Or, there could be just so many pages on your website that it’s hard to think of even where to begin. That’s OK! The important thing is that you learn how to write good HTML and that you stick with it.

The next time you write HTML, be it a small chunk in a huge website, or the beginning of a fresh new project, just do what you can to make it right.

order example


Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19

↑ Back to top Tweet itShare on Facebook

I create websites and help others create better websites through writing and speaking. I consider myself a lucky man for getting to work in such a fun and rewarding field.

  1. 1

    Great post!

    What font did you use for the comments :-)

  2. 2

    Just curious, what font are you using for the comments in your images?

  3. 3

    For some reason I dont really trust html tidy used it for the first time this weekend though. The whole automated thing sorta freaks me out.

    And #2 that’s new to me thanks a lot.

    Awesome article

  4. 4

    “Our code doesn’t use any tables for layout anyway (nice!)”
    Nice…but…tables do allow us to center blocks on the screen very easily.

  5. 5

    So does div{margin:0 auto;}

  6. 6

    Cool… easy and well explained.

  7. 7

    I’ve given up on the Strict DOCTYPE. I used to be its biggest advocate, but it has become less and less viable to me. The reason: user-generated content. We’re well into Web 2.0 now, whatever that means. It’s the era of interaction. I can control my code and validate it and make it semantically perfect… but the minute a user types an ampersand into a comment box, the whole thing explodes. Not to mention mismatched, unclosed, or deprecated HTML tags.

    I suppose if I got paid more I could bother to parse everything and convert characters to entities and figure out what to do with user-supplied HTML. That’s too big of a job to be feasible for me — I can’t anticipate every possible thing a user might type. With the Strict DOCTYPE, all it takes is one syntax error and the entire page fails most ungracefully. I can’t afford to let that happen on a modern dynamic site. Better to go with a Transitional DOCTYPE and let quirks mode deal with irregularities. Practicality wins out.

  8. 8

    I disagree with #7, there is nothing wrong with the class “Red” if it is defined as { color: red; }. In that instance, it is the most descriptive it can be, and if you change your design, you wouldn’t change it to be defined differently, you would apply “Blue” as a class instead.

    As an ID name, I agree with you that Navigation or footer should be specific to what they are, but a class name is something that can be applied to many elements, and should define the class. What is the common denominator of every element of the class? Well, in that instance, every instance of the “Red” class will be red, so why is that a worse name than describing the content?

  9. 9

    @Lee… What is so intuitive about tons of spacer.gif graphics (you normally see ton of those when site is designed with tables)? Learn how to layout pages with CSS, and leave tables for tabular data. Just MHO.

  10. 10

    I was advocating “STRICT” XHTML until I hit the biggest snag – file upload in AJAX enabled websites – still requires an IFRAME which isn’t allowed in XHTML strict…. unfortunately the workaround – OBJECT – doesn’t offer the same functionality as IFRAME… in this one instance.!

  11. 11

    Completely disagree with 4, I’m getting very tired of sites loading without styles or JavaScript whenever there’s a glitch with the connection! The correct approach would be to keep the important code in the header (from a server side include) and use an external file for all the extras.

  12. 12

    really nice and usefull tips. thank you interweb! :)

  13. 13

    great for beginners

  14. 14

    Great tips, Chris.

  15. 15

    Something really worth reading and extremely always Smashing Mag!

    I love you guys.

  16. 16

    Good post!
    oh, and the link “W3 MARKUP” in the footer is ugly dead..

  17. 17

    Close, but no cigar.
    It is a right step in the right direction, but… (there is always a but)…
    1) Since there should be only one <h1> in a page it does not need an id and if you need to style the <h1> in a different way in different pages you can use the body id to identify the <h1> with body#blogLayout h1{color:#f00}.
    2) in most designs the <div id="topNav"> is needless and the <ul> under it can be the hook for the CSS, on the other hand, if you do need the <div id="topNav"> then you probably do not need the id in <ul id="bigBarNavigation">
    3) the name “topNav”, “bigBarNavigation”, “sidebar” and “footer” are problematic. The id of an element should describe its content not its position (top, side, foot) or style (big). Navigation is a good name, you can add mainNavigation, secondaryNavigation and copy as ids, now if you will change (with CSS) the position and/or style of the element the id will still describe its content.

  18. 18

    David Hellmann

    November 12, 2008 3:51 pm

    Good Things! :D haha :)

  19. 19

    Chris, great post. Really like the way you lay out the info, and explain in an easy to understand manner. Great stuff, nice work.

  20. 20

    Good article for Strict basic template building. Thanx

  21. 21

    With the Strict DOCTYPE, all it takes is one syntax error and the entire page fails most ungracefully.

    Only if you’re using an XHTML strict doctype and serving your page up as proper XHTML (mime type = application/xml+xhtml) with its more draconian error handling. And if you’re doing that then you’d need to be using content negotiation for IE anyway. XHTML served as text/html won’t fail badly and neither will HTML 4.0 pages. The pages might not validate, but they won’t fall apart. Sounds like you’re making things more difficult for yourself than they need to be.

    Since there should be only one <h1> in a page it does not need an id

    Not necessarily. You might use a h1 for the title of your site on the site’s home page but on internal pages use the h1 as the page title with the site’s title then being wrapped in a different tag. Rather than have two style rules for each different element, if you give the site title an ID, you only need to write the rule once. It also means that on internal pages that if you use a <p> or <div> for the site title that it won’t get confused with other similar elements in the header.

  22. 22

    So you guys do not draw tabular datas into tables?

  23. 23

    Great post Chris, thanks.

  24. 24

    Derek McDonald

    November 12, 2008 5:01 pm

    I love clean code and whenever I develop anything I always make sure the code is readable and well commented. I find that it helps to have clean code to easily fix problems that may occur when the code is rendered.

    Great list of helpful tips there but don’t forget people that both javascript and css also need to be nice and clean too.

  25. 25

    Great article. Thanks.

  26. 26

    Louise Huntley

    November 12, 2008 6:05 pm

    Great list, but I also disagree (somewhat) in regards to the naming conventions. “Sidebar” and “footer” have become so popular that we tend to forget that they are actually describing the style, or at least the layout more than they describe the content.

    Consider what content is going to go into those sections and name them accordingly. Try “secondary-content” or “supporting-information” or “calls-to-action” for “sidebar”, and “company-information” or “legal” for the footer.

    I’d also go so far as to say that “container”, another very popular class/id name, is also layout specific and should probably be replaced with the name of your website – div id=””.

  27. 27


    You should be sanitizing user input anyway so if a wayward & slips by you that is your fault. An ampersand is mos’ def’ a quite common replacement for and.

  28. 28

    Nice article Chris! I once was guilty of all these! But i’m improving thanks to you and other bloggers around the web!

    If you use php you can simply use the htmlspecialchars() function, which cleans all the special chars LOL

  29. 29

    Chris excellent article. You covered all the major points.

  30. 30

    Excellent. Thank you. I make many of these mistakes – (past tense}.

  31. 31

    Very weak. Strict still validates when using tables for layout. The difference is that in Strict you cannot declare css values as attributes


    I'm a div tag

  32. 32

    This was an excellent post. Well written, and very informative.

  33. 33

    Wow, nice blog – it doesn’t even encode my (x)html – let’s try this again:


    <div align="center">I'm a div tag</div>

  34. 34

    I actually disagree with a lot of the content. You know why people use tables to layout content? Because it’s intuitive, simple and self contained. While there’s a lot of merit in code isolation (particularly for re-use and robustness), there is little reason for many people to use CSS to layout their page.

    Another reason for code going directly into files is Dreamweaver and you know what – it works and people don’t care, in fact, why should they?

    I agree with points 3 and 11 on formatting code, but as another newsflash – people were doing this before blogs were around to tell them about it. In fact in my first year studying Computer Science at uni, I got marks for code style – formatting, indenting, comments. I’m also a fan of verbose variable names – take a look at Apple’s extensive design guidelines for more examples of that.

  35. 35

    The {text-transform: uppercase;} property works great for English text, but fails to transform foreign characters (such as ö -> Ö, å -> Å) for other languages.

  36. 36
  37. 37

    Nice article, good refresher for somebody who is coming back from a mini-vacation ;)

    I’ve seen more and more of these bad practices put into place. Especially ones like #6 & #7. Although, to add onto #7 I would prefer to name it based off the type of color it is – primary, highlight, shadows, etc in addition to what it is (subNav)

    Validating your markup is a bit, well, overrated. When some browsers *cough* IE *cough* still don’t display the page correctly, even when everything is valid – what’s the point of going the extra mile? Now, I do think that web pages need to be properly coded – like properly closing tags & attributes.

    P.S. – Did you ever look at SM’s css? “#leftcolumn”, “#footer .foologo” foo? Seriously?

  38. 38

    I’ve been doing these ever since i began, and i get all of my friends who are starting to codelike this aswell, it just looks soo much better.

    And i agree, that little green text does give a nice warm feeling :)

  39. 39

    Nice post! This will guide me even further in making web designs in the future!


  40. 40

    Nitesh (Web Designer)

    November 12, 2008 10:07 pm

    Well explained.. cleared concepts of writing new html code… 10 out of 10 marks…

  41. 41

    Nice post! Thanks.

  42. 42

    It’s nice…….but very difficult to apply STRICT markup……when we are working on CMS’s…………end user doesn’t think about this..

    Well it’s nice post!


  43. 43

    I agree upon Strict but Transitional may be needed when e.g. using iframes (like Google map). It shall fade into the past when object finally renders properly in most browsers, but not today.. not today.

    And I believe 10. consists 5. (any validation points badly nested tags, right? – of course the rules should be applied while coding – it measures our skill and saves time – but if validation is mentioned I guess it serves a higher purpose than just pointing badly ended tags).

  44. 44

    HEALTH ADVISORY: “Non-acute Divitis can also be an advantage in the long term”

    Allow me to present a relatively weak but sound argument for the benefits of issue 6: Indeed, “Divitis” can result in a proliferation of div tags, and a lengthier HTML code. However, one long term benefit of the disease is the fact that the wrapping div can act as a great facilitator when using javascript frameworks (mootools, jquery, prototype).

    Having named divs wrapping interface elements (even if the div does not server any CSS purpose) can sometimes be a good thing. It will allow the developer to easily implement future JS framework goodness (slides, arbitrary selections, animation etc) without the need to re-edit the code or worry whether the ul element has defined dimensions, is absolutely or relatively positioned, IE’s hasLayout is applied etc, etc.

    Indeed, in the example presented, there’s no need to keep div id=”topNav” since if we need to refer to the li or a tags of the nested ul we can simply use $(‘bigBarNavigation’). However, if in the future we wanted to play around with the idea of a sliding or revealing menu, and if we assumed that topNav is a styled menu with display:inline or float:left li elements, it would be easier to apply the animation to the topNav div instead of the bigBarNavigation ul (despite the fact that it’s a block level element).

    Just my 2 cents…

  45. 45

    Great article! Back to basics.

  46. 46

    Basic but nice post.

  47. 47

    Thanks man, great article. Saved in my bookmarks…

  48. 48

    Jeah, pretty cool!

    All newbies will love this ;)
    I will show this article some of my trainies!

  49. 49

    About ’11. Logical ordering’
    what you mean by ‘logical order’, visual one? I meam:
    1- Header
    2- Content
    3- Columm
    4- Footer
    this is the order while displaying the web but for SEO purposes (place the main content up as possible in markup) the logical order can be:
    1- Content
    2- Columm
    3- Footer
    4- Header
    Yes, it can confuse a bit while working it but remember that uploading a web to server and make it alive is not the last step, is just the begining of the adventure and search engines are going to crawl your site so better serve it the best way or your work will be for nothing in most of the cases.

  50. 50

    @Parker control the user output so that it validates to a STRICT doctype. Don’t just fall back to a TRANSITIONAL doctype. That’s just plain lazy.

    @Mukesh What CMS? If you’re using one that won’t produce valid code or a STRICT doctype get rid immediately. Again that’s just being lazy.


    I disagree with #7, there is nothing wrong with the class “Red” if it is defined as { color: red; }. In that instance, it is the most descriptive it can be, and if you change your design, you wouldn’t change it to be defined differently, you would apply “Blue” as a class instead.

    That’s just daft – now you’ve got to go back through your 2 million page website and remove class=”red”. If you gave it a more descriptive name , then you’d only have to change the colour in the CSS. Or don’t give it a class at all!

    The whole point of using CSS and X/HTML is to reduce the markup in your X/HTML – so utilise as many of the built in features as possible. See example:

    li one
    li two
    li a three

    Would you give the anchor a class of red? Why? Wouldn’t this be better? You could style it like this?

    div ul a {
    color: red;

    You’ve then only got to change the CSS, utilising the power of CSS and X/HTML.

  51. 51

    Good vibes here

  52. 52

    A very usefull article, thanks!

  53. 53

    Awesome post, really nice to read with some interesting points in it…

  54. 54

    @Lee #30: Let go the 90’s – It’s 2008 now!

    Nice article though!

  55. 55

    Great post, it totally aproves that I work the right way :)

  56. 56

    As a 5 year CSS bod myself I have to say that this must be the best Smashing article on CSS for beginners I have read to date.

    Good job old chap!

  57. 57

    Stating the obvious?!
    It’s funny to watch the same stuff over and over again.
    Seriously most of these practices have vanished the last years.
    There’re always going to be some guys using tables, coz they are convinced that’s the way to go. You’re not going to convince those ppl by labeling tables as “bad practices” without proper reasoning. And there are indeed as many positive as negative points for both sides.
    The only reason why people should adjust to CSS is because while tables have reached their potential, CSS is still getting improved.

    @David – Can you imagine having a large-scale website and editing every single class attribute when there’s about a thousand of them…well you might, but you gotta agree it’d be easier to just edit some properties in the CSS file. And there’s no proper reasoning why you wouldn’t use a classname with meaning. If everything important for example is red…use important as a class name…why wouldn’ t you?

    Hopefully CSS3 or something else is coming out soon, otherwise we’ll keep reading these “good practices”-fillers as long as there is nothing new to write about on the Web.

  58. 58

    Michael Taylor

    November 13, 2008 1:30 am


    “It’s like crossing the streams in Ghostbusters. It’s just not a good idea.”

    Quality analogy.
    Most of the points are just common sense but #8 is a new concept to me, I’ve never thought of using the CSS to change the case of text before, thanks for the informative post.

  59. 59

    div in li? you gotta be kidding.

  60. 60

    Awesome post! #5 was an eye opener!

  61. 61

    Moderate divitis is not to be feared – it is entirely compatible with the whole point of CSS, separating content and presentation, and should be welcomed. If you’re changing layout somewhere down the line, you may well need another containing div in order to add additional layout behaviour, not to mention avoiding buggy browser behaviour. If you have to go back and add these extra divs to your XHTML, that’s a failure in the very principle you’re advocating the use of CSS for. You need look no further than the Zen Garden to see this demonstrated perfectly – they even make a note to that effect in their guidelines for contributors.

  62. 62

    Excellent article.

  63. 63

    Lets not forget that properly formatted, streamlined code is also more compact in file size and nicer to the world!

    Excellent article. Well written and presented. It’s about time we had articles of this quality on smashing magazine. Don’t get me wrong, posts about “The 50 most beautiful this and that” are all well and good for inspiration but articles on good practise are also a great tool to have. Keep up the good work and I hope it helps make the HTML world a cleaner, more logcal place to work in.

  64. 64

    Francesco Camarlinghi

    November 13, 2008 2:20 am

    Nice post for beginners. Another good principle is to use lists (both ordered and unordered) when possible instead of divs. E.g.: a menu can be done with an ul element as it is a list of links, same goes for a category list, a post list, etc. The list of cats (#12) should have been done in that way too.

    – Francesco

  65. 65

    Mike Archibald

    November 13, 2008 3:15 am

    Great post! I can check 9 out of 10 most of the time, but it did remind my of one small point I’ve been forgetting and that’s to use text-transform: uppercase;

  66. 66

    What font are you using for the handwritten comments?
    Nice post!

  67. 67

    A useful and well written article. Thanks!

    You also included some great resource links and made me laugh a few times, too! (“It’s like crossing the streams in Ghostbusters. It’s just not a good idea.” Heh!)

  68. 68

    Fantastic post

  69. 69

    it is a great list…!
    let’s do it strict baby ;)

  70. 70

    simple stuffs but very useful!

  71. 71

    Bruno Alberto Byington Neto De Figueiredo

    November 13, 2008 4:48 am

    awww, so cute. Im one of those Geeks who went from XHTML and CSS to DHTML to Pythong (Django) and its always such a pleasure to get to know people who dig standards as I always tried to. Feel umarmed and together our creative geeky but powerful network will rise.

    sorry Im feeling kind of emotional,


  72. 72

    The #8 rule must be applied to the #3 example (uppercase text). ;-)
    Great article. Thanks

  73. 73

    I don’t really agree with the body id thing. Or maybe I am thinking of this the wrong way. Can’t you just write

    body #div1 {

    body #div2 {


    Other than that I completely agree with the other topics. Good work!

  74. 74

    Very nice article, Chris!
    I’m really glad about your first rule because I see more and more Transitional Doctypes but I don’t know why it’s used, no reason for doing that. Transitional is a Doctype for the transition between old and new Markup, it’s been developed to be mostly compatible but it’s not for new websites.
    On my own website I’ve written an article about the same issue and now I’m very pleased to see it on a very huge blog. May it help to make the Web better! ;-)

  75. 75

    nice article
    i wish you make another one on DOCTYPEs

  76. 76

    I agree that if something looks clean and slick, most of the time it is slick.
    However, I’ve heard enough of people trying to tell me that something is just “bad practice” only because it’s engraved in the holy grail of web design. That sounds quite religious..

    If something works for the majority of users , it’s good practice.

  77. 77

    Nice article …
    I would suggest to optimize your images ( – for people who don’t it’s the best tool for optimizing your images
    And also measure your site with YSlow, see how fast it is, what you did wrong and what you did good and how to improve it

    All these … thanks to yahoo and Stoyan S.

  78. 78

    Great Article Chris! I will start using strict from now on in my client’s websites…

  79. 79

    Thanks Smashi! :-)

  80. 80

    On point 11, it might be interesting to put the menu at the bottom of the code and the put it on the top of the page with CSS. This will be good for your referencing. But maybe not for people who use text-readers browsers… Have fun !

  81. 81

    What I really liked about this article was the comments. It’s nice to hear other peoples opinions. Sometimes there really is two ways of doing the same thing. Thanks!

  82. 82

    heather van de mark

    November 13, 2008 7:10 am

    I haven’t finished reading this article yet, but props for the handwritten script. It really makes this more interesting to read/look at visually. Thank you for not making this boring, otherwise I would have skipped right over it!

  83. 83

    Nice post, grats!

  84. 84

    Not necessarily. You might use a h1 for the title of your site on the site’s home page but on internal pages use the h1 as the page title with the site’s title then being wrapped in a different tag. Rather than have two style rules for each different element, if you give the site title an ID, you only need to write the rule once. It also means that on internal pages that if you use a p or div for the site title that it won’t get confused with other similar elements in the header.
    One of the authors key points was to define a class for body, so you can distinguish the content styling for h1 ones using the body class. This way you still only have one h1 per page.
    body.main h1
    body.home h1

  85. 85

    Real Quick on the DOCTYPE thingy – Transitional is not always a bad choice – you have to consider sites that might need to embed code (i.e. YouTube videos, etc.) from a third-party site that may not be Strict compliant and will break validation tests in Strict. Another example might be a site that depends on an underlying CMS.

    Also, many of the popular Javascript libraries (i.e. MooTools, JQuery, et al) are intended to work with XHTML – so there is a good reason at times to pick that over just plain old HTML.

  86. 86

    Ironically enough, there are 14 errors when you validate this page….violation of number 10.

  87. 87

    Great post. I practice most of these regularly, but every once in a while I find my code getting sloppy. It’s always good to go back and reinforce good habits.

    Beginning HTML/CSS coders take heed!

  88. 88

    Sai Gudigundla

    November 13, 2008 7:41 am

    Thanks for yet another great article.

  89. 89

    nice post! unlike before where we just manually type everything, right now with the influx of tools that automatically generates html/css, i see this to be a challenge. it would be good practice to follow this esp when you’re in a consulting company and you’ll eventually transition your codes to another person, following a standard, and having a clean code (plus proper docos) is always a good practice!

  90. 90

    Michael: CSS currently does not allow for vertical alignment for block level elements except for TD’s. So if you want something centered vertically on your page your only option is to use a table – or if you are centering a single-line inline element, you can fake it by setting line-height.

  91. 91

    Good post !!

  92. 92

    Ironic how this article’s own page is transitional and not strict!

  93. 93

    I can really see how most of your tips are useful. I agree with most of them. However I don’t think it’s good to say that you can not, of should not use unlinked JavaScript / CSS. There is a reason when you should use CSS / JavaScript internal:

    View source of, all CSS and JavaScript (well, most) is included in the index file. I have heard Nate Koechley speak on why yahoo did such a thing, it all had to do with loading time of the page. Every CSS/JavaScript file is an other server request. And if you are having a lot of traffic on your site (which yahoo, of course, does) than it pais not to link to it but render it into the HTML file.

    So, there you have it, someone elses point ;-) For me it’s not a good idea to have internal CSS/JavaScript, just because I don’t have a high traffic site. But, if you do, it’s worth a shot!

  94. 94

    Very nice article…

    – Josso

  95. 95

    *YAWN* Can we please stop calling CSS and HTML “code”. HTML = HyperText Markup Language – It’s a MARK UP LANGUAGE!!!!!!!!! There’s is no logic to CSS and HTML layouts, Puuuleeeezzzeeee – C is code, Perl is code, PHP is code, XCode is code, Java is code, Javascript is code — hey u guys really want to build a web page using Code – use Javascript – all this self patting in the back for what any 6th grader taking a computer science class can do using DreamWeaver is ridiculous. Those who create their pages using VI, VIM, PICO, Notepad or any text editor are a step up above you clowns but still by no means are they “coders”. WHen you guys start buiding insane web applications that combine CSS, HTML, Javascript, PHP, back end chron scripts, integrating C code into your PHP build, MySQL, FLEX, Actionscript cohesively – then, then maybe you can start discussin the merits of “clean code” as it it applies to web development not just simply laying out a pretty web page in photoshop, slicing the images, and then using CSS and HTML to lay them out—- thats not coding— not code — code it is not.

  96. 96

    The {text-transform: uppercase;} property works great for English text, but fails to transform foreign characters (such as ö -> Ö, å -> Å) for other languages.

    I use {text-transform: uppercase;} often, and most webbrowsers do this pretty good: In Firefox it’s not only transforming the umlauts but even ß to SS.
    @ E to hte G
    I think it’s cron not chron, isn’t it?

  97. 97

    Unless you’re working on a small website, validation is not compulsory, otherwise you’re gonna end crazy trying to correct all errors.

    I’d say, if you keep only one rule from the twelves, it is #5

    Remember that you want your website to work well in IE, Firefox and Safari. So I’d advice to test your page on multiple browser long before taking care of details like encoding characters
    And having well nesting tags (rule #5) helps a lot when it comes to make your page multi-browser compliant.

  98. 98

    mainContent-500 is not a semantic class name – it’s as bad as “red italic”, used as an example by you earlier.

  99. 99

    @E to the G

    Actually I wouldn’t call Javascript “code” either. It’s a scripting language. Script, not code. But a lot of the same “good practices” applies to both script and code. And even mark-up.

    And if you think there’s no logic to HTML then you’re doing somethng wrong… HTML should be semantic

  100. 100

    Jeremy: tables aren’t the only option for vertically centering elements – a combination of nesting absolute and relative positioned elements, and a top: 50%; works, although admittedly it is harder to explain how to pull it off than valign=”center”.

  101. 101

    Chris Luckhardt

    November 13, 2008 8:52 am

    @John Faulds

    Using one H1 tag is a generally accepted SEO practice. It optimizes your search results and clarifies what the actual page title is.

  102. 102

    Linda OMG are you seriously saying semantic HTML is somehow tied into logic – Logic for me means trying to figure out the precise, correct method for handling use case scenaraios as they pertain to an application. It’s about writing re-usable code that passes unit testing. It’s figuring out the flow of the processes and figuring out all the multiple instances in which that processes might break and fixing that – logic does not meant using “cite” in place of “i” for emphasizing the title of a book in HTML. That’s just good sense, that’s just following W3C standards. Oh and calling Javascript a “scripting” language is correct, but what I meant to say is that you can PROGRAM in javascript which makes it code. Can you program in HTML?

  103. 103

    I find that the most common reason for a ‘divitus’ wrapper on unordered / ordered lists is because each browser has it’s own formatting (margins, padding, etc) on lists. I wouldn’t trust the <ul> tag on it’s own in my layout. What’s more, the ‘div’ tag should be used to divide a section from the rest of the layout / content, and if you’re making a navigation section, that’s usually put in a ‘div’ as it’s more likely than not containing more elements than just an unordered list.

  104. 104

    great post. I agree with all the point that you made. I would also like to insert a new point on avoiding CSS hacks for specific browsers/versions. If you need hacks, odds are your doing something un-needed.

  105. 105

    Hi Chris,

    Thank you so much for sharing these points. I’m a beginner in web development/design. Pretty useful.

    Thanks again.

  106. 106

    retard stuff for beginners. thanks for wasting my time

  107. 107

    excellent post. thanks a lot for sharing!

  108. 108

    Fredrik Carlsson

    November 13, 2008 10:13 am

    …about #2

    I read somewhere that using the title tag first gives a small bump with search engines and since reloading a few lines is not that big a deal, you should go with title first.

    Anyone know if this is true?

  109. 109

    “great for beginners”

    Why are there so many douchebags who feel the need to make it clear that they are *so* much more advanced than this mundane post. Grow up, children!

  110. 110

    Validating your markup is a bit, well, overrated. When some browsers *cough* IE *cough* still don’t display the page correctly, even when everything is valid – what’s the point of going the extra mile? Now, I do think that web pages need to be properly coded – like properly closing tags & attributes.

    It’s not overrated if you just take it is. Validating your code isn’t there to help you achieve cross browser compatibility, it’s there to help you clean up your code. It’s entirely possible to create a new .html page with 100% valid code an have it display horribly (and differently) in different browsers.

  111. 111

    Let’s examine the site this is stated on:

    1. Doc type: XHTML 1.0 Transitional

    3. Uh, check the indention of this site…

    4. Lots and lots of inline styling

    5. Didn’t want to check for badly properly tags

    9. Hrmp… the id of the body element is ‘css’… good choice of name and what is this that is just after ?

  112. 112

    Good stuff, I think #1 is a bit misleading though… probably at least 95% of sites that use XHTML strict actually aren’t serving it up to specification… so in an attempt to adapt the latest standards and follow everything to the letter, it turns out to be fairly counterproductive… HTML strict could work though, but I opt for XHTML transitional (even though I write strict code), for the simple reason that some browsers (namely IE) won’t even render the page if the XHTML specifications are strictly followed.

  113. 113

    Fantastic article. Very helpful. Cheers.

  114. 114

    This is a fantastic post and really helps a lot.

    Unfortunately it serves equally to inflate the massive ego of those who are no longer beginners and therefore do not need the information which they once did, like others do now. They really should grow up. Regardless of their skills, they are just proving themselves to be a total waste of space.

  115. 115

    What a beautiful and easy way to present your point! I totally loved reading through this and had to say it even though usually I am a full on lurker.

  116. 116

    Nice article, I found it very usefull for some friends that are in charge of doing the markup in a project of ours.

    Anyway, I don’t agree with giving the body an id/class, when you have a site that uses the same (or almost) header and footer, it’s a really good practice to keep those files separate in a folder, like includes, so you can include them in the pages that uses them, so the body tag and sometimes even the navigation (and maybe some other stuff) is left in the header file.

    Despite that, I think is a good article for beginners.

  117. 117

    Nice article, although I have a few points regarding tables:

    Tables are allowed in Strict XHTML, they’re not disallowed in any instance to do with code validation. They are however frowned upon when used for layout, as they can present an accessibility issue. Non-tabular content displayed in tables for a screen reader means it could get read out in a very different order than it appears on the page. Having multiple table columns with large amounts of content in each could mean it doesn’t display correctly on Mobile Devices, or can’t fit on an A4 piece of paper when printed. There’s many reasons why table tags should not abuse, even though it can make construction of HTML templates much easier.

  118. 118

    find ./ -name *.html -exec sed -i 's/class="red"/color="blue"/g' {} ;

    Will replace all occurences of class="red" with class="blue"

    Learn how to use the fundamental tools and your life will be a lot easier. I do agree that class="red" is a bad idea BTW.

  119. 119

    These are great hints to writing code well.
    They will keep my code clean for sure.

  120. 120

    Thomas Dedericks

    November 13, 2008 12:20 pm

    Hi. Nice post, but I have to disagree on some points.

    Rule 1 seems unrealistic to me. When you work for a client, you have to accept some constraints. What will you do if he wants some links to open in a new window ? Beat him with your laptop because it’s a bad pratice ? Use JavaScript to open a new window (eeeeek) ?

    Sometimes, transitional doctype is just the right choice. And there’s nothing wrong about that. Keep your HTML clean, use CSS styles and document everything correctly. Who cares if your doctype isn’t strict, really ?

    Rules 2 & 5 aren’t needed if you apply #10 ;)

  121. 121

    This article was just what I was looking for! Very Helpful! :]

  122. 122

    Your advertisement columns are ridiculous. On a normal width browser window they take up half of the screen! It blocks out your nice article on how to design webpages…

  123. 123

    You seem to have confused markup language with code.

    html != code

  124. 124

    Seems like someone is really eager to get their article listed on digg. This article has all the symptoms…

  125. 125

    Thank you for taking the time to create this article. While some of the experienced persons replying think this was a waste of their time…others of us find it encouraging that there are references out there to help the infants of the group find their legs, and learn to walk properly without dragging a limb behind them. It also helps us all to review the basics on occasion, to ensure we aren’t straying from the path.

    While I don’t agree with all of your points, as someone who has been working with web markup/scripting/coding/et al. since BLINK was a pup, the theme that one should always follow a set of standards cannot be drummed upon enough. Far too often, I find myself cringing when I open the pages created by my predecessor, because it is inconsistent, poorly formatted, has no thought process applied to layout and for a myriad of other reasons. If you are unable to apply basic rules to your coding style in the most basic pages, then once server side languages such as PHP are interjected, your code will degrade even faster.

  126. 126

    You forgot the golden rule:
    If you are smart, use tables instead of CSS for layouts…then you can get back to making shit instead of dealing with shotty implementations.

  127. 127

    I’ll have to disagree with “11. Logical ordering”.

    See, when Search Engines scan your page for content, they look at your code from top to bottom. This is why you want the parts of your code containing your most keywords to be at the top.

    True, it seems more logical to have your #footer at the bottom, but sometimes for SEO purpose it is better to have it right after your and then using CSS, place it at the bottom of your page.

    Then again, like the last point says, do what you can!

  128. 128

    1) No “format for print” option = epic fail.
    2) Fully half your blog content area devoted to something other than actual content = weak.
    Good article though.

  129. 129

    Yes this article is basic for most Computer Programmers who deal with C, Perl, JavaScript, PHP, ASP, and other back end total scripting and coding languages. For those who do not use those languages, who do not have the need for databases or hard core programming languages, these are meant to be useful for general mark up.
    No it does not apply to the hard core coders and programmers. It is not meant to be. If you know all that stuff more power to you. No, actually, not more power, just good for you for being able to knowing those languages.
    But going to a post that is supposed to help people, then completely bashing it because it is not a hardcore programming article is not called for. These may be basic principles, but that is all they are meant to be. Some people may agree or disagree with some of this stuff. So be it. If you take something good away from it than it served its purpose. If not then go on doing what you do. Don’t go on here, bash people and fight over it. That is just stupid and childish.

  130. 130

    RE: “Moderate divitis is not to be feared”

    You need look no further than the Zen Garden to see this demonstrated perfectly – they even make a note to that effect in their guidelines for contributors.

    Even Dave Shea says that they would do things differently now. When they created the Zen Garden, the CSS landscape looked different, and they didn’t have the tools/techniques that we take for granted now.

    RE: Styles/Javascript in the header
    An additional reason to keep the javascript/css external is that it can then be cached, saving additional load times for internal pages.

    And if everyone hot linked to Google for their jQuery, everyone would have the same item in their cache, speeding up the intarwebs for everyone.

  131. 131

    oh great another newbie tutorial on what not to do. How about some actual useful items?

  132. 132

    @ David Well, in that instance, every instance of the “Red” class will be red, so why is that a worse name than describing the content?

    Your HTML should be semantic, meaning you want to describe your classes in a way that explains why it’s red. Is it red because it’s an alert? class='alert'. Or is it red because it’s an extra important link? class='important' .

    My question relates to the order of your content. Semantically should you put the navigation before or after the content. The content is what the reader is on the page for and for those browsing on mobile devices it makes it much easier.

  133. 133

    A lot sites on the net use rendered output which may be messy, but who cares, your there to use the site not inspect the code behind.

    Setting DOCTYPE to strict is silly.

    The best rule to follow is, if it displays and works properly in all major browsers then your done. Following a strict standard does nothing for you.

  134. 134

    lol Jonny Haynes, you said everything I wanted to say.

    It’s amazing how most people’s excuses are “It’s too hard”

    It’s even more amazing how people are actually arguing that using tables to design a layout is the smarter way to go. Lol Mainly because they are lazy.

    Amazing, simply amazing. Read a book people.

  135. 135

    People follow people.

    A few people say don’t use tables, then some more people follow eventually opinions change. You silly sheep!

  136. 136

    Enough with validation

    Validation is bullshit in a finished site.

    While I strongly advocate validation when building the site (that missing closing brace just might be wiping out your css), I believe that a site that’s gone live should always have perfect validation. Validations are guidelines, not laws.

    I’m sick of people who must validate. It constrains people and limits freedom. Say you want to use CSS3 attributes for an added effect or just to get a browser to behave. Why throw it away for something as silly as validation?

    Strict adherence to rules -> no change
    With no change there’s no innovation

    Look at the empirics. Almost no successful site validates, especially if you validate them based on Strict validation.

    And I laugh at people who tell others not to use tables. Think of the new web designers. You tell them tables are a sin and they will never use tables again. When they want to make a calendar they will make it a mess full of divs. When they want to show tabular data the html will be barely comprehensible. I design using CSS layouts by choice because tables are too rigid. CSS is flexible. I can throw elements all over the browser window using CSS. But you know what’s a bitch? Equal height columns. Table layouts made many things easy. CSS just brings more benefits.

  137. 137

    I’m confused on point 6. Eliminate unnecessary divs.
    Isn’t the top div a hold for the Navigation bar?
    I checked Chris website, he is doing the same as what he’s written here in the sample.
    Did I miss out anything?
    Can anyone remind me on this?

  138. 138

    Nice pointers! But why is this website still using a transitional doc type?

  139. 139

    Excellent article! Thank you

  140. 140

    can u tell me “!important” in css

    how it will use

  141. 141

    @E to the G: why shall we stop calling HTML code? Well, it’s not a programming language but it’s still code. Code is just a rule for converting information into another kind of information and it has nothing to do with logic. So HTML, XML, CSS, JSON, LaTEX, RTF and ODF are code. ASCII, UTF-8, ISO-8859-1 etc.are code as well. Everything is code. ;-)

  142. 142

    Using tables for layout is like drinking tea from a bedpan – you won’t spill any but yer fellow designer will think your taking the p*ss. Think of what screen readers will make of it all!

  143. 143

    Nice set of tips here, I strongly agree about the importance of getting the basics right.

  144. 144

    useful sharing thanks for it

  145. 145

    Working in an enterprise that deals with many websites and millions of pages I can attest to the value of these best practices.

    Semantic id’s and classes are good because they help new developers understand the use of particular elements better than “bold_left_red” imparts that knowledge. It also allows for flexibility as designs change over time and different audiences shape the look and feel of a site.

    Tables are bad because you have to take extra steps to ensure accessibility devices understand the structure. It’s more difficult to use tables to layout a search engine friendly site (content first, navigation second). It takes extra markup in the form of table nesting, spacer images, and non-breaking spaces to get everything to appear correctly. Tables set you into a rigid path which may exclude your side being usable to mobile devices.

    If you are using a template language and breaking up your layout into component templates those templates may end up being invalid depending on where you are trying to slice and dice your design. I see this most often with JSP where one JSP starts a table and another JSP ends it.

    Using tables for a quick gain up front will cost you more later down the line when you need to redesign a site, cobrand, or internationalize.

    I’ve never seen tables as an intuitive way to layout a page and I fail to see the logic of that mindset unless you are using a WYSIWYG tool as your primary way of developing pages. If that is the case then it’s unlikely that you would care about any of the above tips because you aren’t a person who cares about the markup.

    Regexp and automated find and replace methods are hit or miss and can’t cover the complexity of a modern enterprise website. Changing “red” class to “blue” might work as a very simple case but there’s also a possibility that you break something because the tool isn’t specific enough or someone is using “red” on a different bit of content than you expect them to. Plus the time it takes to get the code right, test it, and run the conversion you might as well have just spent that time on doing things the right way.

    A problem with the idea of automating thousands of changes across a site is risk. With each code change you introduce the risk of defect. By separating concerns and keeping layout in one set of files and structure in another you limit the number of files that need to change and reduce risk. At the same time you reduce QA hours, reduce auditing requirements, reduce version control file space consumed, reduce the number of files synchronized to the server, reduce bandwidth consumed, etc.,.

    Having styles and behavior in separate files is good, specifically in the case that something goes wrong. If you’ve done your job right and the look and feel doesn’t make it to the user because of a failure or because of a choice made by the user, then all of your content should still be there easy to read and ready to use, using the default markup styles provided by HTML. The problem is that most people don’t ensure that their content is solid before adding style and behavior.

  146. 146

    Most of the things are the ones I do normally except I narrowColumn to squeeze the width in and keep the main id for the logical stuff is very neat allows for some sweet jQuery transformations to your page.

    Thanks for the article.

  147. 147

    For step 2: Converting the code
    EG: & to &
    The following tool may be of use to many;

  148. 148

    Very Very Interesting!!!!!!!!!!!

  149. 149

    Really Nice.

  150. 150

    very useful

  151. 151

    Mohammad Alshaikh

    November 14, 2008 11:32 pm

    very nice..
    i do them all..
    that means my HTML is perfect..
    but i dont class/id the body..

  152. 152

    Very useful Chris! Basic concepts which a web developer should know about.

    The ‘charset=iso-8859-1‘ parameter is used so that the special characters in text are not transformed.
    Characters like “less than sign, single/double quotes, etc.” these get printed as ‘?‘.
    To avoid this change the parameter in meta tag – charset=utf-8 to charset=iso-8859-1.

    Cris correct me if i’m wrong :)

  153. 153

    8. Leave typography to the CSS

    This is for English or uppercase supported languages. Turkish and many other languages are not supported by uppercase.

  154. 154

    Great post!…… really nice and useful tips……… thank you…..

  155. 155

    the doctype of this page is transitional!

  156. 156

    Great post… it’s cool. Thank you.

  157. 157

    It’s beautiful that I will realize the principles when coding.
    Merci Beaucoup.

  158. 158

    Really Nice.

  159. 159

    Very good post dear

  160. 160

    Great Post. Thanks!

  161. 161

    thanks, a really good post here!

  162. 162

    Nice tips.. #8 is seems to be the thing i always forgot.. heheh thanks

  163. 163

    OK, all this is good, and I practice what you preach actually. But can someone tell me how to validate in STRICT doctype when using Jump out of this site xHTML Strict doesn’t allow the “target” element.

  164. 164

    < a href="" target="_blank">link</a< is what i wanted to type.

  165. 165

    excellent article

  166. 166

    Ever tried doing target=”_blank” (etc.) in a strict document type?

  167. 167

    Why should I commet my html when I have Firebug. Even correct indentation is somehow absolete. Firebug does that for you so I just need to make sure the html is not to messy.

  168. 168

    nice article, but geared towards beginners…

  169. 169

    Wouldn’t it actually be better to use all caps in the markup versus text-transform CSS property? Sounds like unnecessary processing to me.

  170. 170

    The “target” element is not allowed for simple reasons.
    Some explorers like ie6 don’t use tabs. A “_blank” link open a new window and it’s really messy.
    It’s really messy too for the people who navigate with speech synthesis. The linear navigation is really important for this users.
    To open a link in a new window you might use java script like that : link
    Java script may be disable for users who don’t use it.
    In this way you keep a valid document in xhtml 1.0 strict.

    cheers from france

  171. 171

    @E to the G

    Xcode isn’t a language.

  172. 172

    #7 Made me realize a few things. I’ve always wondered what good naming conventions are, what to focus on when creating classnames, and it just made sense when I read your points.

    Thanks for making my day.

  173. 173

    I had a lump in my throat when I started reading this, but I realized afterwards that my HTML coding methods aren’t as shabby as I thought. Thank you Smashing Magazine for making me feel better.

  174. 174

    André Faria Gomes

    November 23, 2008 5:36 am

    Good tips.
    Nice post!

  175. 175

    It’s beautiful that I will realize the principles when coding.

    Kudaravalli’s from HYD (INDIA)

  176. 176

    wonderful article. May I translate it into Chinese version?

  177. 177

    You don’t really need to indent your code anymore, except for your own use. If you want anyone to read your code, let them use Firebug anyway.

    In my case, for example, PHP produces my HTML, so I indent the HTML according to what’ll make the PHP look pretty, even if the HTML’s indentation comes out ugly. Nobody looks at it anyway.

  178. 178

    and what body id gives you is the ability to write css for a specific page without making a whole new CSS file for it.

    for example, if you need a wider events page:
    #wrapper { width: 70%; }
    #events #wrapper { width: 80%; }

    where the code for each page is
    <!– dtd, , .. –>
    <body id=””>

    this is more readable than separating the CSS file.

    In multilingual sites I also give the body a class with the language. e.g.:
    .hebrew #navigation { margin-right: 2em; }
    .english #navigation { margin-left: 2em; }
    for code <body id=”” class=””>.

  179. 179

    oh shoot the code came out wrong. but you understand what i meant, i hope..
    if not, write me at xnahbdnd at ailag dot net for further discussion.

  180. 180

    awesome post!

  181. 181

    wow! I think ‘E to the G’ need to to take a chill pill or something, he is getting so worked up!

    Relax and get a life dude!

    keep up the good blogs Chris, dont listen to these coding nazis like ‘E to the G’, I think he has a little to much free time on his hands. He strikes me as somebody who likes the sound of their own voice a little too much.

  182. 182

    very informative article.

  183. 183

    Great article, thank you! :)

  184. 184

    Excellent one….. everybody should read this

  185. 185

    Aaron Irizarry

    December 19, 2008 8:46 am

    Great read Chris,
    Thanks for another useful article
    Aaron I

  186. 186

    Great tips..!

    Thank you

  187. 187

    great post, thanks :)

  188. 188

    Murat Göktuna

    December 25, 2008 3:47 am

    Great post!


  189. 189

    The XML prolog in the ‘good’ HTML triggers browsers (even modern ones) into quirks mode. Not what you want. Since the defaults are used (utf-8, stand alone) it can be omitted without problems.

  190. 190

    good things haha

  191. 191

    Decent enough article to state guidelines for common practice. Nothing too intense here, just a “hey, make sure you cross your t’s and dot your i’s”

  192. 192

    Nice list, except I must disagree with point #8. if you use css to change the capitalization, then you go to select/cut/paste the text in the web page, the pasted text will be exactly as it is in the HTML, not as instructed by the css rule(s). This is a deception.

  193. 193

    It’s interesting to see the persnickety assumption from many of the posters here that someone who primarily programs automatically grasps the ins and outs of semantic xhtml and css. I’ve worked with dozens of so-called “hardcore” programmers…many who have been coding website back-end functionality for years…not a one knew/knows all of the basic rules outlined in this article. They couldn’t care less about the front-end, as long as it works. Try to teach a .net developer to ditch the design view and see how far you get.

    Also – I’ve been trying to hire two new people for months. I’ve conducted dozens of interviews, and each person claims to have at least a decade of experience in web development. The first four questions I ask everyone:

    1. Which xhtml tags would you use to wrap these elements, which will be children of the body tag? (on a whiteboard I write ‘About Our Company’, and then on a subsequent line ‘Paragraph text’)

    2. What is the purpose of the DOCTYPE definition?

    3. You are handed an approved creative comp from one of our designers. When you open the PSD, you notice that they decided to include meaningful header text for each page as part of a stylized banner image. How will you construct this element without changing the design?

    4. What is n-tier (or three-tier) architecture?

    Not a single person has answered any of these questions correctly.

  194. 194

    Hi Chris Coyier,
    Very good post, pretty helpful…

  195. 195

    Those seem like pretty reasonable principles that I don’t break to often. Thanks for the list.

  196. 196

    If anything…this has confirmed that clean coding is essential, and not difficult!

  197. 197

    So Good!

  198. 198

    it’s really helpful to us……

  199. 199

    yes its really helpfull for coding

  200. 200

    Really helpful principles, any more?

  201. 201

    Hi there, If you don’t like topics with many links, just delete this topic.

  202. 202

    Nice tips

  203. 203

    i will do all what i can do !
    i love web design !

  204. 204

    I’m no expert at this hense why i’m here but the first thing I noticed when viewing the source code on this page is it’s using Transitional as opposed to Strict???

  205. 205

    I want to quote your post in my blog. It can?
    And you et an account on Twitter?

  206. 206

    Good article. I typically use CSS tools such as the, or, to checking that CSS code I created, it’s very useful tools. Maybe you have a similar validator tools, which apply the 12 principle as above? Thanks

  207. 207

    Very nice article for classroom lessons and newbies! Anything for pros?

  208. 208

    I realized that strict code and markup that completely validates appeals mostly to fresh web designers who are truly looking for direction (normally thinking that there is a winning particular way of doing things on the web.)

    Back to the real world, where you have websites that really serve others out there, its completely unconceivable to think that code will always validate 100%. Besides, clean code should by no means stand in the way of great designs or purpose the site was designed to fulfill.

    Well, I jacked you out, right?

  209. 209

    Also text-transform doesn’t work with other international languages such as Arabic or Japanese. Big problem to rely on when you have a multi-lingual site.

  210. 210

    Great article. I’ve been following some of your articles online and thought I’d chime in with my support for you work! Cheers


  211. 211

    It’s very useful.Thank you !

  212. 212

    Robert {Bryan} Anthony

    February 23, 2011 9:25 am

    Swell Info Here, Chris!

    I’m 20/800 blind attempting code for my FBML, Custom Site Editors, and other pages requiring code. I’m a NEWBIE at the code writing, just enough to get myself into some trouble and wondering how in the world I’m going to FIX what I just messed up!

    My MAC reads to me. However, it’s a NIGHTMARE to get it to read Code for me. Just doesn’t work!!!

    I look forward to discovering more about HOW to write clean code, once I get a better grasp on the concepts, and apply it to my websites and pages. Thank you for the vital info!

    “May you walk in freedom…” – Psalm 119:45

  213. 213

    it‘s so usfull.thank you!

  214. 214

    Breno Martinusso

    May 20, 2011 6:11 am

    I can translate this post in Portuguese and put on my blog? Obviously with that reference.

  215. 215

    This is very useful stuff for a novice like myself, I have found myself making these same mistakes, but reading this article has helped me to look at coding a lot more carefully now.

  216. 216

    You said the first rulel to use “Strict” doctype. But your web site using Transitional …whats this baby…

  217. 217

    The writer of the post doesn’t own the website. xD They contribute articles to it. If you check Chris’s actual website you’ll probably find that he actually does use the correct doctype.

  218. 218

    Christian Rios

    April 27, 2012 10:19 am

    This is pretty good. I liked it. Kudos, Chris.

  219. 219

    Smashing Mag, I love you for this..!

  220. 220

    Interesting staff. Big-ups!!!

  221. 221

    Stuart Blessman

    July 26, 2013 8:38 am

    Is there an updated version of this? Looking for resources while planning a relaunch of an ecommerce site and a few article heavy sites.

  222. 222

    “Our code doesn’t use any tables for layout anyway”!

    This is just silly. Further up we have somebody saying that you are lazy and unprofessional if you use tables.

    The fact is that if you are using “CSS” rather than tables for tabular data, then a worse description in fact fits you.


↑ Back to top