The Huge Update to Twitter Bootstrap

It may not be ready for production, but the release candidate for version 3 of Twitter Bootstrap is a huge change from 2.3 and has me very excited about its future. Sadly, they have done very little related to JavaScript, but that doesn’t mean I can’t enjoy it. Let’s take a quick look at some of the major changes appearing in Twitter Bootstrap 3, CSS and JavaScript alike.

The first thing you have to realize is that version 3 isn’t fully released yet. They’ve just made available Release Candidate 1 – essentially one step closer to being production-ready than a beta version. They expect bugs to be present and are hoping people like you will help them find those bugs. DO NOT USE ON PRODUCTION SITES… yet.

The Changes

If you don’t trust what I say (I can’t imagine that) or if you want to see the full list of changes, check out this document, which is being continually updated as changes are made. The main documentation is also updated to show off version 3’s features.

This is not a drop-in upgrade to 2.3. In fact, if you just swap out the CSS and JS with this new version, it’s quite likely that the majority of the site will be broken. There are NUMEROUS breaking changes in this version, so you might as well start fresh.

The Grid System

Bootstrap 3 has gone mobile. Previously there was a responsive grid when you included the separate stylesheet. Now there’s no way to have a non-responsive grid. The stylesheet is mobile-first, meaning that the base styles apply to small screens, and styles are changed as the screen gets bigger. This probably won’t make much difference to someone who is using it, but it could. To better support responsive design, the columns are always sized with percentages, though at different breakpoints the .row elements can have fixed widths. The fact that the columns are sized with percentages means that when you nest columns, even the nested layers will have 12 columns.

They’ve kept the 12-column grid, but they’ve done away with the span* class and replaced it with col-*, col-sm-*, and col-lg-*. Why was it replaced with 3 different classes? Because they’re awesome, that’s why! It allows you to specify the number of columns you want an element to take up at different breakpoints. You can read about it on the docs, but they don’t make it extremely clear how this all works.

First off, there are 4 breakpoints: <768px, >=768px, >=992px, >=1200px. When we’re below 768px, the grid is completely fluid, but above that, the row containers have fixed sizes according to the breakpoint. If you use give an element the col-4 class, it would take up 4 columns (1/3 the width) at every single breakpoint, even on tiny screens. If you added col-sm-3 to the same element, then it would take up 4 columns in the smallest breakpoint, but anything at or above 768px, the col-sm-* will override col-*, so it will take up 3 columns. If you then added the col-lg-2 class to it, then at or above 992px the element would only take up 2 columns.

So, what happens if you only specify col-sm-* or col-lg-* on an element? If you specify col-lg-*, then it will apply to everything at or above 992px, and if the resolution is lower than that, then the element will be 100% width and will stack vertically (it will not float at all).

It’s pretty clever. I’ve always been disappointed with the way that these frameworks will just become a single column at some point. There was no way to have more columns on a small screen, even though some things would work fine in multiple columns on smaller screens. 992px is an interesting break point choice, but it doesn’t really matter too much. I am slightly disappointed that there isn’t one more class that would only apply to the largest breakpoint, but it’s not a big loss.

In practice, though, I’ve been more disappointed that there isn’t a breakpoint below 768px. I can imagine countless situations where someone would prefer to have multiple columns above 500px or so, but stack everything below that. In the end, though, you can always just customize the breakpoints to your needs. Four breakpoints should be enough, so just go change a few numerical values around.

Clean Style

Bootstrap has taken out some of the more stylistic bits to focus more on structure and allow you to add in your own style without needing to override or remove the default styles. They’ve also made the styles flatter. Take a look at the buttons, for instance. They are a solid color; no gradients or shadows. Well, that’s not entirely true. There’s an inset shadow when the button is active, but otherwise they’re flat. Also, they’ve removed the “inverted” button style and instead made the default button style black (very dark gray actually, but whatever). I understand taking about “inverted” because it has no semantic value, but now none of the buttons really feel secondary. They all pop out for attention. There is an issue started that is trying to get a btn-secondary class added so we can have a lighter colored button that won’t stick out so much. I’m all for this, and if you agree, you should go put your word in to make sure this happens.

Icons

Icons have been removed completely from Bootstrap. As nice as it was to have this included automatically with Bootstrap, they have some decent rationale behind the decision.

These are the most notable and noticeable changes related to CSS. So what about us JavaScripters?

JavaScript Changes

There aren’t a whole lot of changes to JavaScript, though there are a few changes that are related to JavaScript. They removed a friend, made some changes to Modals and Carousels, and added better Bower support.

No More TypeAhead

Previously, Bootstrap included an autocompletion plugin, but it has now been removed. Why? Because Twitter is already producting a different autocompletion plugin that is more powerful. They didn’t want to have two separate projects working on the same functionality, so they dropped it in favor of Twitter TypeAhead. This is fine with me because in the end, you should be concatenating all your JavaScript together and you shouldn’t be blindly including all of the Twitter Bootstrap plugins if you’re not going to use them all anyway. There were plenty of complaints from users, but if you’re doing things correctly, this should be a minor issue.

If you’re going to replace Bootstrap’s TypeAhead with Twitter TypeAhead, you’ll want to take a look at the API documentation, though, because they aren’t fully compatible.

Modals and Carousels

The changes to these two plugins are entirely style-based changes, but since they are powered by the JavaScript plugins, I figured I’d put them in this section. To start off, modals have been designed to work much better on mobile devices. If the modal is too large to fit on the screen, the main body of the page is prevented from scrolling, so that when you scroll, it’ll scroll the rest of the modal will scroll into view and the page behind it will stay still. There were also some minor markup and style changes.

Carousels got a huge makeover style-wise. The dot indicators, previous and next arrows, and captions have all been changed quite a bit. As far as I’ve seen, there are no changes to the JavaScript and the only markup change is that you need to have an additional element within the .carousel-control elements.

Bower Usability

If you’re not familiar with Bower, you should go read about it. It’s similar to npm for the front-end (and potentially the back-end too). Using Bower you can just type bower install jquery and it will retrieve the repository for jQuery and load it into a folder in your project. Up until this new release, Bootstrap’s repository did not contain the compiled CSS and JavaScript files. Instead you had a folder full of numerous LESS files and a folder with separate JavaScript files for each plugin, so bower install bootstrap was mostly useless to most people.

I actually enjoyed this because then I could LESS in my projects and only pull in the Bootstrap plugins that I needed with RequireJS. But, very few people use LESS, and many people prefer to include the entire Bootstrap plugins file for convenience, so Twitter added a dist folder to the repository to hold the compiled CSS and JavaScript.

Also, they’ve changed their compilation tool from MAKE to Grunt so that it is more compatible across operating systems. Also, a lot of JavaScript and front-end web developers are learning Grunt now, so it may even be more widely understood than MAKE (this is entirely speculation of course). So now, if you use Bower to pull in Bootstrap, you can make customizations and build it yourself, kinda like jQuery’s new build option.

Conclusion

Twitter Bootstrap looks to have a very bright future. Though this update is largely incompatible with previous versions, it is because they are working hard to make Bootstrap the best tool that it can be. I’m very excited about these changes. I’m highly considering a new template for this blog and if/when I get around to it, I’ll surely use Bootstrap to handle the grunt work. God bless and happy coding!