Tuesday, January 24th, 2012
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!
Tuesday, January 17th, 2012
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.
Friday, December 16th, 2011
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.
Monday, December 12th, 2011
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.
Tuesday, December 6th, 2011
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.
