I wish they weren't dropping IE7 support. You can make fun of "who uses that!" all you want, but we build a site that is used by government people who can't control their own computers, and our current demographics are 50% IE7! Nothing to be done, we just can't upgrade to Bootstrap 3.0. So -- if you MUST do this, at least leave the website docs up for Bootstrap 2, cause we're not going anywhere...

At some point people need to be pushed off. That's all there is to it. A lot of wasted developer time goes into supporting old browsers. Probably a lot more time than it would take to upgrade the browsers in the first place. If a large portion of the Internet stops working because a company/govt is using IE7, Firefox 3.6, etc, maybe they'll come to the conclusion that it's worth looking at different options.

While it's tempting to use the threat of obsolescence to force governments and enterprises to adopt newer software, these groups are traditionally the most resistant to such efforts. This is due not in significantly to the bastions of old tech living in iso, where all they have to talk to is the custom-built application.

Also, the promise that the forced obsolescence will eventually work out better for the world is cold comfort when it's you who must choose between legacy tech and sacrificing a large portion of your revenue.

Bootstrap 2.2.2 is going to be the last 2.x release and it's fairly polished to begin with.

There's nothing wrong with intentionally staying behind -- Bootstrap 3.x features will more than likely lean a lot more heavily on CSS3/HTML5.

There is however the problem that historically they have not keep a copy of the old docs online. So if you stick to 2.2.2 your probably going to be SOL when it comes to reference info.

Sure there is an archive somewhere of the old docs but that is a long way from ideal.

Aren't the docs part of the repo?

Yes they are. Get them here: https://github.com/twitter/bootstrap/tree/master/docs

I agree, our Enterprise app still has a lot of IE7 visits.

Roughly 10% IE7, 30% IE8, 25% IE9, 17% Chrome, 12% Firefox, 6% Safari. No IE10 yet, not even one.

Same stats roughly, 9.5% IE7. Client's are asking for IE7 support as base level (they normally don't ask for IE6 when I say +50% cost). I suspect next year will start the "death to IE7" campaign. Hopefully.

We also have 1.67% IE6 users who haven't take the hint, my banner and the fact it's totally broken doesn't deter them.

This is a public facing website, although we did investigate the IE7 users and found alot come from public/government networks. They strangely browse the site at work then buy at home (IE8+/Firefox/Chrome) which is frustrating as they won't buy if the site doesn't work in IE7...

I've found this site to be very helpful: http://bootstrapdocs.com/

That's certainly nicer than the one I threw together (and never found time to update manually) at http://bootstrap-docs.org. I'd probably consider pointing the domain at one that was maintained properly :)

As someone with something like four applications on different Bootstrap versions, THANK YOU (and to the creator of this site as well).

ps: yes I know you can just use the docs from the archives.

Maybe you should be looking into a more custom solution instead of using Bootstrap if you have to support IE7.

It's not like bootstrap adds 1000 features that can be created manually.

Why would that be better than sticking with Bootstrap 2? Bootstrap has been a huge boon for us -- provides a cross browser, consistent, and well documented layout framework that has brought valuable organization and unification to our previously hodgepodge and inexpert usage of CSS. It's a fabulous tool, much better than any custom solution we would gin up with the limited time allotted for that sort of thing.

> Administrators have no excuses anymore.

Yes they do. They have procedures and are paid to act according to them. You are clearly unaware how the public sector works, or how expensive are upgrades in such scale. Upgrading software for the whole administration sector of a big country means upgrading a few hundreds/thousands computers per city (depending on the population), do the math; and only if the upgrade is even possible (breaking dependencies of software ordered 10 years ago).

Yeah, 'the system is broken', blah blah, it is what it is.

BTW Polish parliament (420 people) members were given iPads 'to save on paper'. Aside from the fact they watch porn at work, the yearly cost of maintanance and upgrades is at $150k. Yep.

You probably want your govt to spend money on better things than upgrading browsers.

> Removed all color variables (e.g., @blue, @orange, etc). New, more meaningful variables are on their way (such as @state-warning-text).

Hooray! Should make customization that much easier.

I'm sorry, I don't know what @state-warning-text is, googling it only seems to point to this article, could somebody explain please? thanks!

The problem is that a variable name like "orange" is a very bad variable name in case your design wants warnings to be in, say purple for whatever reason.

If the LESS variable is called "state-warning-text", you can define that to be purple without the bad aftertaste of having to use "orange" when you mean purple.

Thanks!

It was just an example, but what this means is that they are switching to semantic naming, rather than style naming.

I don't mind haveing color variables. When I need a new red, I define @projectRed or @redAlt. It is so much easier to remember red than some dangerColor.

Why will they choose hyphenated variables instead of camelCase?

>Why will they choose hyphenated variables instead of camelCase?

Presumably because hyphentation is the standard in CSS.

But, variables are not standard in CSS. I always perceived less variables as JavaScript variables.

Now, I need to figure out a way to make Vim treat hyphenated words as words for filetype=less.

You can either use the 'W' movement (instead of 'w') or use the 'iskeyword' option to change what is considered a word character. Word movement: http://vimdoc.sourceforge.net/htmldoc/usr_03.html#03.1

I enjoy having colour variables at the top that are project specific blues or oranges which can then be set as the values of other variables such as @state-warning-text.

> All variables now use dashes instead of camelCase. For example, it's now @body-background instead of @bodyBackground.

Not sure how I feel about this. On one hand that's a pretty large sweeping change that is going to break all my customizations.

On the other, dashes look much better in css and I prefer them for class names and so on. Not even sure why, is this some sort of community standard I picked up somewhere along the way?

Maybe they aren't using the property of the dash character just yet, but it is special in CSS: http://stackoverflow.com/a/5598250

They don't use that selector as far as I know, because it's very brittle. Something like [class|='span'] would only match classes starting with 'span-' if they are the first class in the class list. So it wouldn't match something like '<div class="stacked span-5"></div>'

I struggled with making this decision, but ultimately it's all about readability for me. Hope it's not too much of a hassle for folks, but that's why this happens in a major update and not minor ones :).

I like the human-readability that dashes lend to URLs, but there are two things that bother me about using them in this case:

1. A dash is an operator, which could get confusing when you are doing math. For example: (@grid-gutter-width * (@grid-columns - 1)).

2. As far as variables go... thisIsDoubleClickable, and_so_is_this, but-this-is-not. I suppose it's not the biggest deal in the world, but I really hate having to drag my mouse to select.

My two cents...

Yea this is an age old discussion, I also like the separation that dashes or underscores give. Personally I'm a fan of underscores myself, mostly because I can then have id="foo_bar" #foo_bar and $foo_bar, for html, css, and jQuery variables, respectively, and remembering that JS can't have dashes in variable names. This makes the double clickable aspect super handy to me :)

Sometimes I hear that people don't want to have to press shift, which is understandable considering how much we code. But if bootstrap devs are already pressing shift in order to use camelCase, I wonder why they didn't pick underscores.

This is my general rule: If it's client-facing (eg. a URL) then use dashes - it's more readable (at least I feel it is). If it's developer-facing, use underscores or camel case. Sure it's not as pretty, but it's functional - which is really what we need. This boils down to - do whatever is best for the user.

I've always wondered why they initially chose camelCase and not dashes. I like keeping camelCase for JS only. CSS uses dashes (border-top). LESS uses dashes in its example documentation.

because you can't double click on class names that contain dashes to quickly copy and paste them into your html.

- do look neater but I wont switch because it frustrates me so much to not have that simple feature!

Funny, my editor usage is different, so I prefer dashes for the exact reason you don't. I use opt+(shift)+arrow keys to navigate and select words instead of mouse doubleclick.

camelCase and under_scores both select the full string as a word. But if you throw some-dashes-in-there, and you're using the keyboard, it's super fast to select just the bits of the value you want. Without the dash, you have the select a character level to modify aspects of the string, which is fairly fiddly for being such a common task.

A simple example of this being awesomely quick is adding a pre/postfix to values, eg:

@color-link @color-link-hover @color-link-active

Could someone create a compatibility stylesheet that defines all the camelCased variables based on the new dashed values? Just as a stand-in until you can update all your variables.

That or can someone write up a nice Sed script to grep through my less files and change all the variable names?

It may be limited, but seems to be a good start:

   $ cat <<HN | sed -e '/@/ s/\([a-z]\)\([A-Z]\)/\1-\l\2/g'
   > The following sed will replace camelCase only if it can find an arobase
   >  character in the current line, thus fooBar and bazThing won't be replaced
   > but @fooBar and @awesomeFooBarBazzProperty will.
   > True story.
   > HN
   
   The following sed will replace camelCase only if it can find an arobase
   character in the current line, thus fooBar and bazThing won't be replaced
   but @foo-bar and @awesome-foo-bar-bazz-property will.
   True story.

"Dropped all things fluid."

What are the implications of this? I'm not a web designer, so does that mean that we have to have fixed-width pages? Won't that make it harder to design web apps? Will someone help to clear up my misunderstanding?

The also redid their scaffolding model (grid system) to use percent widths instead of pixel widths, so it seems like the default (and only option) will be for things to behave like the old fluid layouts did.

Yup, and then if you need specific pixel widths on anything, you specify them yourself. E.g. a fixed width page, you'd need `body { width:950px }` or etc.

However I am not looking forward to removing all the row-fluid/container-fluids in my templates.

You should be able to use find-and-replace to tackle most of this—the classes aren't changing too much.

I don't think I saw it on the doc, but is there a projected release date for 3.0? It sounds like there is some pretty awesome updates coming, even though they seem more "back-end" related.

+7 votes for a rough release date. Working on a new project which would benefit greatly from using 3.0... for the meantime, I suppose we just use the bleeding edge version and extend it in a separate CSS file, then keep the base bootstrap CSS up to date.

It would be great to get a prospective date in those types of announcements.

I understand why people want it, but I'd rather most open-source projects avoided announcing release dates.

Best case is they spend a bunch of time on estimation that they could have spent on delivery. More likely is that they rush something that was unexpectedly hard, or drop things that the would have rather kept in. Or, worst of both worlds, they announce dates that they then slip.

Better, I think, that things are done when they're done. Or that they just have frequent, regular releases, like Ubuntu and Firefox do.

"We're thinking probably January" versus "sometime late 2013" would be useful and feasible to provide, though.

> Dropped all things fluid. We removed the fluid grid system, fluid container, and fluid layout.

Damn. That is very handy when you want to have even sub columns inside of an odd-sized parent column.

I was worried when I saw this, but the very next bullet point is:

>Overhauled default grid system. Now uses percentage widths, padding, and box-sizing: border-box instead of pixel widths and margins. Nesting and offsets remain the same.

Which sounds like they are actually making everything fluid, and removing fixed widths. Perhaps a good thing, although border-box means no IE7 support.

They also removed all IE7 specific CSS hacks. IE7 will no longer be supported at all.

Obviously this is particular to each site's visitor demographics, but the only IE7-specific CSS my sites need would be something along the lines of:

    #ie-warning {
        display:none;
    }
    
    html.ie7 #ie-warning {
        display:block;
    }

That's bold but the right decision IMO.

same thoughts here - worried, then optimistic as it should actually be a more simple syntax to create nested grids - would be really nice if you'd be able to do a project wide removal of "-fluid" and it all just works the same

That should work just as you described it.

I thought border-box was pretty much how IE handled sizing anyways up until IE8.

Glad they are finally using icon fonts instead of PNG. Now we can make icons any color and add drop shadows if needed.

It can be easily done (with any svg/fonts you have) using this awesome tool if you're interested: http://icomoon.io

Wow, that site pegs Chrome at 100% CPU on my Macbook Pro..

Hadn't heard of that one but it looks really cool - thanks!

There was http://fortawesome.github.com/Font-Awesome/

Really sad they are dropping support for IE7

unfortunately I will not be upgrading to this version then.

Adding support for IE7 will be easy:

- Add the box-sizing polyfill: https://github.com/Schepp/box-sizing-polyfill

- Use 'display: inline; zoom: 1;' (with the * hack) wherever 'display: inline-block;' is used

IE8 runs on XP, though. Just about every Windows computer still in operation should have IE8 installed, for security reasons if nothing else.

Should but from what I understand IE6/7 still account for fairly large portion of our revenue.

Really? Are you in enterprise software or something? We (WePay) see less than 1% of our traffic and revenue from IE<=7, and that includes the data from our embeddable checkout flow. And of that tiny amount, most is related to our API.

We still officially support 7 for our offsite/embeddable stuff, but from the chatter I hear of the devs that are working on that stuff, the maintenance cost sounds higher than the revenue. Then again, that cost to us is yet another reason that people like our API, since its one less tedious thing for other devs to worry about in their checkout process.

International ecommerce, including China, I can't speak to the exact numbers but the revenue from 6 and 7 is in the millions so we're not quite out of that maintenance cost to revenue hasn't quite tipped yet. Though we do display the ie6countdown.com banner along (and I may have messed it up a bit to display for 7 as well.)

I don't think it would be THAT hard to add back in support for IE7. Also, I'm sure that not long after the release someone will make a forked version that supports IE7, since so many of us still need to support IE7.

In fact, it will be hard! They will use `box-sizing: border-box;`, which changes everything about width calculation and IE7 does not support this property.

_this_. And why drop support for FF 3.6 too? Is there a technical reason to drop support for older browsers or is it idealism?

There's a great reason. Browsers are advancing, and it makes sense to gradually take advantage of features as most of the mainstream browsers start supporting them.

The hacks required to make older versions behave tend to pile up with time, increasing complexity and maintenance overhead for the developers. There gets to be a point where the complexity and overhead is no longer worthwhile to appease a very slim demographic.

Just use older Bootstrap versions if you want older browser support. I don't want your legacy users slowing down the progression for the rest of the modern world :)

This 'very slim demographic' is more than 1 in 20 people on the web still, and catering to them has typically required very little (maybe a few extra lines of CSS; otherwise, modern websites work fine on IE7, just without the nice rounded corners and such). I'll be using Bootstrap 2.x until that statistic drops much lower.

Additional data point for all the people arguing about it deeper in comments: Firefox 3.6 had its last security update 9 months ago (2012-03-13) and hit official end of life from Mozilla a month later.

When was the last time anybody used FF 3.6?

Serious question.

It's the 16th most popular user agent seen across the ~60,000 websites tracked by W3Counter. IE7 is the 7th. Dropping support for both will affect 1 in 20 visitors of the 'average' website (your particular audience may vary).

Maybe 5% of users need to get their shit together and upgrade. :|

They can't upgrade.

Hospitals and big companies lock down the computers, you can't install anything. If it comes with IE7, that's all you got.

And it's not because of these companies.

E.g. they need to run a specific custom version of SAP (accounting), which on turn crashes if any other browser is present. Upgrading would cost over $30M, so forget it for a while.

Or the hospital needs to validate the hardware + OS + software. Until GE does not support feature X they are stuck with the old version which requires a specific list of software to be installed.

You don't want to hear "sorry about the bad news last week that you have cancer - actually it was just a rendering glitch on your MRI due to the new Chrome version".

So life is a bit more complex than "just upgrade"...

To a degree, definitely. As someone who works in healthcare (both as a practitioner - paramedic), and whose other job is healthcare IT...

I know your example is exaggerated for effect, but there is (or should) be a difference between "general use" PCs in a hospital, and Patient Care / Management PCs (EHR, workflow automation, digital diagnostic imaging, pharmacy and the like). That in itself is a failling of healthcare IT policy.

Sure, your critical systems should all be be "certified", but even that is an area ripe for disruption - witness DrChrono in EHR, and I myself am working, or brainstorming on, better "field reporting" (i.e. 911 response laptops / tablets - most software in this field is horrific for usability, though admittedly there is pretty cool functionality, the ability to transmit 12-lead ECG to the hospital for prepping cath labs is fantastic) - definitely willing to talk to people interested in such a thing.

Edit: as an aside, I'm yet to see MRI software that wasn't driven by a Solaris backend, or even Irix, though that does demonstrate how this area works.

I don't see a reason for general use PC in the Hospital (or any other company). Your Christmas shopping is not a business priority. :)

Philips and Siemens runs Windows. As far I remember the GE scanners were RedHat.

I do agree with the "ripe for disruption". Hopefully DrChrono, Practice Fusion and others will force some change.

Not a lot, but they are there. I just pulled the Google Analytics numbers for one of my sites and over the past 30 days (3.3M visits) there were 3,003 visits with Firefox 3.6 (1.2% of all FF visits and .09% of all visits).

IE 7 is more common, there were 67,841 IE 7 visits. Worse still is the 12,188 IE 6 visits. Amazingly there were 78 IE 5.5 visits, the web must be a crazy place with IE 5.5.

I recently found my Windows 98 CD. I should pop that into VMware and try out the Internet.

It's the highest version of Firefox available for PowerPC Macs (pre-Intel).

I was using it this spring (2012) because I had a netbook running Ubuntu 9.04 (9.10 had failed to work properly). But after Google Docs began refusing to let me edit, I finally gave in and upgraded the netbook to 12.04, which has an up-to-date Firefox.

Still, I don't doubt that there are lots of public computers (in libraries, for example) running Firefox 3.6 today. I've seen even older.

I know of a call center here in the US with 300 stations that have XP and FireFox 3.5 and they won't be upgrading anytime soon.

I don't think people are browsing cutting-edge websites on their call center computers.

They are browsing internal web-based tools and services and make it a huge pain for the developers.

Yeah there's even less reason to use old versions of FF than there is to use old versions of IE.

many enterprise users and stability hawks use firefox LTS

Looks like for IE7 they did it so they could use border-box.

Does this add the semicolons back in?

Not sure how reliable this is, but it seems like you can get a preview of how these changes may affect you by testing out the branch 3.0.0-wip.

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

This is something that has been messing with my workflow so hear me out. First, I use CodeKit on my local machine to compile. CodeKit allows me to choose a framework (bootstrap-master > LESS files). I don't want to keep multiple versions of bootstrap-master sitting around on my computer. Preferably, I'd have the most current version with which I'd use to build all of my CSS (regardless of the site I'm working on) by simply pointing to the bootstrap-master directory. However, the inclusion of variables.less in bootstrap-master > bootstrap.less (where it's an import) makes this difficult - variables.less is the ONLY file in bootstrap-master that I need to slightly tweak for each site I create. The variables.less file should not be a default import in bootstrap.less - at least this would be ideal for me. The way things are now, I have to modify bootstrap.less (to tell it not to import variables) and variables.less (to control colors, grid, etc). I'd like to just update all of the bootstrap-master files in one fell swoop without worrying about overwriting my changes to these two files. If variables was not a default import AND it was outside of this framework directory, I could update every file in bootstrap-master without worrying about overwriting anything. I hope I have communicated this in the right way - it seems a bit muddled?

I actually know exactly what you're talking about and here's what I do:

- Put Bootstrap in a folder and import it as a framework in CodeKit. (Just like you.)

- In my project folder, I create a LESS file for the project (e.g. project.less).

- At the very top of my project.less I add an import for bootstrap (@import "bootstrap.less")

- I define and customize all my LESS variables within the project.less without touching bootstrap.less.

Yes, this does mean that the variables are being define again. However, this won't matter because what you define in your project.less will override everything else.

The bootswatch project (basically themes for Bootstrap) uses a similar system, though they generally have two less files, one for overriding variables, and a second one for theme-specific additions.

https://github.com/thomaspark/bootswatch/tree/gh-pages/swatc...

This solution will work for me. Thanks! I suppose it makes no difference that the variables are defined twice? I guess I was just getting stuck on the metaphor of other frameworks (eg. JQuery UI) where my custom files are kept separate from the library. Make sense?

I do the exact same thing and it makes for a nice, modular setup. I have a site.less that imports bootstrap.less and whatever other "legos" I need.

Any thoughts on how the changes compare with Foundation 3? Is the grid system up to par?

Exciting! I really hope they do end up going with multiple modal widths in 3.1, as I've had to do this myself on more than a few occasions.

On a side note, I'm curious as to why they decided to refactor their variable names to include dashes instead of just sticking with camel casing. Personally, I find camel casing to be much more readable.

For a while the dash-ing annoyed me until I realized that it makes selecting/changing part of a variable name easier (at least in vim). Can't imagine that's the reasoning behind it but it does work out well.

Vim wasn't the exact reason, but text selection is a huge part of it. Readability and text selection are huge.

Thanks, that's good to know.

I suppose it doesn't make _too_ much of a difference considering I prefer to use hyphens in my css classes anyway, but this just seemed like a somewhat useless change that will end up breaking a lot of customization's..

Although not always, you'll end up mixing CSS with JavaScript. In this case when naming CSS with dashes it's easier to differentiate from my JavaScript names, i.e. $("#myDiv") vs $("#my-div").

> Responsive CSS is no longer separate.

Will we still be able to easily remove things like the "large desktop" size?

Yes, of course. The customizer will continue to have the ability to include or remove the media queries for these. You can also always make a local build on your own to do it.

Awesome, thanks! I typically just drop in Bootstrap with a Rails gem but this is good to know.

I don't see why you couldn't. It's pretty easy to find media queries in the CSS, because of the unique styling they have in the CSS file.

Right, but if I want to disable it right now, I simply remove the include and updates to Bootstrap don't require me to do any extra work.

If it's not easy to remove, I'm guessing that I can just set the large format to something ridiculously high for the minimum width.

May I ask why you'd like to? I've invested in a large monitor to avoid being stuck with thin column layouts.

Just that the client didn't want the two different sizes for desktop. Nothing in particular, just didn't have time to invest into that and it wasn't really providing that much benefit for the site we were working on.

> Hero unit > ❑ Convert class to .jumbotron.

can someone explain the rationale here?

V2.2.2 used ".jumbotron" AND ".masthead" for the hero unit in the docs, so I think they are just condensing that to one class.

See this screenshot: http://bluetide.pro/cPkH/5LohuilN

Pretty much. Plus, it's a much better (and more socially known) metaphor for describing its function and presentation.

"Dropped all things fluid."

Looks like I've got some updating to do in the near future.

The default grid system will be come fluid (using percents for widths), so you'll have to just find and replace the row classes and you should be okay. Unsure about more complex layouts though.

This is awesome, thanks for the clarification.

I got scared at 'dropping fluid', because it's become been pretty clear to me that the fluid approach in bootstrap was better for most apps, and I was wondering why in fact using the fluid approach wasn't more popular. I got worried that you were making it much more difficult -- but it turns out you agree with me, and instead are making it the out of the box default! woo!

How about dropping support for LESS and using SASS instead?

You mean, "how about re-engineering the entire project for little benefit"? LESS vs SASS is one of the more infuriating "this vs that" argument circling the web right now, because everyone is so inexplicably vocal and passionate about it.

Looks like there is already a SASS port:

https://github.com/thomas-mcdonald/bootstrap-sass

The SASS ports tend to lag behind the original or don't leverage the full potential of SASS/Compass.

I personally think SASS has won out over LESS since the introduction of SCSS and if Bootstrap dropped support LESS would gradually fade away.

Won out in what sense? Last I checked there are no formal figures about usage for either. Bootstrap's phenomenal popularity ought to make it a kingmaker for the preprocessor it uses, I suspect.

Well, the CSS preprocessor ecosystem is a clusterfuck (pardon my french).

Since the differences are so marginal I wish projects would pick their preprocessor by the number of available implementations (in popular languages) rather than the latest fashion.

Less and stylus only have javascript impls and should be avoided for that reason alone. The same applies for most other niche processors.

Like it or not, SASS appears to be the only one with a C library that enables a wide range of language bindings.

In the Microsoft corner of the world, DotLess[1] is pretty popular, and way more mature than any SASS libraries in .NET.

[1] http://www.dotlesscss.org/

Recently I was investigating using LESS on windows. I didn't want to do it at run-time a la DotLess, but at build-time. I wasn't able to install node.js so i had to scout around for other options...

I came across this: https://github.com/duncansmart/less.js-windows

It leverages the fact that windows has long supported running JavaScript (OK technically "JScript") outside of the browser, without node, to create a command line utility from the less.js implementation. Works perfectly :)

I personally think no CSS preprocessor has won out over any other.

Negatory, but given the prominence of the ports and use of Sass, we'll likely try to do something here to help folks out who are using that over Less. No reason we couldn't write a script to translate the two or officially sanction a port. Both have their pros and cons; just a matter of time, duplicate code, etc.

that's awesome to hear.

Even if you don't officially sanction or provide a port yourself -- just hearing that you're open to tweaking the way you do things a bit to make it easier for _others_ to port to Sass (and keep their ports up to date with bootstrap evolution) -- is super encouraging.

I'd actually suggest that as a first step, just talk to the folks maintaining the ports, and ask if there's anything you can tweak on your end to make their jobs easier.

On significantly large projects, the compass compiler can take a lot more time than lessc. Eg. Sencha Touch's sass based styling.

does SASS work without installing the pre-processor? I know LESS does. I didn't think SASS did. LESS will work well enough with just the js file loaded (if a bit slower).

You still have to compile both.

You shouldn't be running less.js in production.

Interesting, I didn't know this, though in retrospect, it should be obvious, versus compilation.

:) I see what you did there....I also agree

Any word on carousel supporting fades? They mention vertical movement but thus far I've had to hack in fades a lot

When will input and button size classes (e.g. input-xxlarge) be normalized as hinted to in the current docs?

Does 'punted' mean punted away like in a sport? Or does it mean bet on, like at a casino?

It's the sports metaphor ... kicked down the field for later

well i like it! i usually get a helping speed boost through NetDNAs CDN serving of bootstrap files. http://blog.netdna.com/opensource/64-million-request/

Still punting ARIA support?

Some of these like Glyphicons are already in Kickstrap (a Boostrap fork)

Can't wait to use it.

I really like how frequently words like 'dropped' 'removed' and 'consolidated' are used. Was a little worried about bloat with the creators now having more time to devote to it. Great to see that wont be a problem!

Yup, loving that we're getting rid of stuff out of the core. Definitely a major focal point of mine to date.

Any reason why you prefer that over "deprecated"?

Deprecation keeps the code around to increase size, reduce performance, and slow down development.

Seeing lots of stuff dropped is preferred to seeing lots of bloat added.