I was being a bit facetious, I meant you don’t have to put much thought because when they’re scoped or in modules you can just name them the way you’re naming them. Complex CSS naming rules (like BEM style) seem dated to me.
This is actually super bad practice. I really dislike scoped css.
When I see devs using scoped css the class names always end up like `.box` or `.name`.
Having to think about classnames and writing Sass makes me much more aware of the structure of the components I'm styling.
Also scoped CSS kinda makes you skip the steps of thinking about your component in the bigger picture of your site, since you don't care about having meaningful and unique classnames, then you're much less inclined to think about good guidelines like OP's conventions. What does it matter? Since we can just put a `.box` in the scoped <style> and call it a day.
Frankly I think only JS oriented devs like scoped CSS and frontend who love html/css and the challenges of architecturing good CSS don't egt any benefit out of styled components (since you're using atomic css like Tailwind and/or BEM-style which always "scopes" classnames with the component name.
In general any solid guidelines makes CSS instantly 10x better and that's all most projects needs, and it's often what most projects lack.
SuitCSS works great with Vue in my experience, and can even be linted with postcss-bem-linter :
I'm the original author.... and what I can say is that my area of specialization is content management; creating the CMS and the websites that consume from the CMS. So I'm not doing "app development"; I'm doing traditional website development and scoped CMS is not on the table. This little guide for naming things is something I used with teams for YEARS as we were building very large websites for very large companies.
Suffice to say, the SuitCSS convention is extremely close to what we've put into use over the years.
Yeah, SuitCSS's main distinction with OP's (excellent) guidelines is that it specifically mentions components, and using the "PascalCase" format of the component's name, as the root classname for the component's root and child elements (eg. `.ProductDetails` `.ProductDetails-footer` `.ProductDetails is-selected` etc, optionally with an app wide prefix like `.cg-ProductDetails`). It's very convenient when you search in editor like VSCode and you find all the matching CSS/JS files together (when they are not "single file components").
When I wrote the guidelines, it really was all about, "be consistent". camelCase is my preference, but really, go with what makes sense and is least disruptive.
I actually REALLY like SuitCSS' recommendation and I definitely wouldn't object to it.
I intentionally didn't address project architecture (folder names, file names) because ... to be honest... I still haven't quite figured that out.
But I'm going to think on it and maybe add something to the guidelines that echos your suggestion.
