WIP: Bootstrap 3 by mdo · Pull Request #6342 · twitter/bootstrap · GitHub

@WilliamStam Thanks for the feedback. Happy to hear it and it's why we've opened this pull request rather than doing everything in an isolated branch where changes are often more difficult to see.

Won't something like .clearfix_mixin work better? will allow for mixin growths in other fields as well like for instance .border_radius_mixin etc

Appending _mixin to a property isn't the most elegant approach, and one we'll likely strive to avoid. It isn't necessary given it's syntax. The clearfix mixin is a unique case, and the border-radius one is no longer needed. We'll work on improving this, but options are limited within Less at the moment.

bootstrap is used quite extensively with web applications with complicated layouts and pixel perfect fitting, not being able to use nested grids is a major drawback IMO.

I thought I was rather clear about this in the pull request description: nesting is still there and works just fine. It requires the fluid approach (meaning, six columns in six columns is half of the parent, not the full width.

I make use (successfully) of btn-info in my application. btn-primary for instance works great for submitting forms, but a button that opens up a modal with extra info needs a different button than those in forms. agree with inverse, but would be cool to just rename it instead of dropping it

I wrestle with -info for all of our components. I may bring it back, but I'm not too attached to it for buttons. And with .btn-inverse, I see no reason to bring it back or rename it. What semantic or meaningful name would make sense? Can't think of any myself honestly.

Input groups: surely you can diferentiate if its a span / div etc vs .btn? the markup change doesnt really make much sense to me. version 3.1 its going to have another markup change going back to .input-group-addon lol

Lolling doesn't help you make your point, and I encourage you to go ahead and do something better. All sarcasm aside, it's the best approach I can think of given the new display: table-cell method we're using. Definitely not satisfied with it, but it's better than the janky font-size and white-space bullshit I was doing before.

Dropped .form-search support. | why? every site / web app has search functionality. would of just recomended giving it another class .rounded to have the very rounded corners.

Of course damned near every site has search, but not all of them need to include more rounded corners than other inputs. If you want super rounded corners, add them. It's one property to change now and can be done whenever you need it with ease.

Adding .rounded is a bad idea because it furthers the idea that presentational classes (which we do use to an extent, but only with lacking a better nomenclature), and isn't really specific at all. How rounded? Super rounded? Perfectly rounded? Only kinda-sorted rounded if you look at it from one angle? For now, folks can add the one line of CSS to their specific form and get all the benefits the search form provided.

Dropped .label. | again why? wasnt badge always a thing like heres a number of unread emails you have type thing where as a label is inline text? surely it cant be THAT complicated to leave it in?

It's not about complication, it's about duplication for no clear benefit. The same component with 99% of the same styles is being recommended. I think keeping badge, or label, and introducing a new counter element would be more appropriate to help differentiate the two. In the latter case, I'd remove the options to color it and instead make it a simple element for placement within other components. Still undecided here.

Class changed from .hero-unit to .jumbotron | in the next version you guys will decide that it doesnt define what the class does as well and it will change... nice name for it tho.. just more like a nickname type thing

I'm really not torn here, and I don't think others will be either aside from having to make a change with no clear benefit. Sometimes getting the name right matters most. Given we used .jumbotron in the docs layouts and .hero-unit in the core, and no one outside marketing knows what the hell a "hero unit" is, the change I think is justifiable.

Removed submenu support. | by the looks of the comments here.. there are FAR more people using them than you thought.

A handful of people in a pull request isn't that many people. I completely understand that folks use them, and I myself use submenus on a daily basis—but only ever in navigating OS X. When's the last time you used a traditional submenu on your phone? It's just not as useful of a paradigm anymore.

overall it seems that bootstrap is about sticking with a version you started with - dont dare try upgrade. the devs seem hell bent on not making things updateable between versions. surely new version = fixing what is there, adding new things, fine tuning things, only removing things if they serve NO purpose and havent served any purpose at least 1 version back already. instead of just dropping stuff that the comunity have come to rely on / change stuff with by the looks of it, not a lot of thought / feedback on it?

It's a challenge to build things for large communities, when you have no control over final implementation, nor knowledge of the countless other individual pieces. No one forces folks to upgrade, and with the way development works on the web, we're happy to drop things for their newer, better, and stronger replacements. Not everything fits that bill sometimes, but we do our best.

3.0 still has a lot of work ahead of it, so stick around and see what comes out of it. I've updated the original description of the PR to better explain some things and give context to others. Will continue to do so as changes are made.