4 ms·
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 styl
by dimmke 4y ago
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.
- nirvdrum 4y agoGot 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.
- dimmke 4y agoI 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.