81–90 of 118 posts
Earlier quoted context omitted.
I don't want to start a flame war, but I was wondering if there is a rationale for prefering dash-case? I have a hard time not writing in camelCase by default now.
fwiw, we generally just try to do what the language does: border-radius document.createElement etc…
> Renamed all of the variables to use dashes instead of camelCase. I absolutely detest camelCase. It ranks down there with good-old Hungarian notation. So, I am now wondering, why this change? Are people finally coming to their senses?
I believe that, exactly as the utterly retarded "TAB vs space" debate, the "cameCase vs dash" should be a non-issue. This should be solved at the text editor / IDE level and at the tools level and should not cause any issue. Put it this way: I can trivially write an Emacs minor mode that detects cameCase and shows them as dashes and vice-versa. This should be something each programmer could decide on its own, as long…
Tab vs. spaces will not cause code to break, mistyping camel case in a case sensitive language does. Neither camel case nor case sensitivity makes programming easier, better, faster, less error-prone, clearer, more accurate, et. In other words, it serves no useful purpose other than feeding a fad.
Tab vs. spaces? Don't really care. There are good reasons for going ether way. As long as the tab key does the indentation I, personally, couldn't care less which way it goes. My code will not break if I enter a bunch of spaces instead of tabs.
Earlier quoted context omitted.
They were so handy to have for those corporate and/or data-oriented web sites and doc archives.
...and BTW zurb offers a sleek solution to the "small-screen drop-down problem": http://foundation.zurb.com/page-templates/contact.html -- it extends the bootstrap's idea somehow and I was expecting to see something like this in the third version instead of having it removed.
Earlier quoted context omitted.
I don't ever recall saying that, but if I did, I'm happy to have been wrong. Super stoked about the direction we're going.
I am not sure what "mobile first" means, could you please explain what that means for the end-developers? The only thing to that effect I see right now is that responsive less files will no longer be separate from the core. That will probably mean that I will be forced to support mobile platforms. Is there more to it? (Aside, wishing someone would take a deeper look at https://github.com/twitter/bootstrap/issues/4935…
> Renamed all of the variables to use dashes instead of camelCase. I absolutely detest camelCase. It ranks down there with good-old Hungarian notation. So, I am now wondering, why this change? Are people finally coming to their senses?
just-testing-this JustTestingThis Hmm. I think it only matters to me that the author picks one and stays with it. But that means that all libraries he uses has to use the same one. Which is why languages tend to prefer one over the other. e.g. Java using CaMeLcAsE To have them mixed in one code base would be like a micro context switch.
It's "justTestingThis" not "JustTestingThis" if we are talking camel case.
So yeah, camel case and case sensitivity add unnecessary fragility to programming. Which is the reason I don't like the fad. You accidentally made my case.
Why the dropping of support for submenus? I find those really useful and it would be a pain to have to patch them back in.
I am glad that they removed it. Submenu is very much a last generation tech. Awkward on mobile devices. And my one very strong reason to use bootstrap was to make the app mobile friendly. Removing its support is good because it was adding tons of CSS code.
That's an absurd generalization.
It would be awesome if someone built a Bootstrap version converter. I'm currently using v2.2.2, and I simply don't really have the time to go through all the code to get it upgraded to the extent of making sure nothing breaks. Does anyone know the best way to do things like this, if a converter doesn't exist? It would be nice if the docs still had old versions, sort of like WordPress or PHP docs do, where you can see…
Earlier quoted context omitted.
I am not sure what "mobile first" means, could you please explain what that means for the end-developers? The only thing to that effect I see right now is that responsive less files will no longer be separate from the core. That will probably mean that I will be forced to support mobile platforms. Is there more to it? (Aside, wishing someone would take a deeper look at https://github.com/twitter/bootstrap/issues/4935…
Why on earth would that mean you'd be forced to support mobile platforms?
I currently have scenarios where I want the same version on the desktop and mobile. That's trivial because I simply don't include the responsive CSS file.
In 3.0 the media queries are part of the core. So I can't just leave the responsive CSS out. Further, it's mobile-first so things like the navbar would be collapsed by default on a mobile device. I would be forced to negate that to get an uncollapsed navbar on a mobile device (as desktop version).
> Renamed all of the variables to use dashes instead of camelCase. I absolutely detest camelCase. It ranks down there with good-old Hungarian notation. So, I am now wondering, why this change? Are people finally coming to their senses?
For that reason, I prefer using camel case.
What's interesting is underscores are not considered word separators in many text editors.
Earlier quoted context omitted.
I believe that, exactly as the utterly retarded "TAB vs space" debate, the "cameCase vs dash" should be a non-issue. This should be solved at the text editor / IDE level and at the tools level and should not cause any issue. Put it this way: I can trivially write an Emacs minor mode that detects cameCase and shows them as dashes and vice-versa. This should be something each programmer could decide on its own, as long…
I think the big difference is that camel case added to the ridiculous idea of designing programming languages that are case sensitive just makes for unnecessary friction. Tab vs. spaces will not cause code to break, mistyping camel case in a case sensitive language does. Neither camel case nor case sensitivity makes programming easier, better, faster, less error-prone, clearer, more accurate, et. In other words, it s…
Well, mixing them can. Python, for example.