markdotto

As another commenter pointed out, you can recompile the .less files, excluding what you don't need. You can also use the web customizer in our hosted docs at getbootstrap.com.

Fellow GitHubber here :).

No, we don't use Jekyll for our blog. It's part of the GitHub.com codebase I believe.

For chat, all standard stuff really :). We use Campfire for group chat (dozens of rooms), Gtalk/AIM/etc for individual chats, and Skype or FaceTime for video chats.

Sorry, my typo made this more confusing. We never supported IE6. IE7 was supported through 2.3.2. With v3, we dropped IE7 and now support IE8+.

Yeah, sorry about those changes in the RCs. Really we used the wrong label and are sorry about that. All in all though, everything with those pre-releases worked out really well. Just a naming thing :).

And thank you! <3

v2.x supported IE7, so yeah. Since we dropped that we were able to make use of it.

Edit for typo

Yup, and we'll be working with these folks make this more official shortly. Stay tuned!

We do.

Naming changes were for consistency across the framework.

We only use `!important` on utilities where specificity would make them impractical. Quick floats, toggling by viewport size, etc make it necessary unfortunately. When it comes to every other component though, we don't use it at all.

Major version release enable us to break backward compatibility. Other motivations aside, I see no reason to not do it in attempts to do something better.

True, we could be louder about that. I'll get a tweet out about it shortly. To be honest I totally forgot about even mentioning it anywhere but in a few @ replies and issues on GitHub.

And once we add the theme, it'll become clear :).

Thanks for the feedback! <3

v3 will ship with a v2-ish theme that you can optionally enable.

Yeah we probably should have called them betas, but I'm fine with using RC—beta sounds way less serious and we want folks to just go to town on this. It's helped a lot.

And glad to hear you're a fan! <3

Super interesting—I did not realize that :). If you guys ever want to pass along feedback on how that went and what you did, please do! <3

We've always used purple, save for the months of red in the v3 dev work that we then changed just a couple days ago. The purple was pulled directly from http://static.djbooth.net/pics-tracks/asaprocky-peso.jpg :).

Actually it is—it might behave perfectly right now, but the intent is that it is mobile-first and responsive like nearly every other component. If you're running into problems, let us know though via issues. <3

Awesome to hear, yo! <3

Indeed there will be at least one more RC.

Thanks! And no, probably not—the two are most definitely not directly related.

Meh, I'm usually not one for variety :).

The purple space background was designed by an illustrator here at GitHub and I just put it to use. That the page ended up being purple and blue like Bootstrap is kind of just a coincidence. Previously the Enterprise site's background was a custom-made OS X ish space background—lots of blue and gold.

Beyond that I don't see a huge concern of the two looking similar. Bootstrap 3's homepage will be massively different from v2s today if it helps though.

I wrote all the styles for Bootstrap and refactored GitHub's forms and buttons a few months ago for a similar approach. Not 100% the same, but definitely close. All those styles are tested thoroughly within Bootstrap and made it super easy to update and standardize our styles, while at the same time dropping mad duplicate code.

The overall homepage though I think looks nothing like Bootstrap's docs, if that's what you're implying. Also, Bootstrap, and GitHub, was not influenced by Dropbox. We just iterated on that stuff internally in a pull request and shipped when we were happy with it.

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.

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.

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 don't ever recall saying that, but if I did, I'm happy to have been wrong. Super stoked about the direction we're going.

Pretty much. Plus, it's a much better (and more socially known) metaphor for describing its function and presentation.

Negatory, but given the prominence of the ports and use of Sass, we'll likely try to do something here to help folks out who are using that over Less. No reason we couldn't write a script to translate the two or officially sanction a port. Both have their pros and cons; just a matter of time, duplicate code, etc.

Vim wasn't the exact reason, but text selection is a huge part of it. Readability and text selection are huge.

That should work just as you described it.

The default grid system will be come fluid (using percents for widths), so you'll have to just find and replace the row classes and you should be okay. Unsure about more complex layouts though.

Yes, of course. The customizer will continue to have the ability to include or remove the media queries for these. You can also always make a local build on your own to do it.

You should be able to use find-and-replace to tackle most of this—the classes aren't changing too much.