markdotto

7 ms·

1.
by markdotto 13y ago
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.
2.
by markdotto 13y ago
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
3.
by markdotto 13y ago
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+.
4.
by markdotto 13y ago
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
5.
by markdotto 13y ago
v2.x supported IE7, so yeah. Since we dropped that we were able to make use of it. Edit for typo
6.
by markdotto 13y ago
Yup, and we'll be working with these folks make this more official shortly. Stay tuned!
7.
by markdotto 13y ago
We do.
8.
by markdotto 13y ago
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 ev
9.
by markdotto 13y ago
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
10.
by markdotto 13y ago
v3 will ship with a v2-ish theme that you can optionally enable.
11.
by markdotto 13y ago
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
12.
by markdotto 13y ago
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
13.
by markdotto 13y ago
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 :).
14.
by markdotto 13y ago
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
15.
by markdotto 13y ago
Awesome to hear, yo! <3
16.
by markdotto 13y ago
Indeed there will be at least one more RC.
17.
by markdotto 13y ago
Thanks! And no, probably not—the two are most definitely not directly related.
18.
by markdotto 13y ago
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. Previous
19.
by markdotto 13y ago
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
20.
by markdotto 14y ago
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.
21.
by markdotto 14y ago
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
22.
by markdotto 14y ago
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.
23.
by markdotto 14y ago
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.
24.
by markdotto 14y ago
Pretty much. Plus, it's a much better (and more socially known) metaphor for describing its function and presentation.
25.
by markdotto 14y ago
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.
26.
by markdotto 14y ago
Vim wasn't the exact reason, but text selection is a huge part of it. Readability and text selection are huge.
27.
by markdotto 14y ago
That should work just as you described it.
28.
by markdotto 14y ago
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.
29.
by markdotto 14y ago
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.
30.
by markdotto 14y ago
You should be able to use find-and-replace to tackle most of this—the classes aren't changing too much.

More ›