[paceaux]

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.

[AltruisticGapHN]

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").

[paceaux]

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.