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,
.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
@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.