After a few weeks of hardcore bugfixing, Jacob and I are happy to finally push out a fairly stable patch to Bootstrap 2 that resolves a bunch of issues. Here are the highlights on what’s new:

• Previously the docs called for use of .control-label in the examples, but the CSS didn’t make clear use of it. This class is required for horizontal forms and has been reflected in the CSS.
• We’ve tried our best to improve rendering of buttons and icons across all browsers. Some issues remain; Firefox throws an !importanton line-height for inputs, so that’s the big one.
• We refined the label component style to move away from uppercase.
• Added the black button option, .btn-inverse.
• Added a mini button class, .btn-mini.
• We had to re-add the protocol, http: to the HTML5 schim because IE7-8 wouldn’t recognize it, dropping some HTML5 support for those browsers and introducing major performance issues.
• Resolved some issues with responsive layouts where media queries would overlap at 768px and 980px.
• Rearranged Scaffolding docs page to split fixed and fluid grid systems.
• Tons of docs updates for typos and language changes.

For a full list of bug fixes in this release, check out the 2.0.1 milestone on GitHub. All in all, we closed over 100 issues with over 150 commits—not bad for a patch release! A big thanks to all who reported bugs and added pull requests, we couldn’t do this without you nerds.

When building a CSS design system like Bootstrap, it’s important to keep things simple, durable, and flexible. This is no easy task, especially on larger teams and projects where the number of components can become quite high. To help improve this situation in a CSS design system, you might consider using prefixed classes instead of chained classes.

Taking the chained classes approach, your CSS selectors might look something like this for a given set of components:

.success { ... }
.btn.success { .. }
.alert.success { ... }

We have here a global base class, .success, that might house all the commonalities between successful buttons and alerts. Then, at the individual component level, we add on or override as necessary. However, this wide open class and chained approach exposes developers to a number of questions and potential paint points:

• What’s that base class stand for?
• What elements will be affected at the root level?
• How many elements have .success chained onto them?
• Can it be extended further to more components?
• What if one instance of .success uses green text on a white background while another uses white text on a green background?

And those questions barely scratch the surface. This solution isn’t necessarily bad, but when scale, brevity, and flexibility are your top requirements, it might not be the best idea. A better solution might be using prefixed classes.

Prefixed classes guide developers towards a simpler and more maintainable direction for building an extensive CSS design system. Here’s what we have if we take away the generic base class and scope things per component with prefixes:

.btn-success { ... }
.alert-success { ... }

This way, the base class is at the component level and not the entire system level. In other words, our base classes have become .btn and .alert, not .success. There’s no bleeding of styles or behavior from one component to another here because we treat components in a “successful state” as an idea across the design system. That is to say, we have a shared idea of what “success” looks for buttons and alerts, but the execution is scoped entirely to each independent component. No questions of where common styles are used and no concern of unintended effects, making each component more durable and flexible.

While a very tactical and detail-oriented practice, building components that inherently isolate themselves for improved modularity and customization in a system like Bootstrap makes for better code and a more enjoyable project down the line.

If you didn’t have a chance to make it out to last week’s event, you can view the slides on Speaker Deck from our Bootstrap 2 announcement at Twitter HQ. In our presentation, Jacob and I walked through a brief update and history of Bootstrap, some of the new hotness in v2, and a quick look at the future of the toolkit. Also, be sure to check out the slides from Rob Sayre‘s Hogan.js talk and Sean Herron‘s NASA & Open Source talk.

Thanks again to all those who made it out, helped test Bootstrap 2, and contributed to the project. We couldn’t do it without you nerds!

My fellow nerds, I’m very happy to announce that Bootstrap 2 drops January 31. To ensure we have the very best release possible, we’re opening up the branch and encouraging everyone to jump in and test the new code. We have a lot of new features, rewritten documentation, and use cases to test with the addition of media queries.

This week at Twitter is Hack Week and Jacob and I have dedicated the entire week to working on Bootstrap 2 to get ready for the release. There’s a ton to do, but we’re confident we can get it all done with your help testing and providing feedback on the new hotness.

Here’s how you can help:

• Head on over to GitHub and checkout the branch, 2.0-wip. It’s our essentially our master branch right now.
• Don’t want to check out any code? We’re hosting the latest version of the docs so you can easily load it up on devices and such for testing. (Please don’t host any other version of the docs for now!)
• Load up the new docs in your favorite (or, ideally, your least favorite) browser or device and start testing.
• When you find a bug or have feedback, open a new issue on GitHub. Tag it as 2.0-wip right away so we know to prioritize it. Please include as much context and information as possible. If it’s a visual bug, please include a screenshot. If it pertains to javascript, consider including a jsfiddle.
• If it’s a code fix you can make yourself, go ahead and submit a pull request to 2.0-wip. Be sure to read the Contributing to Bootstrap wiki page first though for a bit of insight into our code practices. (Unsure how to submit a pull request? Learn more here.)

We’re super close to getting Bootstrap 2 out, but we need your help to make it the best it can be. Any help you can spare would be fantastic and much appreciated.

Thanks in advance, and see you next Tuesday with the finished release!

Not too long ago I was asked by the A List Apart crew to contribute an article on Bootstrap. After some delays due to the Twitter redesign, the holidays, and some run-ins with the flu, I’m very happy to announce that the article has been published in today’s new edition.

The article, Building Twitter Bootstrap, focuses on the decisions and processes that went into creating Bootstrap. In short, a super small group of developers and I got together to design and build a new internal tool and saw an opportunity to do something more. Through that process, we saw ourselves build something much more substantial than another internal tool. Months later, we ended up with an early version of Bootstrap as a way to document and share common design patterns and assets within the company.

After a year of working on it on nights and weekends, we open-sourced Bootstrap in late August 2010. It’s since become the most popular project on GitHub with over 14,000 watchers and 2,400 forks. There’s a lot more in store for Bootstrap, including v2 launching in the coming weeks, and I couldn’t be more excited about the coming months at Twitter.

Also, a special thanks to Mandy Brown and Krista Stevens as editors for the article. Without Mandy’s incredible ideas and insightfulness, and Krista’s editing and article preparation, the article wouldn’t have happened. It’s been a pleasure working with both and I hope to do so again in the future.

Head on over to A List Apart and give it a read.

Bootstrap 2 brings new responsive features and a large part of that is the grid system at its core. With BS2, we’ll be leaving behind our 16-column overlords and moving to a flexible 12-column grid system. Nothing substantial should change in your use of Bootstrap, but I wanted to share some thoughts about this new (to Bootstrap) approach.

To date, mobile and tablet devices were all virtually ignored. No more–Bootstrap 2 will provide support for mobile devices out of the gate. Responsive features will be available and should provide at least some level of support for all our major components.

By leaving the 16-column grid system behind, we save some headaches and streamline some code. 16-columns required extra CSS for a 3-column layout and we were including an extra 8 columns for those wishing to add 24-column support. No more. We’ve removed the extra CSS and gone to 12-columns, all while retaining the same overall default site width (940px) and adding responsive variations.

Not much changes for those using Bootstrap when we release 2.0. We’ve been using this grid in the our development of 2.0 for several weeks now and are quite fond of it. Just be sure to check your column sizes and test your projects on mobile and tablet devices when you upgrade.

Follow along with Bootstrap 2′s development on GitHub with the 2.0-wip branch.

After a few recent projects, I’ve realized a good commenting strategy is necessary in CSS (and any other language really). After running into problems of our own with mysterious or vague code, I figure I’ll share my general set of quick and flexible guidelines for commenting in CSS.

Here’s what my typical (non-LESS) CSS file looks like:

To start, each file should include a repeated name and short description. While the name here can be the same as the filename (as I’ve indicated), combined with the description, it can help you add clarity for other designers. For instance, if you compile multiple CSS files, these comments can guide you in reading the final file.

Moving along, every major component is broken down into its own section. Not shown above is that each section has two to three lines after it to space things out. Subsections of that component have their own sub headings as well to further break things apart for readability and documentation.

Really though, the last two types of comments are the most important to me. The others are honestly more of a formality and sanity check as searching is just as fast in most cases. These last two are what keep you and your coworkers happy. Take this example of a typical comment and snippet of CSS:

The comment adds no value to anyone because it doesn’t tell you why this code is there in the first place. Here’s what might work a bit better:

While not the greatest example in the world, it illustrates the point. The last type of commenting, inline notes, works well with this as it provides line-by-line justification for properties. Even though some folks might know \9 is an Internet Explorer hack, not everyone does and comments don’t hurt anyone.

CSS, and any code for that matter, is much more legible and maintainable with the right comments. The why’s and inline context matter most for justifying why blocks of code appear in your files in the first place. Most importantly, commenting makes or breaks a team’s ability to quickly execute and update projects. Figure out your own solution, carry it through, and watch your projects become easier to maintain.

I’m a sucker for CSS conventions. Beyond CSS property order, general code formatting, spacing, and commenting are all up for some discipline. To keep things nice and tidy, and to save time in the future, I do my best to streamline my code. Figuring out the right formatting for CSS properties, especially properties like border-radius and box-shadow, is near the top of my list.

Take for instance this block of CSS:

Straightforward enough. We have our vendor prefixes first, ordered by character length (a complex of mine I’m afraid), and ending with the official spec for that property. Great, but we can do better!

Ah, much better! Why? Well, if you’re a fan of code editors like Textmate, Coda, or Sublime Text 2, then you can easily edit multiple lines at a time. In Sublime Text 2—my editor of choice—I just have to hold Option while clicking and dragging to select multiple lines to edit.

With the values lined up, I can not only read my code faster and easier, but I can edit it faster and easier as well. A little bit of guidance on code formatting goes a long way for your own sanity, and those of your peers.

CSS property order matters, especially on larger teams with several engineers and designers all contributing code. I know it’s been discussed, but frankly there’s always room for improvement and alternate approaches. In a few projects at Twitter, we added the constraint of consistent CSS property order to make onboarding new folks easier, debugging faster, and expectations of what exactly a block of CSS does that much clearer (without viewing it in the browser).

High level overview

At a high level, here’s our breakdown:

• position
• display and box model
• font, leading, color, text
• background and border
• CSS3 properties like border-radius and box-shadow
• and a handful of other purely visual properties

We hadn’t really seen an approach like this in any other projects we’ve worked on. It mixes the common structural and alphabetical approaches into one in an effort to ensure our property order is logical, scannable, and all-encompassing. We wanted an order that mapped to how we mentally visualized DOM elements and—to an extent—how Webkit’s Inspector presents properties.

Show me!

Getting more specific, here are some blocks of CSS might look with this property order in mind.

Here you can see positioning, box model (height and padding), and visual (background-color, border-bottom and box-shadow) in their proper order. This flows in such a way that you can discern that this is a fixed dark gray bar with a drop shadow–you know exactly what it is you’re dealing with as you read line-by-line.

In this example, we have only box model and visual. Notice that for box model, we have dimensions first with min-height and padding (as that adds to the overall width of an element). For the visual elements, background-color and border come first because those inform you how this element starts to look (e.g., a gray box witha border). border-radius and box-shadow follow that because those are additional visual treatments that add to the base look and feel.

Use what works for your team

This approach seems to work well for us and our teams without adding too much overhead. All you need to do is create a series of rules and stick to them with your team and this because a very successful tactic for organizing and maintaining CSS. No one solution is teh best, so keep that in mind and adjust as you go.

Today I’m stoked to announce the release of my unofficial GitHub buttons! For months I’ve wanted to provide consistent, easy-to-use links back to my projects’ source and documentation on GitHub. A couple of weeks ago I was finally able to create a decent method of doing just that. Now, I want to share them with everyone and get feedback from the community.

Functionality

For their initial release (and due to lack of time and expertise), functionality is limited to a static link back to your repo and dynamic counts for the number of watchers and forks on any public repo. In the future I’d love to expand on this to support user profiles and—one day—dynamic buttons via oAuth.

How to use

Using these new buttons is as easy as adding an iframe and setting some paramaters in the URL. It’s fast, easy, and pretty lightweight. The best part is that these are hosted on GitHub pages, which means you don’t need to host the code yourself. Just add and go. It also comes with a few options: watch or fork button, count or no count, and default or large size.

The two buttons above are live examples of Bootstrap’s watcher and fork counts. Everything but the size of the iframe is configurable via URL parameters. (This was the easiest and fastest way for me to get this project out the door.)

Get it on GitHub

You can find the source on GitHub. Feel free to download, fork, or watch it from there. If you have any feedback or want to contribute to the project, go ahead and open an issue or submit a pull request.