SMACSS, Semantic Class Names and Nested Elements

Question

I've just read Scalable and Modular Architecture for CSS and it's got me thinking about a few things. Snook's two principle tennets are:

Increase the semantic value of a section of HTML and content
Decrease the expectation of a specific HTML structure

So this means using semantic class names rather than relying on unsemantic element types for targeting. For example rather than targeting .someClass h5, I might target .someClass-title instead so that if the h5 is swapped out for something else, things don't break.

Personally I find encoding an element's hierarchy in its name kind of unpleasant (even if it is semantically correct). I would prefer doing .someClass .title. But to use a class as generic as title you need to accept that this class will be used in lots of different contexts.

So is there anything wrong with using the same class in completely different contexts if I know it will be namespaced by a previous item in the selector?

For example say I have three different places in my site where a class of 'title' makes sense:

HTML

<header class="pageHeader">
   <h1 class="title">Some Title</h1>
</header>

...

<article class="leadArticle>
   <h3 class="title">Some Article Title</h3>
</article>

...

<ul class="productPreviews">
   <li class="product">
      <h5 class="title">Some Product Name</h5>
   </li>
</ul>

CSS

.pageHeader .title
{

}

.leadArticle .title
{

}

.productPreview .product .title
{

}

Edit: as Alohci mentions in his answer below, a header tag isn't unsemantic, so perhaps this wasn't the best example to use.

Obviously I might be doing something completely different to the title in these contexts, but title makes absolute sense with it's module's namespace, and I never have any intention of using title as a general selector.

This seems to tick all the boxes. It is semantically rich, completely decoupled from implementation. For example if the last example was changed into an ol or a stack of divs, nothing would break, and if title was wrapped in a div it would still be targeted.

This makes sense to me, but I haven't seen this approach used much and I'm wondering why. An obvious disadvantage is that you are chaining classes in the selector, but I think this is preferable to namespacing each classname.

"... I never have any intention of ..." — famous last words — chharvey, Jun 02 '14 at 04:19

score 5 · Accepted Answer · answered Feb 13 '13 at 21:48

I prefer using a class like .title rather than selecting just the h5 element, as I feel it decouples the HTML from the CSS some more. If, for whatever reason, you decide an h4 or and h6 is more appropriate for the document outline, or some other element/reason, you would have to refactor your CSS if you are selecting the element(h5) vs select a class(.title).

This is why I prefer to class ALL THE THINGS vs. element selectors because the markup may change over time. If your working on a smaller site that isn't seeing many updates, this may not be a concern, though it's good to be aware of.

As far as if there is anything wrong with using the same class in completely different contexts if you know it will be namespaced by a previous item in the selector, I have mixed thoughts on it.

On one side, some concerns come to mind, for instance the use/meaning/role of .title could be empty without it's parent selector. (.pageHeader .title) While I think that .title is a perfectly fine class name, it may be difficult for other devs to understand it's meaning comes from a parent selector like .pageHeader .title

Another concern is if you are using the class .title for multiple instances of "titles" in a module, you can run into issues. The basic idea is that the local scoping descendant selectors provide can sometimes be too restricting if trying to stretch the reusability of .title within the module. I set up a code demo to show what I'm talking about here.

On the other side, descendant selectors are one of the most used selectors, specifically for their scoping purpose.

Tim Murtaugh, who is one of the developers (not sure if he is the lead dev or not) for A List Apart uses descendant selectors for the majority of his styles on his personal site.

I've recently been exploring this and BEM and would agree with your conclusion, "this is preferable to namespacing each classname."

I prefer .pageHeader .title{...} vs. .pageHeader__title{...} but there are always instances where one approach may be more beneficial in a situation over the other.

As with most things, it depends, but I think if you don't let the nesting go too deep and are thoughtful with how you use them, descendant selectors are powerful and good solution for providing locally scoped styles while also offering a solution for globally scoping styles.

For example:

/* Globally scoped styles for all .title(s) */
.title{
   font-family: serif;
   font-weight: bold;
}

/* Locally scoped styles for individual .title(s) */
.pageHeader .title {
    color: #f00;
}

.leadArticle .title {
    color: #00f;
}

.productPreview .product .title {
   color: #0f0;
}

I too have started to Class All The Things, although for me it's more of a guideline than a rule. When it comes to content, as opposed to layout, I need my CSS to reflect the simplicity of markup that I enforce upon my editors — H3, H4, H5 (ad so on) are all classless within content blocks. — Tim, Feb 13 '13 at 21:53
Great answer. Since posting this question I have been classing everything (other than necessary furniture like

score 2 · Answer 2 · answered Aug 27 '12 at 23:50

I think there's very little to say about this. What you're doing is fine, though it's not the only approach to organizing your markup for CSS. The important thing to understand is that class names are not part of CSS, they're part of HTML.

So the classes applied to an element are not, in HTML terms, "namespaced" by their ancestors in the DOM tree, but stand in their own right. So it is reasonable that you use "title" for the class names of each of the elements in your example because they are all alike in being titles.

A contrary example would be to say use the class name of "note", where on one element it signals a type of comment, but on another element a musical note, and then assuming that their meanings can be distinguished by inspection of an ancestor element. That's not how HTML classes are supposed to work.

It's also work noting that there's nothing unsemantic about <h5>. Use of element names in your CSS selectors is just another way of describing the relationship between the elements you want to style. .product h5 as a selector means "style fifth level headings in the context of the sub tree of the class 'product' like this ...". That's a different statement from .product .title which mean "style elements of class 'title' in the context of the sub tree of the class 'product' like this ...". Both statements are useful.

Thanks for your answer. I come from an object-oriented background, so I suppose to some extent I am trying to impose this onto CSS/HTML and I can't shake the analogy of components and variables. I have yet to see a naming convention across a site that has felt like the right solution to me. They always seem to break down after a point and become overcomplex or hard to follow. I fully agree there is nothing unsemantic about h5. Possibly 'title' wasn't the best example I could have given. — Undistraction, Aug 28 '12 at 00:02

score 1 · Answer 3 · answered Nov 08 '14 at 15:03

One very important thing to note is that browsers read CSS right-to-left, not left-to-right so if you structure your selectors few levels deep then it's more work for browsers to do.

.pageHeader .title {}
.leadArticle .title {}
.productPreview .product .title {}

So this is one .title but in a different context. Browser while rendering will check if the child element is placed inside of particular parent element and then it will apply corresponding rules.

.pageHeader-title {}
.leadArticle-title {}
.productPreview .product-title {}

Here we have 3 very different titles (not one!) so browser wont do any extra calculations nor checks if the child is a child of particular parent. What we have here is also more flat structure of modules which is always nice.

Always remember that nesting your selectors and naming them in the same way but in different context has impact on the performance which does not mean anything if you're writing small personal website but if you need to plan and deliver solution that will be viewed by millions then it's important to know how to properly structurize your markup.

score 0 · Answer 4 · answered Feb 19 '15 at 15:30

It's sometimes referred as "parent-child relation" (http://thesassway.com/advanced/modular-css-naming-conventions) and often recommended to go with .page-header-title.

In your case .page-header can be treated as a component and .title as a component part. RCSS (https://github.com/rstacruz/rscss/) standard advocates .page-header > .title. I personally find it as not a really good idea. Consider following:

<header class="page-header">
<h2 class="title">
  <span class="tooltip">
    <span class="title">..</span>
  </span>
</h2>
</header>

.tooltip > .title unintendedly inherits from .page-header > .title.

So I would go with .page-header-title.

When you do intend the heading to inherit from a base class, just add class to the HTML element

<header class="page-header">
<h2 class="page-header-title title">
</h2>
</header>

Now page-header-title contains component specific styles and title augments with abstract title styles. Yes, it is verbose, but safe. Here, if any interest, my detailed opinion on how to keep style cascading sane and to have clean and obvious abstraction https://github.com/dsheiko/pcss

SMACSS, Semantic Class Names and Nested Elements

4 Answers4

Linked