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 what is depreciated and how to change/upgrade things to newer versions.
At what point in a project is it considered beyond the "bootstrap" phase? The way I see it, Bootstrap is the perfect CSS template to use when starting a project. But at some point the project will reach a level of maturity and complexity where "upgrading" to a new version of Bootstrap is perhaps far more effort (and error-prone) than it's worth. This is especially true when they do things like renaming classes or reorganizing the layout structure.
Note I think this applies primarily to the CSS part of Bootstrap which I consider to be more of a template than a library or framework; the JavaScript plugins are always pretty painless to upgrade.
Definitely agree. My company has been switching over to a centralized version of Bootstrap for our internal applications (over 300 in total, maybe 40 use Bootstrap so far). I oversee the upgrade process, and quickly/easily doing so remains a hurtle I have yet to gracefully overcome.
The best solution I've been able to cook up is adapting their changelog into a step-by step tutorial for developers to use when upgrading, though I'd love to hear any suggestions on improving that process!
I've heard this before and I think it's a great topic. Is the addressable issue that there needs to be a way to "upgrade" to the newest version or is there a fundamental oversight into how we handle upgrades of amazing resources like this. I feel like there is an elegant solution out there but it just hasn't been adopted into CSS and JS yet.
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.
I'll work with either, but kebab-case(or snake-case with dashes if you prefer) is a lot more readable in HTML source for me.
Also, all their CSS classes were kebab-case anyway, so it makes sense that they'd change their variables to match. It's a nice move towards consistency.
Many text editors view dashes as word separators, so double clicking on a variable name with dashes (to have the editor highlight all places it's being used) will only highlight the word you double clicked on and not the entire variable. This is also the case when moving the cursor by holding command/control and using the arrow keys, the dashes are considered separate words.
For that reason, I prefer using camel case.
What's interesting is underscores are not considered word separators in many text editors.
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.
Ah, see, you would have received an error when running this code!
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.
camelCase vs PascalCasing is used to signal and separate public from private in C#, so that you always know what kind of data or function you are working with.
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.
"results indicate a significant improvement in time and lower visual effort with the underscore style. The interaction of Experience with Style indicates that novices benefit twice as much with respect to time, with the underscore style."
Having said what I said, I'll program in any language and abide by any convention if required. That's just what you have to do as a programmer. No issues there. If a client requires camelCase, so be it, it's not like it is crippling.
If I have the freedom to do so, I tend to be very pragmatic about my own projects. I don't subscribe to fads both in my personal life and in software development. Camel case and Hungarian notation are just fads that, when surfaced, may or may not survive the test of time. The second, for the most part, did not. We'll see what happens with Camel case. None of this crap is necessary to write good code, or code that is bug-free, or code that makes you money.
Life goes on. Those who love to camelCase, hey, it's OK, not the end of the world.
> 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 remember the convention).
Utterly inconsistent. And it didn't make any difference to readability or maintainability, once people accepted that there actually is no single standard we can use.
In my opinion, it's one of these things like, e.g. significant whitespace or C brace style, that people believe make a difference because they have an example - in which the difference is often not attributable to the feature being discussed.
Well within several modules of the same project, I guess it's inevitable, and not that problematic, especially not between several languages; but seeing (at the top of one function)
int my_counter;
char hostName[256];
double LIFESPAN;
doesn't make for pleasant reading, I'm sure you agree.
But in a large enough project, there are several modules that cannot escape that:
Our main codebase used unix_conventional_names. Then, a GUI (FLTK, C++) was added, with classes like Fl_DoubleWindow; Every GUI part now had two conventions.
Then, it turned out that the abstractions FLTK gave on Windows needed a small nudge. So we added some Windows-specific stuff; that module had calls like FLTK Fl_RadioButton, Win32's TrackMouse, our main code's "user_action_t".
Then we added needed to add Python scripting (implementing a native Python module in C) - and since the most maintainable way to do that was to have the C names and Python names correspond, there's a module that also had Python convention names in it. Lather, rinse, repeat with JNI.
So, I would guess ~ 70% of the files ended up being "uniform convention" (with one convention, depending on source code language), and 30% had mixed conventions of up to 4 conventions.
And it didn't make anything a little bit unreadable. It's no more distracting than changing fonts in a document every paragraph (and occasionally in the middle of a paragraph) between several readable standard fonts (arial, courier, consolas, ...). It looks weird and bothering for the first few days, but is not actually distracting or hampering in any way.
And if anyone is going to reply "but new people who come into the codebase will be confused" - that codebase was moving millions of dollars per day, and was nontrivial enough that I wouldn't allow anyone to commit a change on their first week, often their first month, without two other people reviewing it (experienced people got only one person to review their code).
By the time anyone knew the code well enough to make a change, they weren't bothered by the multiple conventions either.
> doesn't make for pleasant reading, I'm sure you agree.
only lifespan, the upper case implying constantness when it isn't, bothers me. Other than that - pleasant as day.
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.
<?php $x = 55;
$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).
When someone, particularly a beginner, is reading the code and come across, say, an unfamiliar function name, then they know straight away whether to look for it in the language docs or a definition somewhere else in the code. Not essential, but handy.
I guess that only works for really simple project. Once you bring in third party libraries, your own common library, your own multiple layers of abstraction, this naming convention means almost nothing. It pays the price of annoying programmers who are already familiar with the code for not-so useful short term benefit of the very early beginner.
Surely there are better ways to deal with this problem. Different languages have different solutions for this, but completely breaking the naming conventions doesn't seem like the way to go.
That's a really bad thing in my eyes. Why teach a beginner that consistency is something that does not exist?
Also, non-english variables are an abomination! I've worked with code with some finnish variables. Not only is it harder to grok, it's actively distracting.
I believe it could be usefull for CSS selectors[1]
The following rule will match for values of the "lang" attribute that begin with "en", including "en", "en-US", and "en-cockney":
*[lang|="en"] { color : red }
So you may now be able to select with CSS elements with that syntax, for example matching all text-warning, text-info, text-center etc with just
*[class|="text"] { font-weight: bold }
Correct me if I'm wrong.
I don't know if it would be practical or not. Other than that it just a matter of preference, CSS classes tends to be generally separated by dashes from my point of view, whether I prefer Camel Case or not.
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 "<p class='content text-foo'>", then it would not be matched by that selector.
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...
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 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.
I literally just started going through Project Euler with Python now to get comfortable with the language.
I'll play with that and see. I can't think of any other language where this might matter.
Should I look for anything in particular or simply tabs vs space in indentation on any code?
# Problems from ProjectEuler.net
# http://projecteuler.net/problem=1
def problem_1():
return sum([n for n in range(1000) if (n%3 == 0) or (n%5 == 0)])
def problem_1a():
return sum(set(range(3,1000,3) + range(5,1000,5)))
# http://projecteuler.net/problem=2
def problem_2():
sequence = [1,2]
while sequence[-1] < 4000000:
sequence.append(sum(sequence[-2:]))
if sequence[-1] > 4000000:
sequence.pop()
return sum([n for n in sequence if (n%2 == 0)])
I did say I was just getting started!
I'll try the above and other code I wrote with a mixture of tabs and spaced and see what happens. Interesting. If Python actually breaks because of that it's a shame. I really like the language. Is it a matter of IDE interpreter (type code and execute interactively) vs. command-line interpreter (same as previous) vs. module execution (i.e.: "python my_module.py" from the command prompt)?
If I recall correctly, Python's indentation counts characters, so a single tab is not the equivalent of four or eight spaces, but only one. If you accidentally mix them, therefore, lining things up visually in your editor will result in indenting or outdenting where you did not intend.
Man, I love bootstrap. Not only is it pretty well design from the front end and back end. The less files that are architected are awesome, I wouldn't have thought of it on my own. The guys built it for full customization for advance programmers and dead simple for beginners. Keep up the good work!
The only disadvantage to this is that all startups are now 'lazy' and begin using bootstrap default theme colors and styles -- which makes all website look the same. I'm not sure whether I feel that we're losing creativity for people who want to play with colors or we're losing the ability to actually code up some CSS to make things pretty. (Just my opinion).
Dropping support for IE7 was a good idea. I believe that is the next browser we're killing after IE6, right? After all, who keeps versions of browser these days? I mean I lost count when Chrome updates for me -- and Firefox is on rapid release (18) now. I can't keep up remember all these numbers and browsers!
Please keep up the good work! Bootstrap is an awesome framework for the web!
I'll take the time to say thanks too, since they seem to be following this.
We've long had lots of open source infrastructure like Linux, Rails, Postgres, Apache, and so on and so forth that was very much a "by programmers, for programmers" affair. It's very nice to get some "design" infrastructure - Bootstrap has made my sites look a lot better, and I get compliments from people.
Pretty much everything in Bootstrap is gray-scale , with the exception of things with semantic function: red=error/danger, amber=caution, green=success.
The only exceptions are "primary" buttons (which was blue by default but based on the link color the last time I checked), info which is pale blue, and code samples which are pink.
I'm not in the slightest way artistic, but I feel if those (incredibly easily overriden) usages hold you back from expressing yourself with color then you're probably best not to bother and so it's a net-win either way.
In my opinion that is AWESOME that lazy startups are defaulting to basic bootstrap theme. 1) It is WAY better than the crap that a non-design oriented engineer would come up with and 2) it lays an awesome foundation for a designer to come in and make improvements. Usually engineers write the first 10,000 lines of code on a project so give them a dead simple UI framework so they don't create something horrible in it's place.
Maybe they could add support for color scheme designers to the customized version (such as kuler.adobe.com or colorschemedesigner.com, which are works of art in my opinion).
Also, some things are difficult to modify. What if I want two navbars, one with a different height than the other? Some tweaks seem pretty difficult to make.
I too feel a little put off by this. I find it immature and gratuitious, like others have said in this thread. This made me recall that in the examples they have HTML comments reading "le javascript" and "le CSS" if I recall correctly.
I have a personal pet peeve with people using 'Internet slang' outside _humor_ places on the Internet (some people I know overuse it to the point of annoyance), and so the discomfort I feel reading these terms sneaks up to my impressions of Bootstrap and its authors. Of course, rationally I know it's a good product made by outstanding people, so I still use it without refrain, though.
It's not about the language used, it's about the context. He's not expressing anger or making a humorous statement. He's just throwing f-bombs around to show that he's your "brah." I don't quite understand it, but every time i read something by @fat, i feel like i'm reading a YouTube comment from a 10-year-old.
I agree. If it were a discussion that would totally fit, but it's an announcement so it feels strange be to "talked to" in that sort of abstract and casual tone. Although maybe it's just a cultural thing.
There are some work environments where using "shit" and "fuck" would be a turn-off -- not all places are very relaxed about that stuff.
On a more personal note, it feels immature -- titling a section "Oh shit what" just for the sake of irony dilutes the meaning of what they're conveying. The info would be equally effective without it, and it's just filler.
I know people just want to have fun, but why not save the swearing for personal blog posts rather than a large (and growing) open source project?
I agree, it's gratuitous. Anyone with a swear filter (families, corporates) can't look at the documentation, and religious organisations may feel uncomfortable.
Being open source, perhaps there's a fork opportunity for 'Bootstrap without the swearing'.
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 to be funny and yet miserably fails.
I liked the casual tone. It read like the sort of thing you'd actually say when explaining the framework, and required less mental effort to interpret than program documentation usually does.
If this is all you have to complain about, maybe its time you tried something new in your life instead of criticizing others on how they conduct theirs.
re.findall() returns all non-overlapping matches. We need to use a positive lookahead on the third part of the pattern to stop it from consuming the non-character:
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.
...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.
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.
All mobile first means is that instead of scaling CSS down for smaller devices, we start from there and work our way up instead. So far it's smarter defaults, little bit less code, etc.
That should have read "forced to deal with 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).
But the point of mobile-collapsing navigation on mobile devices is for a better user experience. Why would you go out of your way to ignore that right away? And if you really didn't want it, you could always remove those lines of code from your file. Or comment them out so it's there when you revert.
I'll probably write up something at length about this decision when/if it happens… but this is the current thinking:
CSS transitions are just total shit to deal with in javascript.
What people often don't realize is that there is an event for transitionEnd in javascript – but this isn't always fired in a reliable way – only when a transition successfully ends (which isn't all the time).
This is incredibly problematic because often really important functionality is tied to the completion of transitions.
Because these functions never finish, sometimes you're left with dead dom nodes or weird incomplete states.
What's more, there isn't a performance benefit to using css transitions – the benefit is that they were suppose to be make transitions easier and provide a nice separation of style from logic – but they end up being incredibly more difficult and because of the necessary fallback logic, the styles end up leaking back into your logic anyways. It's a pain in the neck :/
With bootstrap we really just want to give everyone the most reliable product we can, and css transitions just aren't that.
Also, from what I hear, the spec is basically dead in the water – and a reliable cancel event isn't in the works (unless this has changed in the last month or so)… which is more of a reason to consider alternatives.
Most likely we will end up going with some sort of combination. CSS transitions when we don't need a reliable "complete" event – and css transitions when we don't really care (though this case is becoming more infrequent).
It's on our list to check it out because of some of lack of control CSS transitions afford us. Hacks with overflow hidden cause issues, mobile performance is rather spotty, and more. Not a guarantee, but we're considering it.
I'm working on a bootstrap 3 based project and tracking their development. They've been making fairly large changes (e.g. badges are gone, replaced with counters, labels are MIA as well but they're supposedly coming back) over the last month or so and have more to make on their roadmap.
If you're not having any problems you must be very lucky and/or are only using a subset of the tools they provide, it's not going to be a drop in update for most people, hence the 3.0 version.
Bootstrap allows developers to prototype something that looks good enough for production use without having to worry about a lot of the minutiae of layout.
For that, I will always looooooooooooooove yoooooooooooooouuuuuuuu ooooooooooooh Iiiiiiiiiiii will always loooooooooove yooooooooooooouuuuuuuu.
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.