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.
Agreed. These are sorely needed for enterprise apps.
+1. Enterprise still on the way.
Bootstrap 2.3 Released
71–80 of 118 posts
Re: Bootstrap 2.3 Released
#72Re: Bootstrap 2.3 Released
#73> 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 as the commits are using the same convention.
Now, also, maybe maybe maybe that it shouldn't be language recommandations but specs defined in the language.
A bit like how the Go language close shut the big mouths of people advocating for this or that place for brackets.
For what it's worth I'd configure my text editor to show names using dashes instead of camelCase...
Re: Bootstrap 2.3 Released
#74Earlier quoted context omitted.
Why does it matter?
For me, it's not so much that the profanity is offensive or anything - I have what many might consider to be a fairly dirty mouth. It's that their usage of profanity is lame. They're trying to be cool and funny, and it's very much neither of these. If they could actually managed the be humorous with profanity, then maybe I wouldn't mind it so much but this blog post really reeks of someone who is desperately trying t…
Exactly how I felt about it. Like it was written by an old sad salesman with a pasted smile.
Re: Bootstrap 2.3 Released
#75It 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 what is depreciated and how to change/upgrade things to newer versions.
Re: Bootstrap 2.3 Released
#76Earlier 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…
AFAIK CSS uses camelCase for variables.[1]
Re: Bootstrap 2.3 Released
#77> 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?
Preference, readability, consistency with classes, better spell checking, etc. I always felt we should have done dashes instead, but shipping camelCase meant sticking with it for backward compatibility. With v3 though, we're going with our gut and using dashes.
OK, thanks for the explanation.
Re: Bootstrap 2.3 Released
#78Earlier 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?" No, there isn't. It's one of those typical things that novice programmers fret about. Consistency within a code base is much more important than which style is used exactly. Having the style be a compile parameter would make sense to me, not switching from one to the other.
> Consistency within a code base is much more important than which style is used exactly. I know this is a commonly held belief, and I held it too for a short while. But then, I was managing a project that ran on both Linux (lower_case_name libraries), Windows (CapitalizeEachWord), had components in Python (ClassesAreLikeThis but variables_like_this), Java (camelCaseIsAnAbomination) and even some VB6 (don't even reme…
those are essentially different code bases (python/java/vb6).
As the other replier wrote, having different style variables and naming conventions in the same project - really, the same file - is somewhat distracting.
$numberOfPeopleEmailed = 23;
$What_The_User_Chose = $_POST['chosen'];
do_something_withVarName($x);
$sFirst_Name = _$_POST['name'];
it gets distracting. While it's been rare for me, I've occasionally dealt with large files with different styles of var naming contributed by different people. It's far more of a mental nuisance than tabs-v-spaces (I'm a tabs guy, fwiw).
Re: Bootstrap 2.3 Released
#79Earlier 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.
"I don't want to start a flame war, but I was wondering if there is a rationale for prefering dash-case?" No, there isn't. It's one of those typical things that novice programmers fret about. Consistency within a code base is much more important than which style is used exactly. Having the style be a compile parameter would make sense to me, not switching from one to the other.
> It's one of those typical things that novice programmers fret about.
I think you might be generalizing a little too far here. I've been programming for over thirty years in more languages than I care to remember. Every so often a meme of some sort raises to the surface and the sheep jump on it. Hungarian notation was probably one of the ugliest of all. Case sensitivity is another. And, case sensitivity added to camel case just makes your job that much harder for no good reason at all:
autoDetectMotorPhaseAngleAndSpeed
Is horribly unreadable and gives you many opportunities to make a typing mistake and cause development delays.
auto-detect-motor-phase-angle-and-speed
Is super-easy to read and type. Less entry errors and legible code are important. If you think that this is a newbie "mistake", well, they are right.
Re: Bootstrap 2.3 Released
#80Earlier quoted context omitted.
[*class|="text"] will also matched textWarning, textInfo, textCenter, etc.
Seems strange to me since the spec says the following: Represents an element with the att attribute, its value either being exactly "val" or beginning with "val" immediately followed by "-" (U+002D). it should match text-foo or text but not textFoo
You are correct, that selector would not match textFoo. It is the same as [class^=text-]. The real problem with using these attribute selectors with classes is that they only apply to the first class in the class list. If your element was something like "", then it would not be matched by that selector.