Yep it was a BEVM article :)

I tried using the –V syntax for a bit but I ended up dropping it in favour of always using -M syntax. I couldn’t find any situation where –V was more useful than the -M syntax and the article I read suggested that the –V wasn’t critical anyway and you could forget about it if you wanted to.

I’m not against the idea.

I don’t agree with the full premise behind the article where he wants us to try and avoid classes as much as possible. I’m worried about specificity getting out of control. Also [type=text] doesn’t cover all the other text box style inputs like email. I also think it would make the style sheet kind of messy.

It’s not a bad idea using the semantic aria attributes for state based styling though instead of modifier classes where possible.

I’m not a fan of using Atomic CSS libraries like Basscss and Tachyons.

This article gives a great run down of all the problems with that style of class naming:

“The Problem with Atomic CSS” https://medium.com/simple-human/the-problem-with-atomic-css-d0c09c7aa38e

It sounds like you are a CSS-in-JS fan.

Firstly CSS-in-JS only works if the site is built entirely in something like React/Vue. Building a site in that way only makes sense if there is an immense amount of state changing all the time. Something like a simple brochure style site where there is practically no state changes to worry about shouldn’t be built in React/Vue.

Secondly I’m just not a fan of CSS-in-JS. It’s mainly a personal preference thing but this article does an ok job of outlining why you might avoid using CSS-in-JS:

“Stop using CSS in JavaScript for web development” https://medium.com/@gajus/stop-using-css-in-javascript-for-web-development-fa32fb873dcc

In most case, Functional CSS just like Semantic HTML is easier to look at.

Thanks for this article ! I’ve only scratched the surface of BEM I always had a bad feeling about this rule on single class selectors in OOCSS in general, and applied in BEM with horrible looking classes.

Now, since adding some specificity through combined classes seems perfectly logical, would it be possible, instead of using classes, to use aria attributes when it makes sense and when it is possible like it is proposed here : http://alistapart.com/article/meaningful-css-style-like-you-mean-it#section3

The specificity would be the same than with classes and we would benefit a more semantic approach.

What do you think ?

For point 1, I know that IE11 supports the dash prefix at the start of classes. All other IE’s are essentially dead now.

I’m interested in seeing what mobile browsers don’t support it. I’m guessing Opera Mini since Opera Mini barely supports anything. Fortunately it isn’t a browser I personally need to support.

As for point 2, I still think separating the modifier is better. The issues you raised sound more like an issue around a lack of training or a lack of resources (so BE devs have to write FE code). If used properly, it makes sites easier to maintain and the html much easier to read.

You might have stumbled upon my artice on medium which I posted in march 2016 and deleted after conversation with a developer from yandex.

We removed -modifier from our project for several reasons:
1. IE and some mobile browsers do not support classes starting with -
2. The problem with specificity is that somebody begins to use chained modifiers and we go back to specificity hell

(for example btn -icon -tiny and overrides padding rules of -tiny with fixed height \ width for smaller icon button using something like .btn.icon.tiny and other modifiers stop working due to specificity)

By the way
BEM is methodology, naming conventon is just a part of it.
https://en.bem.info/

https://csswizardry.com/2015/03/more-transparent-ui-code-with-namespaces/

I think the cleanest way to handle it in your example would be to apply the modifier to the molecule and use &.-colourName { color: [colour-name]; } to apply the change of colour since colour can be inherited.

My main gripe with that method is that it creates a huge amount of extra gunk in your css style sheets. You are then forcing your users to download all that extra gunk when they visit your site.

Say you have 50 buttons on your site that extend the .button component. This is the sort of css you end up with:

.button,
.subscribe-form__submit,
.register-form__submit,
/* another 47 selectors */
.search-form__submit {

 /* button default styles */

}

.button:hover,
.button:focus,
.subscribe-form__submit:hover,
.subscribe-form__submit:focus,
.register-form__submit:hover,
.register-form__submit:focus,
/* !!! another 94 selectors !!! */
.search-form__submit:hover,
.search-form__submit:focus {

 /* button hover & focus styles */

}

That was just one button with default styling and hover/focus styling applied. You can see how ridiculous that can get.

Now compare that to this:

.button {

 /* button default styles */

}

.button:hover, .button:focus {

 /* button hover & focus styles */

}

Using classes the way they were intended keeps your css lean and clean.

Also, never extend a class directly. Only ever extend sass % classes. Extending classes directly can cause some really weird and unexpected side-effects to occur.

So instead of this:

.button {
 // button styles
}

.subscribe-form__submit {
  @extend .button;
}

You should do this:

%button {
 // button styles
}

.button {
  @extend %button;
}

.subscribe-form__submit {
  @extend %button;
}

I’m glad you enjoyed the article :)

I didn’t really want to go too deep into how atomic design works with this article since that is a deep enough topic to fill a full article on it’s own. It was out of scope for this one.

I’m wondering why you aren’t using camelCase? I spent a third of the article explaining why you should be using camelCase when using ABEM :/

As for your question, it depends a lot on context. Under what circumstances do you want the text to be coloured differently?

If you only want the colour to change on these particular atoms when it is in this specific molecule then it might be best doing the colour change as context sensitive styles. Context sensitive styles don’t have to be used for layout exclusively, it’s just the most common need for them. They should be used whenever you need to apply styles based on what the parents are.

If you want to be able to apply this change to the colour in a more general sense then it’s probably better to apply the -colourName class to the atoms directly.

If you want the two to be linked you could apply the .-colourName class to the molecule, then in the atom scss files you can do this sort of thing &.-colourName, .- colourName & { ... }. That will apply the colour if the modifier is applied to either the element itself or a parent.

I think the cleanest way to handle it in your example would be to apply the modifier to the molecule and use &.-colourName { color: [colour-name]; } to apply the change of colour since colour can be inherited.

It all depends on context and under what circumstances you want the colour to be applied though.

No reason you can’t incorporate is- into the ABEM modifier syntax. You could do something like this .-is-modifierName. See what I mean by camelCase allowing you to create your own custom groupings?

I like keeping the dash at the start since it is still a modifier name and a dash start = modifier.

https://github.com/suitcss/suit/blob/master/doc/naming-conventions.md

In my opinion, SUIT component state classes are more explicit by adding is- prefix instead of a single dash.

See the Pen ABEM Experiments by Kendall (@KendallWhitman) on CodePen.