What style should we use for CSS naming?

Software Development
1

Our current CSS naming standards are based on the BEM methodology, but don’t completely stick to it: they dictate using .is-* classes instead of BEM Modifier classes.

<div class="button is-icon-only">
  <span class="button--icon"> ... </span>
</div>

On top of that, we have atomic helper classes, which are intended to modify a styling attribute ad-hoc, to make minor changes without needing a completely new component. These are of the form .has-PROPERTY-VALUE, e.g. .has-padding-left-1.

Alternatively, we could use full BEM style:

<div class="button button__icon-only">
  <span class="button--icon"> ... </span>
</div>

This also means we can use either .has-* or .is-* for atomic helpers, depending on which makes more grammatical sense, which would help our code to be more readable.

4 Likes
2

I am but a beginner with CSS, so my opinion might not count for much. But when I see is-something or has-something I know what it means right off; if I see thing__something or thing–something then I can figure it out, but it’s not as obvious. In addition, I’m likely to get the wrong number of underscores/dashes (I just did this not five minutes ago when writing some Stylus customization elsewhere), and if we mix dashes and underscores we’re probably inviting confusion. (When do we use which? Will everybody get that right?)

I vote for readability and writability. Are these in conflict with each other? Are there cases where is-something/has-something isn’t expressive enough or is confusing?

4 Likes
3

I’m not a fan of full BEM / thing__something either. I think button is-icon-only is more readable than button__icon-only.

This is likely because I’m often in CSS and JS at the same time, and even C or PHP on top of that. I don’t think I’ve ever spent an entire day coding only in CSS. The relevance is that the use of underscores in other languages have different meanings, depending on context, project, language, and standards.

Personally, I’ve found that I have to reread underscores in CSS when switching contexts. It takes a second or so - not much - but rinse and repeat 100x a day and I’m losing my mind.

But that’s just my personal preference; I don’t have strong feelings either way.

2 Likes
4

I am just repeating a few things I wrote yesterday:

  • It’s shorter. Co-Design has already some long-ish/verbose names. Hence using the shorter prefix .is- is (IMO) better than also adding a possibly long component name. This is also better to prevent lines from growing beyond the character limit, especially, when we also have some atomic classes.
  • There shouldn’t be any confusion. CD does not support giving one HTML element multiple components. This means, that, e.g. no element may be both a button and a badge at once. Therefore it is not neccessary to say, what something relates too. A good CSS/JS structure will also help to prevent confusion. In the compiled CSS, the component name should be immediately before the modifier, for example.
  • Co-Design already uses the old style. That’s no hard problem, but it means some effort, which could be spend better, if it is not really neccessary. However, we need to make a decision now, to prevent even further work if we change later.

I think having both, .has-X and .is-X, as atomic class prefixes is unneccessary and also sometimes counter-productive, for these reasons:

  • Atomic classes are for one specific purpose. They override one CSS property with one specific value. Everything else would not be an atomic class. Therefore, we only need one form, which can be .has-[PROPERTY]-[VALUE], as it is now.
  • This would IMO lead to more confusion, not less. When to use .has-X vs. .is-X?

@ArtOfCode also said (in Discord), that with the .is-X notation, it is’t clear, what the exact effect is, because it changes, depending on the element.

I think this is not true/problematic, for this reason:

We should still strive for consistency within our system. .is-danger shouldn’t sometimes change something’s color to green and sometimes to red. However, within the existing system, that’s already the case. .is-danger marks something as “in danger state” and gives it a red-ish look. This works for links, buttons, notices and modals.

(edit: There seem to be some inconsistently named classes for modals and inputs, I’m going to change it later, so this concern no longer applies.)

Therefore, the semantic effect is clear, although the visual effect might differ. I don’t think this is problematic, though.

Considering all these things, I’d oppose changing the naming style.

4 Likes