Mixed case syntax

[etler]

Other than familiarity, is there a reason BEM settled on the all lowercase syntax that was generally popular for non structured CSS naming conventions?

I'm not sure if there was a particular reason everyone settled on the all lowercase dash separated syntax other than lack of need for a more descriptive syntax, and a desire to match HTML conventions. But CSS is not HTML so is there a reason for them to match? Since BEM is much more descriptive, I like to use mixed case to provide more versatility.

Personally I've settled on BlockName_ElementName-attributeName using PascalCase/ camelCase to invoke a class/variable feel. IMO it's easier to read than block-name__element-name--attribute-name because each name token is blocked together. Also __ and -- look ugly :)

Is there a particular reason BEM settled on all lowercase instead of mixed case? Did I make a grave mistake, or is it purely cosmetic?

[sumnermic]

My justification for all lowercase is that it ignores the use of capitalisation. Personally simplifies things for me and less worry about having that extra criteria to capitalise my selectors.

I found the underscore symbol __ to mean 'below/descendent of' and double dash -- to mean 'variation of'.

[etler]

I don't quite get that though. We use significant capitalization in pretty much every other language that has significant casing so why not use it with CSS as well?

HTML ignores tag casing so it makes sense in that language, but CSS has significant casing so why not use it?

I also don't see how it's any more complicated. It's the same number of significant separators. There's a block-element separator, an attribute separator and a word separator either way. Personally mixed case seems simpler to me because camel casing is very standard in other languages and you don't need to understand the difference between - and --. If I had no experience with BEM I would need to be taught the difference between dashes, but with camel casing the significance of the underscores and dashes are more obvious to me.

[garrypolley]

🚲 🔴 🏠 🚲 🔵 🏠

I think part of the reason was related to tooling. It's pretty simple to write tools that parse text on -- and __. Having to do mixed case adds more complexity to the tooling.

At this point the ship has sailed on how the naming works. If you want your projects to use camel case with a single _ and - you're free to do that, nothing forces it. However, most tooling will be built around knowing that -- and __ are used.

As for ease of reading, that's fairly subjective in the context of these CSS selectors.

Related to language the mixcase or not doesn't really matter. CSS is most often used with HTML for web developers, so following some of the standards that HTML use make sense to me.

[etler]

Are word separators significant in BEM? I was under the impression that foo and foo-bar were just treated as token name blobs? I didn't happen to see any tooling mentioned on the website so maybe there's a constraint I'm missing, but I thought the only really significant syntax tokens were the block/element separator and the (block|element)/attribute separator, and anything in between was pretty insignificant.

I of course haven't thought about the problem as much as you guys so I'm curious if there's some constraint that requires you to parse the characters within the name token blob. It would be nice if the tooling would allow you to choose the separator token.

It's simply differing opinion, but I don't really agree that CSS should be constrained by HTML naming convention. Normally naming conventions are based on the language syntax constraints, and since CSS and HTML and Javascript all have different language syntax constraints, it makes sense to me that they would differ. I agree that ease of reading is entirely subjective though.