That said: no idea what's in Bootstrap 2. Someone got a concise summary?
Here's my quick (and probably incomplete) list:
- new 12 column grid
- responsive layout
- tons of new JS plugins
- stacked forms are now the default
- lots of new 'controls', like split buttons, new tabs, toolbars, highly styled radio buttons and check boxes.
- icons(!)
I have this sneaking suspicion that even if Zurb does a 'good' job, unless it's way better, they're never going to get the publicity these guys do, and thus won't have quite the same feedback loop.
Button groups. Toolbars. Icons sprites. Progress bars. Checkboxes and radios as buttons. More appropriate terminology (Tooltips instead of Twispies). Some retouches on styling and class naming. An overall increase of functionality for most of the existing stuff.
It's definitely a worthwhile upgrade, and it seems to be all added functionality, not a lot of semantic changes.
I just converted a ton of stuff (like last week), so it's pretty fresh in my mind. I feel like I should have checked the wip branch first, but this has really become my favorite kit. I've been about 95% YUI and the remainder OOCSS, and Bootstrap is the fastest concept-to-reality I've used.
I'm not too worried about upgrading if there are some compelling reasons to do so.
What's the win going from 16 to 12 columns?
I have use for both.
- Responsive design using media queries
- CSS Progress bars
- A few new javascript plugins (Carousel, Typehead)
- Icons
The documentation is online here in case you missed the link the article : http://markdotto.com/bs2/docs/index.html
Maybe someone has a better summary
a) Bootstrap uses less and I'm using bootstrap.
b) It was trivial to go from sass to less. Mostly just renaming files to have the right suffix.
c) I'm sure someone can argue differently, but I really think that the mixin syntax for Less is significantly better than Sass. I don't use mixins all the time, but this is really important if you want re-usable code. With Less, you don't have to declare @mixin and then @include it. Instead, any less block becomes a potential mixin.
That said, Sass has a compressor/minimizer and Less doesn't really have one. I had to integrate clean-css into my builds. It would be nice if Less had this by default.
http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#im...
Sass, too, supports Less’s mixin model. Sass can include any block as a mixin with the @extend directive (http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#ex...). Basically, if a block is going to be used in the HTML as well as elsewhere, you write it normally and then include it with @extend. If a block is only going to be included in other styles, you write it with @mixin and then include it with @include. I think Sass’s approach is better because it’s more flexible – if a style isn’t going to be referenced in the HTML, it doesn’t clutter up the CSS because it is hidden with @mixin. And if you like Less’s approach better you can just use @extend everywhere.
The main reason I prefer Sass is the indent-based and semicolon-less Sass syntax (as opposed to the SCSS syntax). I find that that syntax’s advantages greatly outweigh its few weaknesses.
Odd, it says that lessc can take --compress, but using the most recent version of less in npm says that there's no such flag.
Maybe it's on the way, or the bootstrap authors know something we don't.
A big thanks to Thomas if you read this, a gem is way nicer than converting it myself.
The learning curve on this one was not bad at all -- the examples are great!
Don't mean to hijack, but I'm curious if anyone has gone the other way, i.e., choose backbone over knockout. My main concern is DOM overload/GC issues. Backbone is also considerably smaller, but that's not as important in my context.
Hell, I would even strip out the localStorage and include a php script that hits a sqlite database.
Looking forward to digging into Bootstrap 2.
(you can also add the 'primary' class to provide a splash of color and highlight the recommended action)
Question: I notice that the button styles are still static (as are a lot of the color styles). Are there any plans to implement project-wide color changing based on the primary color variable?
I ask because I've hacked this out manually in a project at my day job, and another in my own free time. [Edit]: + I'd be more than happy to contribute this.
(Probably should crosspost this to Github.)
You can always change and recompile.
What I mean is, almost all of the colors are hard coded, unlike primaryButtonColor. You can easily adjust that one, but the others are trickier.
The newest version of variables.less in the 2.0 wip branch seems to have these colors bubbled up to easier access, already, now that I look at it. But still, the buttons aren't all exposed - just the primary button. That's what I was suggesting.
I've been waiting for this release for an upcoming project. I assume the use of HTML5 specific tags is optional. I noticed that the page used for the docs uses "<ul class="nav">" instead of "<nav>", but does utilize the "<footer>" tag. Is there a specific advantage to not using the "<nav> tag?
<ul class="nav">
<li></li>
</ul>
<nav>
<ul>
<li></li>
</ul>
</nav>
Seems like a very big increase.. Should we be worried?
(edit: Looks great though ;)
Should I bother "porting" them to Bootstrap or is there no real advantage?
I still am reluctant to move to Bootstrap, but due to its popularity I think it will get more updates and will attract more people willing to improve it ...
Thanks so much to the twitter team.
It seems non-admins cannot tag/label an issue, FYI.
Used Bootstrap while building my new (launched today!) project. It sped up overall development more than I could have imagined.
Really excited for the responsive upgrades.
