Classes Vs Ids

From CSS Discuss

Jump to: navigation, search

When should I use a class and when should I use an ID?

This is a common question on css-discuss and other lists. The key thing to know is that IDs identify a specific element and therefore must be unique on the page - you can only use a specific ID once per document. Many browsers do not enforce this rule but it is a basic rule of HTML/XHTML and should be observed. Classes mark elements as members of a group and can be used multiple times, so if you want to define a style which will be applied to multiple elements you should use a class instead.


Also, an element can have multiple class values (by space-separating the various values), while an ID must be a single value. In this way, a single element can "inherit" from multiple classes.


The choice between ID and class can also be important from a Selector Specificity point of view, as IDs have higher specificity than classes. This means that, in situations where a class's properties might not be applied (for reasons of specificity and inheritance), an ID's properties probably will be -- IDs trump virtually everything, so you can be fairly sure that they'll make their mark.

See also Class Naming .

To paraphrase KevinW's comment (below) into a more conceptual comment :

Classes are useful to apply similar declarations to a variety of elements.  
In design, you often want thematic style to be applied consistently.  
For example, you may wish for all external links to be red, 
while internal links are blue.  
Using the class attribute in this case makes sense.
IDs are useful to uniquely identify a particular element.
On the face of it, this may seem to be a narrow use, 
but if you consider that a  Contextual Selector  can be used 
to apply declarations to elements which are contained 
by a particularly ID'ed element, the usefulness is greater.  
For example, you may wish to have all menu links be green, while content links are red.  
Placing the menu inside an element which is ID'd as "menu" or "content" respectively 
allows you to make contextual styling based on the section of the page.  
(Dorward: Or not - since you can use class selectors with a descendent selector 
just as well as you can use id selectors)

Perhaps it should also be mentioned that IDs and classes carry a bit (not much) of semantic information. If you look at HTML the way I do, you don't see markup that's going to be styled, but you see markup that tells what the content is. For example, a <div id="header"> tells me that this is the header of the document. Not necessarily something that appears at the top, but header as in "the section that contains the logo and all that basic site-wide stuff". It's also the header in that there is only one of its kind, and logically there's no possibility that there can be any other.

<div class="warning"> tells me that this part of the page isn't just another block, but in fact contains a warning message, perhaps as part of a tutorial about some mistake you could easily make.

The point is this: there are semantic elements in HTML: strong, blockquote, cite and code are examples of these. Then there are the deprecated presentational elements, like i and b. And then there are the semantic-less generic containers, div and span. But you can give them some semantics using id and class. Not very much semantics, because there's no standard way of doing this (XHTML 2 is supposed to solve this with the role attribute), but a bit. Which, by the way, is the point of microformats, which you might have heard about. So when you're deciding whether to use class or id for your elements, consider this: is whatever property you're giving the element something that logically appears only once, or could it appear several times? In the former case, use id, in the latter, use class.



I used to use classes almost exclusively until I realized that you can (with modern browsers) link to an element that has an ID.

Now when I'm considering page layout, I use an ID for each part of the page: navigation (#navigation), main text (#body), footer (#footer) and so forth. -- Unknown Signer


The way I decide whether to use a class or an ID is that ID is an identification attribute: it identifies a single element and the CSS rule is irrelevant or illogical when you apply it to any other tag.

Classes represent classes: that is, groups of tags that are structurally the same or similar.

Thus, I prefer to use class rather than ID for the content, headers, footer, etc., but that is my personal preference. - KevinW

Using both together

It's sometimes useful to use both id and class. For example, a page has a header and a footer. I want these to look these same in terms of colour, font, etc. So they are class="bar", say. But they have position settings too. So one is id="header", the other id="footer".

==

When creating a user interface for a web application, using css classes sparingly and relying on ids instead can really help simplify the code. The biggest benefits are the easy reading of the css later when you come back to it, and the cleaner (smaller) html code that is sent to the browser.

Each UI "thing" is inside a parent element which gets its own Contextual Selector id. Then the child elements are defined for it. By defining each UI widget this way, when you look at the CSS file, you know immediately why and where this style is being used.

Spaghetti code is avoided by not defining styles based on how you want things to look, but instead, by what the UI object is. Less dependencies, too. You want headings on detail pages to look different from headings on view pages? You don't have to go in and create 2 classes for 2 different headings, then apply them to the html. Change only the child elements of table#Detail and you won't have to worry about table#View. Its children are not affected, and the html isn't touched. And there is less html overall (plus the CSS is cached), which benefits the performance, especially when sending down 250 rows of data.

Personal tools