-
Notifications
You must be signed in to change notification settings - Fork 220
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mixed case syntax #94
Comments
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 |
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 |
🚲 🔴 🏠 🚲 🔵 🏠 I think part of the reason was related to tooling. It's pretty simple to write tools that parse text on At this point the ship has sailed on how the naming works. If you want your projects to use camel case with a single 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. |
Are word separators significant in BEM? I was under the impression that 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. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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
usingPascalCase
/camelCase
to invoke a class/variable feel. IMO it's easier to read thanblock-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?
The text was updated successfully, but these errors were encountered: