> All variables now use dashes instead of camelCase. For example, it's now @body-background instead of @bodyBackground.
Not sure how I feel about this. On one hand that's a pretty large sweeping change that is going to break all my customizations.
On the other, dashes look much better in css and I prefer them for class names and so on. Not even sure why, is this some sort of community standard I picked up somewhere along the way?
They don't use that selector as far as I know, because it's very brittle. Something like [class|='span'] would only match classes starting with 'span-' if they are the first class in the class list. So it wouldn't match something like '<div class="stacked span-5"></div>'
I struggled with making this decision, but ultimately it's all about readability for me. Hope it's not too much of a hassle for folks, but that's why this happens in a major update and not minor ones :).
I like the human-readability that dashes lend to URLs, but there are two things that bother me about using them in this case:
1. A dash is an operator, which could get confusing when you are doing math. For example: (@grid-gutter-width * (@grid-columns - 1)).
2. As far as variables go... thisIsDoubleClickable, and_so_is_this, but-this-is-not. I suppose it's not the biggest deal in the world, but I really hate having to drag my mouse to select.
Yea this is an age old discussion, I also like the separation that dashes or underscores give. Personally I'm a fan of underscores myself, mostly because I can then have id="foo_bar" #foo_bar and $foo_bar, for html, css, and jQuery variables, respectively, and remembering that JS can't have dashes in variable names. This makes the double clickable aspect super handy to me :)
Sometimes I hear that people don't want to have to press shift, which is understandable considering how much we code. But if bootstrap devs are already pressing shift in order to use camelCase, I wonder why they didn't pick underscores.
This is my general rule: If it's client-facing (eg. a URL) then use dashes - it's more readable (at least I feel it is). If it's developer-facing, use underscores or camel case. Sure it's not as pretty, but it's functional - which is really what we need. This boils down to - do whatever is best for the user.
I've always wondered why they initially chose camelCase and not dashes. I like keeping camelCase for JS only. CSS uses dashes (border-top). LESS uses dashes in its example documentation.
Funny, my editor usage is different, so I prefer dashes for the exact reason you don't. I use opt+(shift)+arrow keys to navigate and select words instead of mouse doubleclick.
camelCase and under_scores both select the full string as a word. But if you throw some-dashes-in-there, and you're using the keyboard, it's super fast to select just the bits of the value you want. Without the dash, you have the select a character level to modify aspects of the string, which is fairly fiddly for being such a common task.
A simple example of this being awesomely quick is adding a pre/postfix to values, eg:
Could someone create a compatibility stylesheet that defines all the camelCased variables based on the new dashed values? Just as a stand-in until you can update all your variables.
That or can someone write up a nice Sed script to grep through my less files and change all the variable names?
$ cat <<HN | sed -e '/@/ s/\([a-z]\)\([A-Z]\)/\1-\l\2/g'
> The following sed will replace camelCase only if it can find an arobase
> character in the current line, thus fooBar and bazThing won't be replaced
> but @fooBar and @awesomeFooBarBazzProperty will.
> True story.
> HN
The following sed will replace camelCase only if it can find an arobase
character in the current line, thus fooBar and bazThing won't be replaced
but @foo-bar and @awesome-foo-bar-bazz-property will.
True story.
Not sure how I feel about this. On one hand that's a pretty large sweeping change that is going to break all my customizations.
On the other, dashes look much better in css and I prefer them for class names and so on. Not even sure why, is this some sort of community standard I picked up somewhere along the way?