Yep I agree.

A good use of utilities can reduce the CSS weight and it seems Sara is using it with BEM too :) https://mobile.twitter.com/SaraSoueidan/status/1019157731796799488

@Ryan I guess it’s personal preference, but I’ve always applied that use case with the utility section/prefix. It’s the most specific part of ITCSS so I’ve used it where you semantically need an h2 element but would like it sized as an h4 or similar. In those cases I just use u-h4 similar to what you mentioned so I guess it’s just a personal preference on how specific you think that override should be.

Anyways, great article, cheers!

Thanks Bernard, glad you liked this article.

Regarding the Elements, I usually use e- prefix in a situation that requires different styles from the actual markup.

For example, let’s say we have <h2>This is heading</h2>, however in some places, the <h2> may look like <h1>.

In that case, I add the e- prefixed class like <h2 class=“e-h1”>This is heading</h2>. That way, we can keep both markup and styles correct.

For <a>, as you said, I don’t usually use the element prefix (e.g., e-link), but I do use the component prefix (e.g., c-link) and use it for both links and buttons.

Hey James,

It would be depending on how the card component is designed/structured, but for the simple case, I would say that’s gonna work fine; simply putting the buttons inside the card scope with .c-card__button (and with a comment of why the card scope is used so other engineers will understand it too).

However, what if there are several different button styles in the card? Then woudn’t we need to overwrite each button? I guess that might pile up the CSS specificity issue later.

In that case, I would talk with a designer and architect the button in a way that it can be more scalable with OOCSS.

The only critique I have is regarding Elements and their prefix of e-. Being that it is only for elements without a class such as <a> doesn’t it make a namespace irrelevant since you’d never use the prefix e-?

Otherwise, great article and nice overview.

I haven’t seen any particular examples that use this pattern, so I’m not sure if I might be “doing it wrong”.

Consider that I have a button:

<button class="c-button c-button--large">Click Me</button>

And I want to use the button inside a card, but I don’t want to have to repeat the styles. And I’d rather make it clear in the markup that the card is extending the styles of the button – as opposed to using a SASS mixin or @extend in the CSS.

Click Me

The c-card__button class still has low specificity and I DON’T do this with the selectors in my CSS:

.c-card__button .c-button {
    // styles
}

So it’s not actually nested in the conventional sense – it doesn’t increase specificity via nesting.

The c-card__button will add styles that are relevant only in the card – it may be positioning or some extra spacing or whatever – but ultimately those styles would only be relevant when the button is used inside the c-card.

Hey James,

Yes, definitely we can.

However, with that approach, we should have a good agreement between designers and engineers what spacing we are going to use.

I am using the similar approach for the Design System here at Campaign Monitor and I found that it’s quite important to make sure both designers and engineers are on the same page. If not, it can end up with many utilities which could actually be merged (e.g., .u-padding-sm-20 with .u-padding-lg-21 etc).

Thanks zngiron!

Regarding ordering CSS properties, here is actually a great article you can check out:

New Poll: How do you order your CSS properties?

Personally I follow the alphabetical order because almost always I know what I want to update and it’s easier to find.
Also my team doesn’t have to make/remember an extra rules on how to group properties.

In my opinion, it would help us organize the properties a lot better if CSS itself groups the property names naturally.
For example, if all text related properties come with text-, we would not really worry about how to group the properties. However, as mentioned by Jen Simmons here (https://twitter.com/jensimmons/status/1001242807758196736), now we have font- and text-; also color.

But it’s just my personal opinion/wish :)

What’s your thought? How would you order the properties?

That really representes my project structure.

Hi, I was thinking why not have utility classes with media queries… so for example you could have `class=”u-padding-sm-10 u-padding-lg-20″.

Really great article for understanding in-depth CSS.
Question though how do you structure your CSS classes?

.class {
Positioning
Display (Box Model)
Styling
Typography
Appearance
Animation
Etc
}

Might be a good idea to include it :)

Hi Fredrik,

It is probably depending on the boilerplate you use. I use my own with Webpack due to the different specs between static front-end projects and React projects, but for the static front-end projects, the general structure looks something like:

https://www.dropbox.com/s/9h3eu03d0k2xi87/file-structure.png?dl=0

Would you like to share how you structure your projects?

Thanks!

The main difference between BEM and OOCSS is what each one mainly focuses on.

BEM helps us lower down the CSS specificity by having a unique class name. The heading in the accordion as an example with BEM would look like:

.c-accordion__heading {
  …
}

but without BEM, we would be doing:

.c-accordion {
  .heading {
    …
  }
}

which ends up with a higher specificity.

OOCSS gives us a better way to construct components as explained in the article above.

In BIO, I have combined those two methodologies so the syntax looks like BEM which gives us a lower CSS specificity but helps us construct components in a better way with OOCSS.

That’s why you are seeing like .c-button--red which is BEM + OOCSS.

Hope that helps :)

Thanks Sebastian!

Regarding the helper classes, it may be depending on the project.

The helper classes might work well with frameworks like Bootstrap because they, in most cases, want to provide certain styles so the end users could construct components with different variations. However, that usually causes the size of the frameworks unnecessarily big.

There is no doubt that Bootstrap is a great framework in a certain way, but personally I never use any HTML/CSS frameworks unless it’s absolutely required (e.g., a client request etc). The main reason is the size (with unused CSS) and also the design I usually work on is very different from what frameworks usually provide.

From my experience, using helper classes too much could cause some issues, but especially those two issues.

1. Maintenance

For example, let’s say you have this helper class:

.u-padding-10 {
  padding: 10px;
}

and added this to all buttons.

<button class="c-button u-padding-10">I am a button</button>

One day, the client asked us to change the button padding to 15px.

In an ideal world, we could just go and replace .u-padding-10 to .u-padding-15 but in the real world, it is actually quite time-consuming to find all the buttons and replace the helper class when comparing to just updating the padding from the button styles.

2. Responsiveness

If you wanted to have padding: 10px in the smaller screen size, but 20px for the larger screen size, it’s quite hard to overwrite the helper class because 1) the helper class is supposed to be the highest CSS specificity and 2) .u-padding-10 might be also used in other components which shouldn’t be 20px in the larger screen size.

Overall, if you are working on a framework-like project, the helper classes might be actually helpful, but if you are building websites/components from scratch, I will definitely avoid over-using it.

What’s your thoughts on that?