
Bootstrap 3 - bauerpl
http://getbootstrap.com
======
saurabhnanda
Is it just me or do flat styles actually have worse usability? There's
absolutely no visual cue for what's clickable and what's not.

~~~
wiremine
Yeah, I agree. A good case-in-point is the new button groups.

Here is 2.3.2:
[http://getbootstrap.com/2.3.2/components.html#buttonGroups](http://getbootstrap.com/2.3.2/components.html#buttonGroups)

And here are groups in 3: [http://getbootstrap.com/components/#btn-
groups](http://getbootstrap.com/components/#btn-groups)

There _is_ a rollover state, but it doesn't really convey it is a button
anymore.

~~~
zeckalpha
And rollover doesn't work if you are mobile-first.

------
yesimahuman
If anyone's interested, I wrote up a little guide on how to prepare yourself
for B3 - [http://blog.jetstrap.com/2013/07/bootstrap-3-how-to-
prepare-...](http://blog.jetstrap.com/2013/07/bootstrap-3-how-to-prepare-
yourself/)

------
pixelmonkey
The actual reason that all the styles are "flat" right now? One of the main
project authors removed them temporarily while he focuses on fixing other
issues in the current pull request for Bootstrap 3.

    
    
        mdo commented: Gradients and other embellishments have 
        temporarily been removed while I focus on other things.
        It has nothing to do with skeuomorphism or anything 
        like that.
    

Stop reading the tea leaves, people. Source:
[https://github.com/twbs/bootstrap/pull/6342#issuecomment-123...](https://github.com/twbs/bootstrap/pull/6342#issuecomment-12332378)

~~~
WickyNilliams
It would be pretty neat if all the "gloss" was an additional, optional
"module" that you could add in at your discretion.

People who want something they can work with straight away can then add that
in and get their gradients, drop shadows etc. People who want something more
basic that they can augment with their own styles can then choose to not
include this "module", and save themselves having to jump through hoops to
undo the default styles (which is a pain, as anyone who has had to do this
knows)

------
taspeotis
> Bootstrap 3

It's a release candidate. The first of at least two.

If you want discussion, check out
[https://news.ycombinator.com/item?id=6112141](https://news.ycombinator.com/item?id=6112141)
(disclaimer: my submission).

@mdo jumped in for a bit of commentary, too.

------
girvo
Man, I feel weird. I used BS2 temporarily, but then stripped it out for a
straight reset and grid system. Old habits die hard, I guess, and what I Want
from a UI doesn't always match Bootstraps ideas... I'll give this another shot
for my startup prototype, but I have a feeling the same will happen.

Is anyone else like that, or am I now old-school at the ripe age of 22?

~~~
moogleii
Maybe Foundation would suit you better. I heard it's a bit more lightweight
than BS.

~~~
nahname
I checked it out for that reason. Then I found a number of social images and
began wondering why a lightweight CSS framework needed images for facebook,
twitter, etc...

~~~
jaredmcateer
You mean the Social Icons in the _Add-ons_ section? You don't need to include
those, in fact, I believe they are opt-in, not opt-out.

~~~
nahname
Just checked and you are correct.

~~~
thatswrong0
If you want something lightweight, I wouldn't go for Foundation either. Even
after stripping out the unnecessary stuff, I found it overly obnoxious to
style.

I ended up with the Skeleton framework after struggling with both Bootstrap
and Foundation for a few days. It was a much better decision. I've also been
eyeing Bourbon Neat lately as well.

------
message
Dude,
[https://www.hnsearch.com/search#request/all&q=Bootstrap+3](https://www.hnsearch.com/search#request/all&q=Bootstrap+3)

~~~
scrrr
So what. Now all the people that haven't seen it will notice. heh

~~~
thejosh
It's still on the second page of HN, was on the frontpage for a while.

~~~
GoNB
I guess it goes to show front end design is one of the most controversial
topics on HN. On GitHub, Bootstrap has maintained an almost permanent position
in the daily top ranked repos.

------
xtrumanx
I don't think I get the new grid system.

    
    
        <div class="col-12 col-sm-8 col-lg-8">.col-12 .col-lg-8</div>
    

What's going on here? If I were to guess, I'm assuming it's going to be 12
columns if its a mobile, 8 if a tablet or a desktop.

In what situation would that be useful? It looks like you'd end up with some
pretty complicated mark-up quickly like that.

~~~
timdorr
In order to reduce complexity like this, you should avoid using Bootstrap
classes in your HTML directly.

Instead, use semantic class names for your app and use the new &:extend()
directive in LESS 1.4 or @extend in SASS (if you're using bootstrap-sass).
You'll end up with much more readable HTML and CSS, and will insulate yourself
from future changes in Bootstrap.

I do stuff like this in SASS

    
    
        %flash {
          @extend .container;
          @extend .alert;
          margin: 15px auto;
          border-radius: 0;
        
          .close { top: 0; }
        }
        
        .flash-success {
          @extend %flash;
          @extend .alert-success;
        
          .close {
            color: $successText;
            opacity: 1;
          }
        }
    
        .flash-error {
          @extend %flash;
          @extend .alert-error;
        
          .close {
            color: $errorText;
            opacity: 1;
          }
        }

~~~
WickyNilliams
I'll politely (and completely) disagree with this. I much prefer the HTML
convey semantics (to the dev, not to the user) than having magic happening
behind the scenes with CSS.

By having the classes in the HTML, you know at a glance what is going to
happen. Whereas using extend there's an extra layer of indirection, you end up
having to look at the HTML, see there's a class called something like
"sidebar". Then you have to look at the SASS, find the sidebar class to see
there's an extend directive, then and work out what's going on in there.
That's an extra step i'd rather avoid.

People usually follow this approach to get "clean" or "semantic" markup, but
there's some falsehoods in that thinking. The "markup looks ugly", or is "non-
semantic" are misguided: no user agents infer semantics from classes, and the
ugliness you describe is purely aesthetic, _the real beauty is in the
semantics the developer can infer from having clear and obvious classes in the
HTML_. Another classic argument is it makes the markup bloated. This may be
true on the surface, but when you factor in GZIP, it is completely negated as
more repetition == better compression.

A great read on the topic is Nicholas Gallagher's article "About HTML
semantics and front-end architecture"[1]. Reading that article for the first
time was one of those moments of clarity, where your previous perceptions are
completely shattered. Hopefully you guys will feel the same :)

[1][http://nicolasgallagher.com/about-html-semantics-front-
end-a...](http://nicolasgallagher.com/about-html-semantics-front-end-
architecture/)

~~~
timdorr
I'm not sure I follow. You're basically arguing for including style attributes
throughout your HTML. CSS classes are always a layer of indirection,
regardless of whether they are semantic or functional. As such, you shouldn't
be forcing style and layout directives into the structure of the document.

The main benefit of what I'm describing isn't actually semantics. It's
allowing CSS to do what it does best: cascade.

Say I've got an application where I've got several pages with unique layouts
and the designer has come up with a new form style that has all the labels
inline instead of on top of each input and has a new dynamic tour system that
needs some area on the right of each form.

If you were using Bootstrap classes directly, you'd have to go to _all_ of
your forms and add .form-inline and change the column size classes. You
wouldn't want to redefine what those classes are because that may have effects
on other areas of the application. This may also break some of your
Javascript, as it was dependent on those class names.

If you were using semantically-named classes, you'd simply change the width
and add @extend .form-inline to your main form placeholder (which is in turn
@extend'ed by any specific form class). Your HTML would stay the same, meaning
any Javascript dependent on those classes wouldn't break.

~~~
WickyNilliams
No I'm not arguing for style attributes, that's a maintenance nightmare
waiting to happen (with very little waiting needed!). They are a layer of
indirection indeed, but which of these do you think conveys more
information/semantics to the developer (these aren't bootstrap specific
classes, just illustrative):

<div class="sidebar"> <!-- content --> </div>

<!-- or -->

<div class="sidebar grid-one-whole grid-one-half-medium grid-one-third-large">
<!-- content --> </div>

The second one is _way_ more verbose, but at a glance you know exactly what is
happening (assuming my class names are obvious enough). The classes convey
information that an amalgamated class you get from @extend simply cannot.

First let me say that a lot of what I'm talking about is optimal for building
large-scale web sites with lots of page variants. Your mileage may vary for
smaller sites, the principles can still be applied, but you might not need
adhere to them as strictly.

There's been a movement in recent years, Object Oriented CSS (OOCSS). This
ethos urges the developer to write CSS as they would other code, using the
hard lessons that have been learnt in other language. We should be thinking in
abstractions, utilising the single responsibility principle, favouring
composition over inheritance, loose coupling, and self-documenting code. I'll
go through these one at a time, because the benefits of each flow throughout
one another.

Abstractions - using a single class like "sidebar" to contain all your styling
for the sidebar is not thinking in abstractions. The sidebar may need specific
styling (say a different BG colour) but it also has a lot in common with other
parts of the page. For instance, it's nothing more than a grid column, so why
bundle all styles into one class instead of using the grid abstraction to
"decorate" the sidebar with this? This is equivalent to breaking a system into
reusable classes. See Nicole Sullivan's article on the Media Object [1] and
Harry Roberts on the open/closed principle in CSS [2]

Single-responsibility principle - Do one thing and do it well. A class should
have a single-responsibility so that it can be composed into larger "blocks"
of styling. A class that does everything is monolithic and difficult to work
with as soon as a design needs to change. Overly broad selectors in CSS can
also break the single responsibility principle - suddenly your styling is
relying on the coincidental placement of elements inside one another. Harry
Roberts cover this [3]

Loose-coupling: Can parts of your code base change without affecting others?
By @extending grid classes you're tightly coupling yourself to the
implementation details of the grid system. Now you can of course override
styles in your sidebar class, but overriding styles from previous classes is a
code smell. If you're "undoing" what another class has done, you've applied a
style too early. You suggest changing the CSS and leaving the HTML the same
when a change is required. I always prefer changing the HTML because it has a
far more limited scope for far reaching changes. If you change one segment of
HTML you know it's not going to affect other parts of the site beyond itself
(and possibly it's children), but if you change some tightly-coupled CSS its
effects could ripple throughout the whole site. The previously mentioned
article on the open/closed principle [2] touches on tight coupling in classes.

Favour composition over inheritance - In OO languages we've learnt that we
should favour composition of granular, single-purpose classes over deep
inheritance hierarchies. Why? Inheritance is a fundamental tenet of OO, just
as the cascade is in CSS, but we still frequently eschew it. The reason for
this is because we can compose infinitely more flexible pieces of
functionality from granular building blocks than we can from inheriting traits
from "super classes". And now that we're thinking in abstractions (as outlined
above) using the single-responsibility principle, we can put multiple classes
on an HTML element to compose them as you wish into large blocks. Harry
Roberts (CSS Wizardry) covers this nicely [4] and also when talking about grid
systems [5]

Self-documenting code - From the HTML I ideally want to know exactly where
each bit of style is coming from. With one monolithic class all I know is that
it's a sidebar, which doesn't really tell me much that I can't work out
visually. Multiple classes tell me exactly how it will behave at a glance.
This means your classes should be as descriptive as possible. Classes should
not describe the content of the markup they are applied to (sidebar is
definitely content-centric) but rather their intent. And small, abstract,
single-responsibility classes convey more information than a monolith can, and
they ease understanding of the system. Someone familiar with bootstrap could
quickly get to grips a site using the plain bootstrap classes, whereas
@extending all over the place necessitates digging into the CSS to gain an
understanding of the system. This is covered in great depth in the original
article I linked to.

Finally, you should never use as a JS hook a class whose purpose is visual
styling, then the whole mess you outlined is avoidable. Either use data-*
attributes (as most bootstrap widgets do) or a class which conveys intent and
a single responsibility e.g. "js-date-picker".

Now my incoherent ramblings are probably lacking in a number of points, I had
to leave out a lot so this didn't balloon even further (e.g. I didn't talk
about specificity or BEM methodology). I urge you to read all the articles
I've linked to, as hopefully you've already read the original one. You might
also want to read this article which kinda covers everything in one post:
[http://engineering.appfolio.com/2012/11/16/css-
architecture/](http://engineering.appfolio.com/2012/11/16/css-architecture/)
Most of the principles I've outlined here are actually used in bootstrap.

PS. if you want to continue the conversation, hit me up on twitter
(@WickyNilliams) or something, I always forget to check back on HN comments
for replies.

[1] [http://www.stubbornella.org/content/2010/06/25/the-media-
obj...](http://www.stubbornella.org/content/2010/06/25/the-media-object-saves-
hundreds-of-lines-of-code/) [2] [http://csswizardry.com/2012/06/the-open-
closed-principle-app...](http://csswizardry.com/2012/06/the-open-closed-
principle-applied-to-css/) [3] [http://csswizardry.com/2012/04/the-single-
responsibility-pri...](http://csswizardry.com/2012/04/the-single-
responsibility-principle-applied-to-css/) [4]
[http://csswizardry.com/2012/10/a-classless-class-on-using-
mo...](http://csswizardry.com/2012/10/a-classless-class-on-using-more-classes-
in-your-html/) [5] [http://csswizardry.com/2013/02/responsive-grid-systems-a-
sol...](http://csswizardry.com/2013/02/responsive-grid-systems-a-solution/)

------
weego
Meh, at some point they should start to realise that you can't change
everything every release and expect everyone to keep up. It feels like it's
becoming more of a chore than the real initial win it was able to deliver on
first release.

~~~
jvzr
You don't _need_ to stay up to date with this kind of frameworks. It isn't
like every update has security fixes.

The company I work for uses several versions of Bootstrap 2 and we have no
issue dealing with it. Newer projects will use BS3, but we don't need nor feel
the need to update every project.

~~~
steveklabnik
There is an image gallery plugin that I use that secretly downloads its own
latest version of bootstrap, which can conflict with the one you have loaded,
breaking everything :(

~~~
nahname
It must be a very good library to be chosen in spite of that behaviour.

~~~
steveklabnik
As you might tell by my :(, I wasn't aware that it did this until quite
recently. When it broke my site.

------
WickyNilliams
Is there actually a changelog somewhere or will that be written up with the
full official release? I can't see anything detailing what's changed

Also, it's a damn shame they're still using pixels for everything (from a
cursory glance). Fluid grids (i.e. %-based) and ems (for font-size and media
queries) are much better. They are infinitely more flexible and much more
easily adaptable to any layout.

~~~
pixelmonkey
The Bootstrap 3 pull request has a lot of details about what is changing:
[https://github.com/twbs/bootstrap/pull/6342](https://github.com/twbs/bootstrap/pull/6342)

~~~
WickyNilliams
Thanks, that's really comprehensive (perhaps too low-level for the end-
consumer to care about).

Reading through that PR it seems they are actually using percentage-based
grids now, but the grid containers are fixed width (and probably defined in
px). That's definitely better than completely fixed width grids, though I'd
much prefer having max-width on my containers instead of an absolute value,
and relative values used throughout

------
dave1010uk
This looks like the changelog:
[https://github.com/twbs/bootstrap/pull/6342](https://github.com/twbs/bootstrap/pull/6342)

------
nateweiss
While simple, I believe Panel and Listgroup are new components; nice to have
those nicely implemented and styled in the framework. Will be handy for me. In
many ways I think Bootstrap helps the most with the little things like this. I
am very appreciative of this terrific framework being made available for us to
use.

------
NanoWar
Why is everything _flat_ :-C

~~~
joeblau
I think it's flat because it's easier to add CSS and build up widgets as
opposed to having a stylized widget, then trying to override the CSS to re-
customize each widget. Foundation, the original front-end framework which
Bootstrap emulates, works the same way.

~~~
jaredmcateer
Foundation doesn't isn't completely flat though. Buttons, for example, hint at
being intractable by giving a tiny bit of depth using the line at the top of
the object.

------
chrisweekly
A big improvement: the media queries are ordered properly, mobile-first. Great
decision.

------
phpnode
It's interesting to see that the references to twitter are basically gone now,
presumably this means we'll see more things from `Bootstrap` in future,
perhaps a company since it already has a lot of mind-share.

------
LukeWalsh
The nav bar that automatically collapses for mobile is an excellent addition.
This is one of the main things lacking in quickly made prototypes.

~~~
nadaviv
This exists in Bootstrap 2 too:
[http://twitter.github.io/bootstrap/2.3.2/examples/fluid.html](http://twitter.github.io/bootstrap/2.3.2/examples/fluid.html)

------
jasonkester
Bug report:

    
    
      - open on iPad in landscape
      - navigate to a long doc page
      - scroll halfway down
      - rotate to portrait
    

Expected: content scaled to fit

Actual: content zooms way in, document scrolls several pages

    
    
      - rotate back to landscape
    

Expected: content returns to previous view

Actual: content zooms even further

~~~
frakkingcylons
It's probably best if you submit bugs to their issue tracker:
[https://github.com/twbs/bootstrap/issues](https://github.com/twbs/bootstrap/issues)

------
db-dzine
wtf is wrong with the button ... srsly.
[http://s14.directupload.net/images/130729/kassm787.png](http://s14.directupload.net/images/130729/kassm787.png)

~~~
adventured
I'm on Firefox 22, and the same thing happens here. Mouse over download
button, click it, download pop-up appears, click cancel on the download,
button disappears. It re-appears upon giving focus back to the page.

~~~
epmatsw
Still happens in FF 25 nightly as well.

------
jzone3
Personally, I think the "Download Bootstrap" button is too ambiguous. Why is
the default color the same as the background color, it is just confusing and
ugly

~~~
wilfra
I love that button, think it looks awesome.

------
hearty777
I'm assuming this was design by committee. The first versions of Bootstrap
seem a whole lot better visually.

------
greaterweb
It's really unfortunate to see all the haterade being spilled over the
comments. The efforts to take Bootstrap to version 3 were pretty significant,
at the minimum they deserve a pat on the back for that alone.

Here are some important concepts I think a good portion of people are missing.

 _Upgrading_ \- Don't upgrade for the sake of upgrading. If you have a fully
functional site right now which uses or extends a previous version of
Bootstrap your incentive to upgrade at this point is probably minimal.

At some point you had conceded that version X of Bootstrap was the right front
end framework for your project. If that has changed you need now concede you
have some work ahead of you.

Identify and evaluate the features introduced in Bootstrap 3 that are lacking
from your current project. Scope out the markup and stylesheet refactoring
required for any of the "must haves" and setup a schedule to integrate.
Realize that this doesn't necessarily mean you are bringing Bootstrap 3 into
your project, more so you may just be adapting your existing front end assets
to model Bootstrap 3 features/patterns.

This is really no different than an existing site that doesn't use Bootstrap
now wanting to bring the framework into their project. If you've identified
that you need Bootstrap 3 for your project, you would expect there is work to
be put in.

 _Usage_ \- I see a number of comments critiquing design and usability. Is
Bootstrap really intended to solve those problems for you?

In my opinion this is a framework intended to bootstrap your front end assets
and development efforts. It prescribes conventions for common component markup
and their respective selector naming conventions.

Think about that for a moment how valuable that is to your project (especially
those with a large number of contributing developers). How many projects
previous to one using Bootstrap did you have such well documented markup,
style and naming conventions?

Bootstrap standardizes and documents front end patterns for rapid adoption and
implementation into your project. That's pretty damn special. If what they
promote doesn't align with your needs or development practices, well, don't
use it.

 _Style_ \- Bootstrap wasn't designed for your site, your users or even to
keep up with the latest design trends. The styling, while in the view of many
is decent, seems to have been intentionally minimalistic and not overly
opinionated.

It provides basic structure and basic styling. It's your starting point. You
can get to your destination now a bit quicker without needing to reset their
style rules.

Having such minimalistic styles probably serves to be good motivation to get
creative. If you want custom and don't have the design ability to get there,
rest assured there will be a companion stylesheets to extend bootstrap coming
soon to at a market place near you.

 _Inspire_ \- If the Bootstrap shoe fits, wear it. If Foundation, Pure or any
other front end framework fits the need, use it.

To me the great benefit of all these popular frameworks is they bring to light
many well thought out development approaches to the front end. Not everyone
will agree with them. They aren't always bullet proof. Though at the end of
they day though they invoke developers to take a look at their individual
assets and recognize areas of improvement.

Find the framework or approach that best aligns with your needs and personal
preference and customize the hell out of it.

------
da_n
This is awesome work, well done to the Bootstrap team.

------
dangayle
Other than the grid, it looks like all the classes and markup are the same.

I wish the examples used more semantically meaningful html5 elements where
appropriate, but that's not too big of a deal.

~~~
mrgreenfur
I noticed last night that the forms have been cleaned up a bit and outfitted
with new class names

~~~
dangayle
Oh, I missed the forms. I haven't had much call to use them in my current
project, so I missed those.

------
hawleyal
The CSS/JS on the website is broken.

