Take the 2-minute tour ×
Webmasters Stack Exchange is a question and answer site for pro webmasters. It's 100% free, no registration required.

Here is the summary I've recently learnt from discussions on this site (and similar) of 4 basic rules, so please correct me if I'm wrong or misunderstood something:

a) Don't use IDs in CSS (or use it as few as possible)

b) Use as many descriptive elements as possible such as article, section … instead of div

c) Name classes according to the content, not appearance

d) Don't use too many classes: "Don't give elements a class just because you can. It adds noise." (I don't know how to achieve this one though, because almost every element needs a class. If it's a section, there is another section elsewhere with different looks. Same goes for the article, etc.)

This is kind of "philosophical" question, but the goal is to set some things straight for all readers to benefit; having constantly in mind the rule of separation of content and presentation.

share|improve this question
d) why is that section different? maybe the class shouldn't be on the section, but on its parent container - if a section is different because its article is different, use article.class and article.class section, not article.class and section.class –  HorusKol May 5 at 3:51
For the love of who-ever-you-like, USE ID'S WHEN YOU CAN!. It's the fastest selector in both JS and CSS. The reason is simple: An id is unique. If the browser found it, it doesnt have to check other elements (thus saving time). #LoveIds! (Think a little like MySQL's LIMIT 1) –  Martijn May 5 at 7:37
@HorusKol: Don't use it like that :) Fastest is '.class', not 'div.class' (now it has to check if the class is a div, unneeded), and .class section is even worse, now it selects ALL sections, then matches if they're in .class. Most right selector has to be the most precises :) Tip: Google -> Css Sizzle –  Martijn May 5 at 7:39
@Martijn - comments don't allow space for a lot of nuance, so I went for a simple example. If your design/layout is so complicated that that you are experiencing slowness do to selector usage, then you really should be rethinking your design. Using something like .class section or .class article > section makes for a much more modular CSS design. If your CSS is nothing but ID selectors, then you're going to have an incredibly complex and needlessly redundant pile of styles. –  HorusKol May 5 at 23:40
add comment

3 Answers 3

up vote 4 down vote accepted

a) Use as many as you need but IDs are there for a reason and can serve a purpose. The problem with IDs is the same one might have with global variables in javascript. That one may forget the ID is used on another page causing problems cross-page while coding.

I agree with b and c.

d) will require more thought on my part but this can venture into personal preference and opinion more than fact.

To explain d) further, there are a lot of considerations about class usage for descending elements. Some may say all elements should have a unique class name so you can reference them directly for ease of use and speed of operation like so:


Others say only one parent element needs a class name and we should continue with descendant selectors such as

.myclass {}
.myclass p {}
.myclass p span {}

In the first case, things can get verbose but, in the second case, you have to be concerned that someone may add a property to all span elements you aren't aware of and, thus, have a problem with the cascading of properties and specificity.

At one time, there was concern over speed of operation by the second method because browsers evaluate from right to left but this may have diminished in Chrome (at least. Not sure about other browsers).

share|improve this answer
Thanks. Yes, No.4 sounds like "do the same thing, but with your hands tied" –  Dalibor May 4 at 14:01
@Dalibor I don't know what you mean by that. I'll edit my answer if I can in a few minutes to explain further. –  Rob May 4 at 14:13
Sorry, I made a bad joke. As for your Item 4, second option (parent class, descendant selectors) I read many articles strongly against it. –  Dalibor May 4 at 14:30
In between these two extremes we have stuff like .myclass .statement {} and .myclass .statement em. Which is specific enough to identify element(s) unambiguously, without requiring that every class have its own whole hierarchy of child element classes that apply only within it. –  cHao May 4 at 19:52
add comment

Element ID's

ID Styling

You can use as many ID's as it makes sense too, ID's should be treated singular classes that are not shared with any other element or class. So if you only have one slider gallery per a page then you could use #gallery however if you want to use multiple galleries then ideally you should use unique id's for both i.e #gallery-main #gallery-secondary. Then in your CSS you used shared CSS along with unique i.e


ID Experience

You should be also aware that ID's are useful for enhancing the user experience for your users with 'go tos' i.e

<a href="#product-details">Product Details</a>
<div id="product-details" class="funkybox"> </div>

Sites that use Goto's will often have hundreds to thousands of ID's and this is completely acceptable as its improving the way people quick navigate to the content they want, without the need of additional scripts (Great for accessibility).

ID Summary

There's no such thing as too many ID's as long as it makes sense to use that many within your project.

HTML5 Article, Section, Header, Main etc.

There's nothing wrong with using DIV over article or section for validation or search rankings but for markup semantic markup it can vary from project to project and you should use whatever makes sense for your project. One site may require one articles, a few sections while another site could use hundreds of each, it really depends on the content... generally sites that are blogs and will have plenty of articles etc, while a business site may just decide to use DIV with ASIDE.

I recommend you use http://html5doctor.com/ and use the elements that makes sense for your project. By the way SECTION is one of the most least tags a site should generally use, in the start of HTML5 lots of people rushed in and used section to sparring for cutting up elements. Generally on HTML5 Doctor your notice a vibe that DIV is still the leading element for many reasons and you shouldn't use the HTML5 tags just for the sake of it.

Ideal Class Naming

Name classes according to the content, not appearance... This is purely down to personal opinion and dependent on your project. A big project for a large site with huge amounts of traffic should try to use shorter class names to avoid unnecessary increasing the size of both HTML and CSS.

So you could use something like:


or you could rather use a .cbba{} and .cbbp{} but again this is down to personal perf and it may vary on if your using SASS or LESS too as you could script a shorter-name for live sites, and longer names for development.

How many classes should I use?

Don't use too much classes... You should use as many classes as your project needs, there's no right or wrong here and you should use as many as you like or few as you like.

Generally using less is better, for example:

article aside {} will be better than using class names if these elements are the same across the site, but if they vary from page to page then you should opt to use classes vs element styling.

If your articles strictly use a format like so:

        <h1>Article Name</h1>
        <span>Something short about the article</span>
        Content goes here
                <li>Related Link1</li>
                <li>Related Link2</li>
                <li>Related Link3</li>
        Published by Blah

Then you could use:

article aside{}
article div{}
article header h1{}
article header span{}

But then the problem can occur when you need multiple spans in the header or multiple divs and then your need to use multiple pseudo which isn't a bad thing but can get messy as the CSS gets bigger and bigger

Correct Planning

Your CSS should be planned where your site will be in the future, if you can't see the need of CSS increasing, changing then you can get away with using as less CSS class and Id's as possible, but if the site is going to get bigger, better and then you should forsee this changes and try to make the CSS as adapter-able as possible and using many class names and ID's, elements will allow this.

share|improve this answer
add comment

The “rules” are little else than opinions and coding style. They are not dangerous as such; they become dangerous if adopted as strict rules that make you deploy contrived methods and tricks just to be “pure” or “semantic” or “correct” (or whatever the buzzword is) according to your own standards.

A few examples:

a) There is no harm in defining id attributes more than you absolutely need for styling. They are not only for CSS; they are also crucial in linking, and “extra” id attributes (e.g., on every heading and every data table) let others link to specific parts of your page. In CSS, an id selector is handy for styling a specific element. However, in most cases, it is better to use a class selector (or other selector), just to prepare for the possibility that in the future, some other element might need the same styling. Not a big issue, though; it’s not that difficult to change an id selector to a class selector and add a class attribute.

b) “Descriptive elements” are coding style that is fashionable these days but does not give any tangible benefits beyond following suit (i.e., being perhaps more acceptable to your fellow designers/authors/developers). It has the definite problem of requiring extra code to make things work on old versions of IE. (Not much, but still.)

c) Class names have no impact on anything except people who read HTML and CSS (and JavaScript) source code. But it is generally better to use names that reflect the structure (and meaning) than just presentation. An attribute like class=red and a class selector like .red looks silly (and may even confuse) if the page is later styled, for some media at least, without using red color at all, perhaps even using another color for highlighting. But if you are using, say, <span class=red>♥</span> in order to display the heart suit symbol in red, it would be rather artificial to use a non-presentational class name.

d) There is no harm in setting up more classes than you need. They might help you in the future, or they might even help a visitor to style your page according to his preferences. On the other hand, inventing class names is mostly pointless if there is no specific need for class attributes. You might use class for some constructs just in order to be able to style them in a particular way if needed. But you might just as well add the attributes (and often span or div elements) when you have the need.

If you think you need a class on almost any element, then there is probably something wrong with the page design and your approach to styling.

share|improve this answer
Thanks for the answer! a) I do use element id for other purposes (I come from .NET background and elements ID are like "divSomething" or "ulSomething"), but I've been told it's the wrong way to embed the actual element names in an ID. b) I've been told it's crucial, for search engines and many other reasons. In fact, all your answers, as well-intended as they are, are in contrast to what they've rejected me for the task they set me: codereview.stackexchange.com/questions/48444/… –  Dalibor May 4 at 14:41
@Dalibor, the choice of id values is a different issue; usually divSomething is not a good idea, since it hard-wires the element type into the class name. Regarding b, there is much talk about the benefits of “semantic” markup, but did you ever see any factual evidence of any search engine paying any attention to them? That is, the arguments are theoretical, based on ideas on what might or should happen. –  Jukka K. Korpela May 4 at 15:26
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.