I've been learning HTML5/CSS3 for a month now, and I've built my first demo website. At first I was using a lot of the element selectors like: >, ,, + in combination with the type names for selecting nested tags.

Now I've moved more to the id and class selectors and use the >, ,, + less often for selecting nested tags.

Is using id and class selectors a better approach for selecting tags which are (deeply) nested? Are there any downsides to this approach? Or is it just a matter of style?

3 Answers 3


This is not only a matter of style. It is a matter of performance and maintainability. Anecdotally, some selectors are difficult to implement efficiently for browsers. For example, the general sibling selector A ~ B or the descendant selector A B. And of course the universal selector *. Unless actually needed, these should be avoided. The thing that is really fast is using class names or IDs. The comma A, B is not considered a selector.

When you start out with CSS, you might be tempted to write something like ul.#steps > li.item-without-bullet. That is not good for various reasons:

  • Do not use IDs in selectors, because any ID can only be used once in a document. This prevents you from re-using the styling.
  • Avoid element names in selectors. HTML is meant to be used as semantic markup that highlights what each element means. This should be kept mostly separate from the styling. You will still want to style elements directly (e.g. using a different font only for headings, or setting the line height for paragraphs). That is OK, and I wouldn't use classes for that (yuck), but you shouldn't refer to the element names when styling something special such as a nav bar, or an image carousel, or a pull quote, or ….
  • Avoid ID and class names that focus too much on what text effect they provide (you might as well use inline style attributes), and instead use class names as custom elements or element modifiers, as a way to add your own semantics. A class such as red-text is not as “semantic” as error--fatal.
  • Avoid the descendant selector A B and the child selector A > B. You can usually encode the necessary information through your class names, e.g. steps and steps__step. You can trust that whoever is applying the classes to the HTML structure will respect proper nesting, given sufficiently self-documenting class names.

Seriously consider a strict naming scheme such as BEM (Block Element Modifier). Yes, it's incredible overkill, but using the BEM naming scheme can help you to properly structure your CSS. It exclusively uses class names, and does not generally use selectors.

  • Excellent guide you linked to. Hard to find a good clear guide on BEM. I had no idea you could nest blocks with BEM and I've been using it for years (or thought I had been). Commented Jun 14, 2023 at 19:59

I think it's a little bit of personal preference, however I typically choose to use class names over anything else so that if I decide to add/remove a layer of nesting than I won't break my selector.

So while I might put a class on a "toolbar" div, I might not decorate a contained ul or individual items. I would select the container based on class, then know that what's underneath that are toolbar buttons.

As with most things related to CSS, trial and error wins the day - best of luck to you!


Each type of css selector has its place. The progression of usage you describe is natural because it mirrors the progression of design from general to specific. There are several selector types to help us fulfill our design goals (I've given two examples of each in parenthesis):

  • element selectors (p, div) to establish overall styling
  • state selectors (:hover, :checked) to provide feedback on user interaction
  • class selectors (.nav, .span5) to further style groups of similar elements
  • id selectors (#container, #result) to customize unique elements
  • attribute selectors ([target=_blank], [lang|=en]) to vary style with attribute values
  • position selectors (::after, ::first-line) for finer control
  • relation selectors (A B, A > B) are not as efficient, but can be useful

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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