I agree that some of it is preference, but the main point he is making is that the number of utility classes doesn't matter if you're using a framework and styling a component. Yeah, it's ugly markup but so what?
With that said, I think it's reasonable to roll some things up into general classes. They remain very easy to change.
>I haven't seen anyone argue not to use React or Web Components because naming a component is hard.
I think the whole point is that that UI element, or "interface", or "component" is the thing that should have a name. That entity doesn't need to have a unique CSS classname.
Got it. So this would be more of a hybrid approach and clears up that question on naming granularity. Give the "component" a logical name and use the utility classes for the component's entities. That makes a lot more sense to me. I didn't realize those child entities were the things people were giving names to. CSS has fairly rich ancestry rules, so I just assumed people use them.
Thanks for taking the time to clarify that for me. It does indeed change my perception on utility classes.
I still think you're misunderstanding. It sounds like you think that the component has a class and everything flows from that. Like .component-name a {}
The point is that HTML elements don't need to have semantic class names at all. So even the top most element in the component would still use utility classes.
With that said, I think it's reasonable to roll some things up into general classes. They remain very easy to change.
>I haven't seen anyone argue not to use React or Web Components because naming a component is hard.
I think the whole point is that that UI element, or "interface", or "component" is the thing that should have a name. That entity doesn't need to have a unique CSS classname.