Smashing Magazine - we smash you with the information that will make your life easier. really.

13. Apply the concept of DRY to your websites — use includes for repeating code like navigation, footer, headers, etc.

14. Comment your closing div tags for when you come back to it in the future

**Most times when people don’t use logical ordering it is because they want the most important information at the top of the page for SEO reasons.

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

“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.

Cool… easy and well explained.

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

great for beginners

Something really worth reading and extremely useful..as always Smashing Mag!

I love you guys.

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.

Much thanks to Chris Coyier, the handwritten font is Loved by the King (a great $5 font by Kimberly Geswein).

Good article for Strict basic template building. Thanx

So you guys do not draw tabular datas into tables?
Gosh…

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.

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=”www.mysite.com”.

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

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

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

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

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.

POO!

@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.

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?

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

Thanks!

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

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!

Thanks!

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…

Basic but nice post.
Thanks!

Jeah, pretty cool!

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

@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.

@David

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:


div
ul
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.

A very usefull article, thanks!

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

Nice article though!

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!

Hahaha

“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.

Awesome post! #5 was an eye opener!

Excellent article.

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

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;

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!)

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

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,

Bruno

very informative article.

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! ;-)
Thanks!

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.

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

Thanks Smashi! :-)

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!

Nice post, grats!

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.

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!

How come Smashing Magazine doesn’t practice what they preach? On this very page where you promote clean code, you are breaking many of the rules you outline above.

1. Doc Type is XHTML 1.0 Transitional
2. Outputs 16 Validation Errors
3. Majority of Code not Indented
4. Lots of inline JavaScript

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.

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

Very nice article…

- Josso

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

@Matt.
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?

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

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”.

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?

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.

retard stuff for beginners. thanks for wasting my time

…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?

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.

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.

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.

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.

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.

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 ;)

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…

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

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.

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.

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.

@ DavidWell, 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.

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.

标题很好很强大，内容很黄很暴力

sdsdsdsdsd

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?
Thanks

Excellent article! Thank you

@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. ;-)

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

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.

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

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

very useful

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

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 :)

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

Great post… it’s cool. Thank you.

Really Nice.

Great Post. Thanks!

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

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

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

nice article, but geared towards beginners…

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

@E to the G

Xcode isn’t a language.

#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.

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.

Great post. I love smashingmagzine and thinkflick both have great and original posts

HI.
wonderful article. May I translate it into Chinese version?

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=”">.

awesome post!

very informative article.

Excellent one….. everybody should read this

Great tips..!

Thank you

Great post!

Thanx…

A nice post

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”

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.

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

So Good!

nice

LoooGo

Very verrry good Analysis.
Thanks

Really helpful principles, any more?

Nice tips

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???