Bootstrap 3 preview | Hacker News Reader

Bootstrap 3 preview

rc.getbootstrap.com

306 pointswinkerVSbecks151 comments

The issue Bootstrap still has is that the parts that make use of JavaScript completely rely on JavaScript. If you're on a flakey data connection, for example, and JavaScript doesn't load parts of the page simply break.

The tab component is a good example of this - turn off JavaScript in your browser and you'll see that it still looks like tabs (thanks to CSS) but you just can't access anything part from the first tab.

Technically, this isn't a hard problem to solve. Have JavaScript add the HTML class that triggers the CSS rules to make the content look like tabs. If JavaScript fails, no part of the page ever gets hidden.

It would be great to see Bootstrap embrace progressive enhancement properly. With more devices of different capabilities accessing the web over networks of varying quality all the time, it becomes more important than ever to build robustly and not just for the best-case scenario.

I disagree. As a web designer/developer your job is to make sure your site looks proper. If someone chooses to disable javascript, they know that they are missing out. It's their personal choice to embrace an inferior web experience, and I don't think it's fair to have to compensate for them as well.

...except that JS can also fail due to network lag or simple programming errors (like a trailing JSON comma in IE). Ideally, sites should remain as functional as possible if JS or CSS fail to load. (Admittedly, a great many large websites fail this test.)

Requiring a refresh is not outlandish. If they failed to load the content due to network error, they will already be used to that kind of flaky connection and the refreshes it requires.

Specifically building your app to attempt to handle the "bad data connection" use case that users already are familiar with in the context of the internet seems like bad programming.

Why provide a usable but substandard experience when those users would get a superior experience after a simple refresh?

As for the "turned it off crowd": in terms of web apps, who cares? If you've disabled Javascript, you're not looking to use web apps -- period. Javascript is required to use web apps for anything other than fancy form posting...

Of course, every site's audience is different, and you should prioritize your development for your audience.

It's annoying when you're using a different device in a locked down environment to have to deal with pages braking because some JS (or other) won't load on whatever piece of junk browser or device I have to use. I had this issue a lot when traveling through Asia, I never realise how bad accessibility was until I had to use crap phones and dodgy computers to access airline websites.

For the love of god please provide a BASIC fall back!

Slightly adhomien edit, but I think you're ignorant and live in a bubble. Not everyone uses their computer, or has the same level of access, like you do.

What you call a bubble, I call my target audience. I don't mind that I accurately target my audience and prioritize my development towards them.

If information is what you care about and not design, style, or functionality, than my pages are perfectly readable on a screenreader. It will look and function like shit but the people who see it that way A) expect to or B) are not my target audience.

But you're right, it's a bubble. If my audience included people with poor data connections in Asia, then I would certainly approach the problem differently.

However, when it's just one guy making something, prioritization and cutting out the nonsense (like bad connections from Asia) are vital ;)

If any of your target audience may use your service from a less than desirable connection or device then you should try and make it as accessible as possible. Falling back to non fancy CSS and JS is vital.

It seems that a lot of services don't really understand their target audience, why would an airline or online travel insurance firm make JS mandatory?

>It seems that a lot of services don't really understand their target audience, why would an airline or online travel insurance firm make JS mandatory?

Because they wish to offer any form of rich experience that goes beyond form elements and form submission? Because they want date pickers, column sorting, marketing tracking, transition effects and a hundred other UX tweaks that are only possible through javascript?

Why should airline/online travel forgo modern user experiences? To satisfy a statistically negligible amount of their traffic that cannot see it?

At some point, horses aren't allowed on roads, and users need to buy a car.

They can still have all of that for most of their users. Users that can't use these newer features should be offered a simpler more basic experience. Just because it's a minority of users that want to access your medical claims portal from abroad (who'd have guessed that this would be a valid use case for someone who has bought world wide health cover?) this doesn't mean that you should lock them out.

You are very short sighted. I hope you end up in a position where you need minor surgery in Vietnam during your gap year and can't enter the claim in the insurance companies system because they insist that ALL user must be able to see their fancy drop down menus with rounded corners OR not being able to book an onward flight from Cambodia therefore being refused entry because you can't prove that you plan to leave in the next 3 weeks all because the internet kiosk you're using is blocking the CDN that pushes some crap JS that adds nothing other than eye candy.

What's wrong with creating an alternate UX without all the overhead?

I hope you suffer the consequences of your own short shortsightedness.

Also, FYI, horses are still allowed on roads.

EDIT (can't reply) I think you'll find that medical insurance sites and travelling / booking sites are very similar and attract a very similar userbase. People book flights ticket and medical insurance, people fly then use the medical insurance when they have too. You seriously do live in a bubble, i have a feeling you are an American who isn't very well traveled outside of his own country and only uses medical sites in the context of your non state health insurance. You probably aren't the kind of person that would use any of the services I care about.

SECOND EDIT.. I spoke about my two target services from the offset and did not switch context. Do you not realise how these two sites / services go hand in hand?

I just got back from skiing. I used an airline site and medical insurance site for the same trip.

>You are very short-sighted

Haha. We went from talking about my 1-man development website, to travel sites, to medical sites.

All because each example is a better fit for your argument. You don't warn me when you change the context of our conversation, you just do it and then insult me afterwards for not meeting your newer demands.

Medical =/= travel =/= my site.

Each are fundamentally different industries with dramatically different requirements. Obviously you have to meet the requirements of your industry and your users. I have CONSTANTLY SAID that you must prioritize your users. Medical users ARE NOT travel users ARE NOT blog users.

You're also failing to take into account a team versus one man. One man or small teams trying to launch have to prioritize their MVP and their main audience. Massive operations with dozens of developers SHOULD meet everyone demands, because they have the time and talent to do so.

When you're capable of not context-shifting a conversation to continually cast your argument as superior, I think this chat can continue.

Otherwise, you're just shifting and insulting me for your own jollies, and you'll excuse me for not going along with it.

Good day!

EDIT to your EDIT:

I currently work in healthcare IT after transitioning from a major travel IT company. The requirements are NOTHING alike, really nothing alike at all. The types of users and the requirements placed on the organizations by regulators are dramatically different. Medical is a WHOLE different ball game with tons of people to answer to.

Also, people can be expected to not book a plane flight with a bad connection on an old phone. "Wait until a better connection" is the standard response that has worked thus far (or call your secretary/company to handle it).

When it comes to medical data, waiting is less of an option and getting a good UX is less of a requirement.

Are you kidding me? Both sites have users that need to access various portals from foreign countries. That's the basic similarity between the two sites.

Wait for a better connection... oh yeah sure, I'll just go look for another internet cafe in the middle of nowhere on my travels.... Seriously, you're an idiot.

So many companies get this right. A few don't. I serioulsy hope you suffer

EDIT: I'm specifically referring to people that travel here. As you live in a bubble, I doubt this applies to you or the sort of work you do.

>Are you kidding me? Both sites have users that need to access various portals from foreign countries. That's the basic similarity between the two sites.

That is the most superficial comparison between two disparate industries that I've seen in some time.

Yes, both are websites that you access.

By this context: I visit mobile gaming websites from foreign countries. According to your analysis, mobile gaming == travel industry == healthcare.

You do, of course, realize that the regulation requirements behind the systems that deliver those websites are dramatically different?

Between HIPAA, ARRA, a bevy of other national regulations and 50 separate state implementations of Medicare/aid with additional privacy and other regulations on the state level, I hope you can appreciate that medical software requirements are fundamentally different.

Implementing a medical portal is an order of magnitude more difficult than a travel portal from the regulation and control side alone.

Put it this way: if you leak user data on a travel site, all you might have to do is write mea culpa and force a password change.

If you leak user data on a medical site: the fucking hammer comes down, public disclosure is mandated and _heavy fines will follow_.

These kind of systemic differences absolutely affect the end user UX and the kinds of priorities that developers have going into it.

Making sure spotty data connections work is less of a priority than making sure a secure connection is present when dealing with HIPAA protected data.

All I'm saying is... websites and portals that are accessed from devices and connections, in emergency-ish situations, should really have fallback modes so they work when I'm stuck in immigration in a third world country (or hospital).

long haul airline sites and medical insurance sites fall under this category. I'm not talking about this from any other perspective than accessibility under less than desirable conditions.

I don't really see how this has anything to do with American state laws. Accessing a portal that tells an insurance company that I need treatment abroad is a simple. Can you please burst your god damn bubble. We're talking about JS and CSS fallback not the united states of americas various laws in regards to medical records.

Have you ever left the US?

Yes, sites whose main audience may view it from those limited connections should devote resources to ensuring that they can access it from limited connections.

I clearly stated exactly that in my first original post in this thread. I said, always know your audience and prioritize your development for your audience. I don't know why you've missed me saying that 4+ times at this point. I guess it's because you want to "win" a debate, even though I made your point before you even read my original post.

>I don't really see how this has anything to do with American state laws.

Because accessing data requires you follow the laws governing that data regardless of where the request comes from.

>Have you ever left the US?

Have you ever programmed before? Do you know what software requirements are, or legal requirements, or any of it?

Honestly, you sound like a layman. 100% end user with zero experience in building a portal or medical software or anything else. "Who cares about laws, I'm talking about css fallback". Well, the people who pass and enforce those laws care, even if you don't. And they will make sure you care sooner or later, if you plan on staying in business.

That's the point. You have to care about laws because they're fucking laws! You don't get to just distribute protected medical data over insecure connections because it's convenient for end users! That's illegal.

And protected medical data IS DIFFERENT from non-protected personal travel data!

I know that understanding that difference is difficult for an end-user, but please respect that the concepts are completely different and pretending that "it's the same" only hurts your ability to understand the additional complexity that security laws like HIPAA introduce.

Please do not talk to me any more. I have no interest in replies and have provided this one because you keep stalking me in other posts, so I wish to provide closure.

If you want the last word, please take it here and no where else.

Please stop following me and posting on unrelated threads, it's extremely immature.

You're an idiot, I'm talking about the accessibility of a data entry portal. There's no reason to not make it work in sub optimal conditions if ANY (not just your main) of your user base are likely to be in those conditions.

This has very little to do with data protection laws. I'm not talking about making your data secure, using ssl, redundancy in your database etc. These are all requirements but this is not what I'm talking about.

Simple accessibility in sub-optimal conditions. Stop trying make your small minded opinions the focus of this. Do you even own a passport?

haha, criley won already

wtf?

I'm right, he's clearly a try hard with no idea what he's talking about.

If a load fails due to network issues, the user won't always appreciate that the fault was down to networking. The site might just look broken.

If the failure wasn't related to a network issue (either bad data, or perhaps a buggy JS interpreter on their device) then refreshing won't help. The site will still be broken.

My point is that we can plan and build in such a way that JavaScript failures don't break the page. It's a little bit more work (doing things well usually is) but a reusable component library is absolutely the right place to focus that effort. Everyone then gets the benefit with no more work required.

I agree that the NoScript folks can be ignored for apps. However, for web sites which consist primarily of rich documents, it's polite to at least try to convey the same information.

> Specifically building your app to attempt to handle the "bad data connection" use case that users already are familiar with in the context of the internet seems like bad programming.

Au contraire: It's the height of good programming to attempt to predict and handle as many real-world errors as humanly possible. If I'm writing a USB device driver, you'd best believe I should try to do something sane if the cable comes unplugged, rather than just saying "don't do that".

Also, not all users will understand that components didn't load (many users still don't even know what a browser is!). And if the failed load is due to a proxy/firewall/DNS problem, or just a straight-up bug, a reload may not solve it anyway.

In any case, you're spot on about prioritizing development to the audience. Guidelines can be a good start, but there's no "one size fits all" for the web.

>Au contraire: It's the height of good programming to attempt to predict and handle as many real-world errors as humanly possible. If I'm writing a USB device driver, you'd best believe I should try to do something sane if the cable comes unplugged, rather than just saying "don't do that".

Should you devote a lot of your limited programming time to catching an exception that users naturally experience during USB operation and can be corrected by a simple "unplug and replug?"

I argue that you shouldn't devote undue attention to something that users naturally already handle.

But if your project is healthy and features are rolling out and you have the time and talent to waste on edge cases like this, then why not!

It is totally fair unless you're creating a web application but my idea is that the first priority of a content-heavy web site should be to make its content as accessible as possible. Also, inferior experience should not mean they miss more than half the content.

If anyone is looking for a basic summary of "What's new", the best I found was their blog post about plans for v3:

http://blog.getbootstrap.com/2012/12/10/bootstrap-3-plans/

That lists almost all organizational changes, with fairly few benefits to the users (though quite a few to the organization, which it helpful for it’s continued existence). However reading the comments here it does seem like there are some nice upgrades for the users as well.

Here's the most comprehensive list of changes I've found. The pull request for Bootstrap 3 on github:

https://github.com/twitter/bootstrap/pull/6342

That's a much more informative list, thanks!

Thanks man. Great straightforward list.

For everyone complaining about the flatness, it looks like it's only temporary.

https://github.com/twitter/bootstrap/pull/6342#issuecomment-...

Happy to see even though the removal temporary, they are looking into a way to easily remove styles for those who enjoy the flatness.

This goes even further than the flat/gradients debate and will also be useful for people who'd like to deeply customize bootstrap.

Customizing Bootstrap has always been a pain (and I'm not the only one to think this, in the words of @mdo : those who want to use Bootstrap as a bootstrap kind of get the short end of the stick), I'm very happy to see that they're looking to make this easier.

Would be cool if the gradients and 'shiny' stuff was in a separate file so it could easily be removed for those who want a flatter look. In 2 it's scattered around the codebase.

So glad I saw this. Thanks for posting that. I would have been very sad if they went flat.

This was the first time I've seen 3.0 and I really love the flat clean look. I skimmed through the linked page but couldn't find a specific statement about what they're going to be doing with this.

The thing I like about the flatness is it's even more clear that Bootstrap is a framework for you to build your own sites faster, and it's up to you to really customize it for your brand.

It's interesting that so many of the comments here (and often, those made about Bootstrap in general) focus on the aesthetic of a few form elements and not the utilities that come with the framework. Understandable, I guess, as they're the most obvious when you load up the page!

I've been playing with the 3.0.0-wip branch for a little while, and I think that there are a couple of really cool features that should be noted above the cosmetic - the single, fluid grid; font icons by default; and a mobile-first design.

Well there is no Scaffolding section so it's hard to know what changed beside the aesthetic.

This is the new scaffolding section: http://rc.getbootstrap.com/css/#grid-system

I've only been using bootstrap for a week, but I instantly noticed that the grid elements were separated not with a left margin, but with both left and right padding. This is going to be fantastic, and shows their responsive first thinking.

Weird that the Grid section is buried in the CSS section where it's the most important. See, I like that Foundation starts by explaining directly how the grid system works. That columns need to be in rows, etc... Overall Bootstrap's documentation is better, but it lacks this Grid System first approach.

Still no border-sizing:border-box. Which makes me still root for Foundation.

Buuut, there is now a better nesting (Foundation-like) where there is no need to write row-fluid. Which is good.

I believe Bootstrap 3 does in fact use border-box - hence the padded grids and a major driver behind the drop in support for IE7.

No signs of border-box in the code.

https://github.com/twitter/bootstrap/blob/3.0.0-wip/less/gri...

You might be looking at the 2.3.1 (master) branch, which didn't use border-box :).

Why does padding make it more responsive than using margins? I've considered using padded grids as well, but was discouraged because it would lead to more markup if you don't want background images/color to bleed into your gutters.

Just realized one big advantage padded grid is to be able to use the grid classes on table-cell elements.

Not sure if I like this at all. I think they need to call it

Bootstrap 3: flat and fat!

It just seems like a huge step back to me. It's not even an elegant "flat" design; it's like they scrapped everything and decided to make all classes (even buttons for God's sake) DIVs of different colors. The new navbar, for example, is literally a gray DIV with rounded edges. I use Bootstrap on my web app because I care about design, but I don't care so much about learning fancy CSS; Bootstrap takes care of making things look subtly 3D, shaded, animated, etc., and that's what I'm looking for. I can make flat DIVs myself, thank you very much.

The more people stop using Bootstrap as a complete design the happier I will be.

What would you suggest they use? Why does your happiness depend on this?

Use bootstrap, but customize the design to fit your brand. Bootstrap is a framework for building your own CSS on top of. The less opinionated it becomes, the better, since it'll make it easier to adapt the framework for your design.

This is the key to Bootstrap (or similar css frameworks). It's not intended to be a theme. If you want to just have the css/html ready for you to do some documentation or a project that has no need for any visual differentiation, then go ahead and use vanilla.

When used to build something that should be visibly unique, the visual design and appeal is something that should be created aside from bootstrap, maybe with the grid in mind, and delivered as mockups or pattern guides.

Come on yes it is (was) intended to be a theme , that's why it is so successfull. Grid frameworks existed well before bootstrap , and most developers did not use them.

Grid frameworks like 960gs never became as popular as Bootstrap because Boostrap is as much about formatting content (including forms and UI elements) as it is about the responsive grid layout.

I suppose you could say it comes with a theme, but anyone who cares enough to complain about the theme should also be motivated enough to customize it.

Not everyone is a HTML/CSS hacker. It's a really valuable front-end framework. My app wouldn't look nearly as professional without it.

It's OK for the first iterations, but if you really care about your product, you should hire a HTML/CSS hacker.

Yeah, but I'm a broke high school senior (1-man team), so I'm sort of forced to take advantage of free stuff like Bootstrap and the free year of Amazon EC2.

Bootstrap is definitely useful if you're just tinkering - it makes a minimum viable product look sort of legit ;)

But I would certainly invest in specialized developers to make a lighter-weight, in-house UI if I were really serious about a website.

If you really care about your customers instead of your product, and they are more than happy with the "professional" Bootstrap UI, you have no reason to mess with it.

What is always good to have is a designer or at least a developer with an eye for aesthetics, to use the Bootstrap elements in an elegant way. Otherwise, what would you "hack" about HTML/CSS? Either reimplementing Bootstrap, or playing with the latest and greatest that won't work in anything else but the latest Chrome (see the IE6/7 discussion).

Would you rather see something that looks like these? Because this is what you would get instead: http://www.gnu.org/ http://gcc.gnu.org/ http://clang.llvm.org/

There is something I keep pointing out when inevitably the conversation turns this way: Bootstrap (and Foundation) are UI widget libraries, not just prototyping helpers. They are the missing rich widget set that browsers should provide by default if they were proper application runtimes and not the patched together mess they have grown into. A good comparison would be Sencha ExtJS, but for markup instead of full JavaScript: you have layout elements (the grid), a set of reusable controls, and some helpers (typography, etc).

A lot of web applications -- line-of-business but also consumer-oriented -- should NOT be visibly unique, and styling your own buttons not only is a big waste of time, but also reduces usability. Look at the WinForms/Cocoa/GTK environments to see the value of a single visual language in action (including their respective UI guides that help with a consistent experience). The popularity of Bootstrap tells you the need is still there -- for both the millions of developers who need to get the job done without reinventing too many wheels on top of broken hypertext, and for the users who appreciate not having to figure out a UI for the millionth time (just ask your boss/customer what they think of your boring Bootstrap app, they probably love it).

>I can make flat DIVs myself, thank you very much.

What about the scaffolding, the grid system and sane typographic rhythm? What about the glyphicons and out of the box mobile awesomeness?

Bootstrap is more than 3D buttons and box shadows, perhaps they are moving away from that to focus on the utilities that make the framework great, and not for the shiny buttons.

You're right, but I never use the grid stuff anyway; I only want to invest time in learning about something if it's not framework/vendor-locked, so to speak, so I'd rather just use the elements and do the scaffolding myself.

Glyphicons are probably my favorite part, though.

If you literally only want the buttons, then you should use something like this: http://blog.koalite.com/bbg/ to create the css for your buttons and avoid a whole lot of overhead including the entire framework's css just to get the buttons.

Good to know. I'm seriously considering some ways to cut down on the overhead, so this is great.

That's what bootstrap themes are for, if you are not good in CSS yourself, you can easily install a custom theme on top of it.

>I care about design, but I don't care so much about learning fancy CSS

might just be me, but I don't think you care too much about design if you rely on standard bootstrap for style. Not that I don't understand the appeal of having something that looks good out of the box.

Well, I suppose I'm a lazy aesthete.

According to http://news.ycombinator.com/item?id=5351887, the flatness is temporary.

> I use Bootstrap on my web app because I care about design, but I don't care so much about learning fancy CSS

A paradox.

> The new navbar, for example, is literally a gray DIV with rounded edges

Maybe the motivation behind this change is to make the navbar look a bit less twitter-y out of the box?

For comparison, also check Foundation 4.0, launched about 10 days ago. Foundation seems to be slightly ahead (as in, already launched) in moving to newer technologies (mobile-first, border-sizing:border-box, ..etc).

http://www.zurb.com/article/1173/foundation-4-is-here-the-sm...

>Foundation seems to be slightly ahead in moving to newer technologies (mobile-first, border-sizing:border-box, ..etc).

Check out "Layout and grid system" section here: https://github.com/twitter/bootstrap/pull/6342, it specifically mentions border-sizing: border-box is being used and in the top in bold it says "Bootstrap 3 will be mobile-first"

Bootstrap 3 is not launched yet and Foundation 4 is. That's what I meant by "slightly ahead".

A big heads up for anyone thinking of switching. Bootstrap 3 "Drops IE7/FF3x support entirely."

ref: http://blog.getbootstrap.com/2012/12/10/bootstrap-3-plans/

A big heads up to those people who still support ie7, that is. Google and Facebook dropped support a while ago, and ie7's usage share is around 0.6-2.0% globally.

http://clicky.com/marketshare/global/web-browsers/versions/

http://gs.statcounter.com/#browser_version_partially_combine...

IE7 doesn't cause nearly the same scale of problems that IE6 did; I don't think 1% is small enough to justify ignoring it entirely. (I suppose it depends on whether it degrades gracefully or becomes unusable.)

Indeed, I'm starting a responsive site design project that will have a large target audience in China... where some 20% of users are still on IE6. Looks like I'll be testing both Bootstrap and Foundation.

Heh, good luck doing responsive on IE6 without going crazy!

I hope you understand that global usage is totally irrelevant, when as a web developer you need to target a specific audience.

If your audience is public businesses ie7 shares whill not be just 1% of your target.

If you care only about people using browsers at home,then you are not doing your job.

I hope you understand that global usage is totally relevant, when as a web developer you don't have a specific audience to target.

Can you elaborate on usage stats of "public businesses" and where you got those from?

If you have usage stats on your audience, then use them. Otherwise, go with the global usage, or at least your country/continent.

Are you saying web developers aren't developing to a specific target audience? Or do you mean that if you don't have metrics yet then you might as well use someone's global numbers?

The latter.

with some sass knowledge you are better of starting off with a couple of mixins and building from bottom up as compared to loading a fat css file you probably won't use 80pc of its rules.

Normalize css[1] Bourbon[2] for utilities Neat[3] for the grid, Typeplate[4] for a nice type base.

If you still need bootstrap style elements, you can get individual mixins and styles from one the bootstrap-sass projects[5]

[1] https://github.com/necolas/normalize.css/

[2] http://bourbon.io

[3] http://neat.bourbon.io

[4] http://typeplate.com

[5] https://github.com/thomas-mcdonald/bootstrap-sass

edit: typo

Is it just me or do the new buttons not really fit with everything else. They look very flat. But most other components have shadows and still look like old bootstrap

Yea the new buttons just don't feel right. In the case of checkbox (button toolbar style) it is quite hard to tell which one is selected. Maybe they should aim for a more Rdio/Dropbox style solution. Mostly flat except for buttons and input elements.

They actually don't look like buttons at all, which defeat the purpose of a button.

Yeah the old buttons looked like buttons, it was obvious they could be clicked. These ones look more like an outlined header or something. The disabled ones don't really look disabled if they are not next to a non disabled button either. Aesthetically I think the current version is much better. Personally not a huge fan of everything going to this 'flat' / metro look but it seems to have really caught on.

The "Download Bootstrap Source" button in grey looks disabled.

I don't get why they went full flat. It was way more attractive before.

How is the touch support now? I was trying to use bootstrap "radio buttons" the other day, flailed about for several hours (touchend handlers worked for regular buttons, but not the radio buttons), and they still aren't working on an iPad.

The buttons look like they are disabled.

More than that, they have a really strange linear gradient on Firefox for Android. My flight is about to take off, so I can't check on desktop Firefox or submit a bug report right now. :(

Hey everybody, callahad is on a plane!

why don't they just incorporate font awesome?

They're using Glyphicons which also has a font

Segmented dropdown groups are broken for me in chrome. The drop down is floating underneath the button.

Something that always bothered me about Bootstrap is that the examples don't make full use of HTML5, although…

    Bootstrap makes use of certain HTML elements and CSS
    properties that require the use of the HTML5 doctype. 
    Include it at the beginning of all your projects.

The two examples that immediately come to mind are NAVs[1] and progress bars[2]; HTML5 already defines these elements. Why reinvent the wheel?

[1]: http://rc.getbootstrap.com/components/#navs [2]: http://rc.getbootstrap.com/components/#progress

When I evaluated the use of HTML5 section elements last year, including the nav element, screen readers didn't support them.[1] Also, there wasn't any benefit to using HTML5 section elements.

A book named The Truth About HTML5[2] provides additional reasons not to use HTML section elements.

I've yet to read about any benefits to using HTML5 section elements.

[1] http://www.accessibleculture.org/articles/2011/10/jaws-ie-an...

[2] http://www.truthabouthtml5.com/

Is it meant to be default to full on flat-ui? First impression is that the buttons are now less apparent interface items and it'll take more careful layout planning to make a quick bootstrap effective. Thoughts?

The Responsive Utilities section is interesting with new classes such as .visible-phone and .hidden-phone (also tablet and desktop) but I find in my app that my customers want to see all of the columns even if it means a little bit of scrolling.

Zurb takes an interesting approach with their responsive tables (http://www.zurb.com/playground/responsive-tables).

bootstrap 2 (and 1 IIRC) have .visible-/.hidden- classes already - is there something new?

yeah those classes are not new.

You are right... my mistake. I was looking on a different page of the old bootstrap site.

Those new badges are a real nice addition

http://rc.getbootstrap.com/components/#badges

Are you referring to the addition of active nav states? The rest has been around for a while: http://twitter.github.com/bootstrap/components.html#labels-b...

I actually like the changes. Now everyone will have to do a bit of style editing before using this. So we won't see so many identical sites.

The description at the start of the pull request for this work-in-progress branch is worth a read for understanding the motivations behind most of the changes.

https://github.com/twitter/bootstrap/pull/6342

It may also help to keep in mind that this is a preview. Bootstrap 3 isn't done yet.

Looking at the grid i noticed the 1-column divs change size. e.g. 41px - 42px - 41px - 42px - etc. When resizing in smaller displays it behaves different: 25 - 25 - 24 - 25 - 25 - 25- 24 - etc. Was this always the case in bootstrap? I don't really understand the reason for this. It seems odd.

I suspect that will be because the primary grid is now based on percentage values rather than fixed pixel values. When you're splitting a grid into columns using percentage widths, often the browser has to make a choice between rounding up or down to the closest pixel value for display.

The fluid grid has long been a part of Bootstrap, but until now has generally been secondary to the fixed 12-column grid, which used strict pixel values.

Mobile first? There are a ton of broken examples on my iPhone (grids, inline elements, etc.).

That's why it is in preview and not released?

I'm previewing my new flying car. It doesn't fly yet but it drives great on the road.

Except instead of making a "flying first" car from scratch you start with your existing car as a prototype to build your first "flying first" car that you plan to give away for free and open source it.

Then all the of flying community come out of the woodwork to cry bloody murder it isn't flying yet when you just strapped on some wings and aren't finished. Then you start to wonder if it's worth sharing both the process and the product in the first place when you have to deal with all the kids out there who cry as if their lollipop was stolen.

I like the way tables are handled, it looks so easy now. However, there are still bugs. Screenshots here:

http://www.backwardcompatible.net/164-twitter-bootstrap-3-bu...

Can we make the flat UI optional?

https://github.com/twitter/bootstrap/pull/6342#issuecomment-... 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.

Also, considering the nature of Bootstrap, the UI design is always optional.

Endless props, thanks, and respect to the Bootstrap team. They do an amazing job, sometimes with less-than-amazing levels of gratitude in return.

i really wish they wouldn't lock form into being horizontal or inline by putting a class on the form tag itself, but rather by using the fieldset tag. The whole reason is because sometime when you are doing a large form, some sections just flow better as an inline rather then a horizontal and vica-versa. I submitted a ticket about this a while back, but it must have been overruled.

One thing I liked most is 'Responsive utilities', no device specific coding. If you want show sidebar on desktop, drop .visible-desktop.

You can use that now in 2.x: http://twitter.github.com/bootstrap/scaffolding.html#respons...

Fyi, top nav menu doesn't work on nexus 7

Don't support Nexus4 either...

It works on my LG Nexus 4.

If this is the issue I think it is ( https://github.com/twitter/bootstrap/issues/4550 ), it is unfortunately not only for this beta v3, it is a big problem with the current version of Bootstrap as well.

I would consider it quite crucial. When using Bootstraps responsive features, (which are clearly a selling point) you'd expect something as trivial as a popup-menu to actually work on other than desktop devices.

I like the addition of the .btn-block class -- I'll definitely be using that for mobile optimization!

is the table of contents ordering out of whack for everyone? when I scroll down the page, the right hand table of contents jumps typography->grid system->code->tables, even though the menu is laid out as typography->code->grid system->tables...

I still fail to understand this. What's its purpose? To make all web pages look the same?

Much in the same way Ruby on Rails made every site work exactly the same. It's a framework to provide a foundational starting point that is already consistent rather than trying to build a consistent style guide and toolset from scratch every time.

One purpose is to allow less design inclined developers to rapidly produce a decent looking prototype that people can play around with.

Bootstrap is nothing but a foundation, and while many sites simply take one of the examples and run with it -- which is a perfectly fine approach if you simply want to put some information out there in an accessible format -- many others use it simply as a structural foundation. I've worked with CSS for years and am quite honestly tired of the BS (primarily the hilarious endless recreation of the layout of the archaic table element -- somehow it became verboten and we've been trying to re-make it with CSS for years) and simply starting with the grid layout of bootstrap is a great start.

I don't get this flat look, it reminds me of Windows 8. Is it a new trand in web design?

I see some of bootsnipp's ready made recipes are added in this version.

Modal is still a disaster.

Why?

Will be nice to have a "border-less" class for tables...

What's with the whitish glow on button text?

It's a dropshadow on the text which makes the button text look embossed when there is a gradient on the buttons.

There will be gradients on the buttons.

https://github.com/twitter/bootstrap/pull/6342#issuecomment-...

This is down to poor typographic styling. It can be removed with two lines of CSS:

-webkit-font-smoothing: antialiased; font-weight: bold;

Meh. too flat

> Seriously, fuck off with the flat UI already! I can't express it in any more politely
Apparently you can.
Regardless: ull/6342#issuecomment-12332378 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.

For god's sake, just learn some CSS already.

the download link is broken

Mobile first - Yeah! Can anyone compare/constrast the mobilefirst-ness of Bootstrap3 and Zurb4 ?? Why would I use one vs the other??

That's a good question that I'd like to see answered. It seems to me that mobile-first is used as a buzzword here. Unless they are literally inventing features for the mobile layout and then finding a way to make them work on desktop -- for example if the navigation bar accordion thing was there before the full desktop navigation bar.

Not sure what you mean by this. Mobile first just means everything is designed starting from a mobile view. It's not a "feature" like some sort UI item, it's a style of design thinking with the goal of ensuring the mobile context is absolutely as simple as it can be. It's not a buzzword since this is how they approached this version.

So what specifically was designed with a mobile view first in Bootstrap 3? I'm not being argumentative, I just want to know.

Just check out the css, everything starts with the 480 media query and builds on top of that. CSS is added to the base mobile CSS (which is incredibly simple) to work as the width goes up. Check v2, it's (almost) completely the other way around. Again, it's not a specific thing, it's everything.

I don't really like the new buttons. Other than that good job.

Is it me or do they use greyish text on white background that makes the whole thing hard to read ? i'd like to understand , what the hell is that low contrast trend and how does it make the text more readable ? Designer should quit it. Are they stupid or what ? Also this flat trend make the design very poor , but maybe that's the intended effect.

I think you need to relax. If the design is so poor then customize it. Or even better, submit a pull request that includes your own brilliant design skills.

>Also this flat trend make the design very poor.
Bootstrap is not just a UI framework.

So Bootstrap uses proprietary HTML elements, like Angular?
I like both frameworks but is this a trend we should worry about?

I didn't see any proprietary elements, which ones do you mean?

Which elements would those be? I can see custom attributes for the javascript plugins and in that context it's completely fine.

What's the problem with Angular's choice?
Proprietary elements in Angular are called directives. You define them and choose how to render them, what data to pass to them and linked functions to call after rendering. Everything is taken care of, it's not like the browser is going to freakout and not know what to do.

Reply on news.ycombinator.com