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?

Was wondering that too. First thing that comes to mind is that 12 columnn is more flexible for responsive layouts, which is another big addition in v2.

For example, since 12 is divisible by 3, it's easier to create a responsive site with 3 vertical sections that collapse into a single vertical section on mobile devices. (Like the Less Framework's mobile layout: http://lessframework.com/. Not the best example, I know I've seen a better one, but can't find it atm, but that gives the general idea.).

Don't know for sure if that's the reason, though.

[edit] Essentially it's more expressive. Another commenter correctly mentioned that it could have the same advantages above for a responsive design. 12-columns allow for greater freedom of expression at all display sizes.

You basically can divide it in half (6 columns each), in thirds (four columns each) in fourth (three columns each), in 6th (two columns each and in all 12 plus of course spanning the entirety.

16 gives you only 1, half,

Basically you need look at your design in order to determine what would make most sense.

A very popular choice is to divide it into three equal sizes and then have one of them be the right or left column, while the two others combine to form the other column.

So you end up with two columns one for content and one for navigation (typical blog look)

Grids can obviously also be much more complicated as those used in photoshop, 3dmax, word or windows/osx.

If you want to get really into grids I can recommend probably the best book written about them.

Josef Muller Brockman Grid Systems

http://www.amazon.com/Systems-Graphic-Systeme-Visuele-Gestal...

The Grid Systems book that was recommended earlier is a better bet if you're a typographer or graphic designer, and particularly if you're thinking about designing novel grid systems. But you're not doing that. The Bootstrap grid is trivial and does not require any background in design to use.

I mean I am a designer but still taught myself programming and is generally interested in technology.

Understanding design better will make you a better programmer IMHO.

_Elements of Typography_ (which also has some coverage of grids, along with meter systems), yes. _Elements_ is a buy-immediately book (and a joy to read).

Although, nothing beats Brockmann's Grid Systems book mentioned earlier.

http://www.amazon.com/Ordering-Disorder-Principles-Design-Vo...

Want something on your page to be 3 columns wide? <div class="span3">...</div>

Want to make it 4 columns wide instead? <div class="span4">...</div>

  .span3
    = render :partial => "col1"
  .span3
    = render :partial => "col2"
  .span3
    = render :partial => "col3"
  .span3
    = render :partial => "col4"

  .span4
    = render :partial => "col1"
  .span4
    = render :partial => "col2"
  .span4
    = render :partial => "col3"

    #sidebar {
      .makeColumn(4);
    }
    #main_pane {
      .makeColumn(8);
    }

    #sidebar
      = render :partial => 'common/sidebar'
    #main_pane
      = yield

It's a headache, but as I was saying, it's so much quicker to work with than many of the others that I might just dedicate some time to do the work and get on board.

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

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.

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.

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://lesscss.org/#-mixins

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.

https://github.com/cloudhead/less.js/pull/504/files

https://github.com/jlong/sass-twitter-bootstrap

A big thanks to Thomas if you read this, a gem is way nicer than converting it myself.

Thanks so much to the twitter team.

It seems non-admins cannot tag/label an issue, FYI.

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>

https://github.com/twitter/bootstrap/tree/2.0-wip

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 ...

http://foundation.zurb.com/

http://paste.ly/

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)

http://paste.ly/pastes

intentional?

http://paste.ly/pastes/25

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.

Seems like a very big increase.. Should we be worried?

(edit: Looks great though ;)