Why does Twitter Bootstrap Use Pixels for Font Size?

Given that Twitter Bootstrap is designed to be responsive / device-friendly, why doesn't it use relative font sizes?

Solution 1:

Well it seems that they are hiding behind the browser zoom excuse. Really sad to see such a heavily used and influential framework completely ignore accessibility issues and a fundamental cornerstone of responsive design. They are in a position of great responsibility and unfortunately seem to have no intention of acting accordingly.

[Update] So today Mark Otto replied on the thread I referenced above. Predictably there is no mention of accessibility and use of the phrase 'pixel-perfect':

Okay, so here's a bit of a background on the decisions of yesteryear and plans for moving forward.

Pixels provide absolute control and consistent rendering across every browser.

Designers still mostly think and operate in pixels.

Browsers scale up entire pages these days, so it's not an issue with type scaling or anything.

Nesting ems historically has been a pain and can require extra math for figure computed/intended pixel values.

Mixing units of measurements is ugly and my inner OCD hates it. Using units on line-height is generally discouraged, but provides immediate knowledge of what the computed value is. We'll probably try to steer away from this in the future. In the future, we'll likely use ems for type sizing, perhaps rems even, but not for anything else. This is also debatable on font sizes for inputs and the like. It's just not how folks build pixel perfect sites.

That's a bit all over and hopefully coherent enough. I'll try to blog about these changes as they come up more, but I'm unsure how close 3.0 is and what that will all entail yet.

I would suggest anyone with strong feelings about this go and +1 this thread.

[Update] V3 roadmap oulined in V2.3 release blogpost makes no mention of adding support for ems.

[Update] Lots more information about Bootstrap V3 available in the pull request here including the following from Mark Otto:

We explored the use of rem units over pixels, but found little benefit to offset the implications of their use. IE8 would still need a pixel fallback, and that's a lot of duplicate lines of code. Moreover, using rems everywhere instead of pixels would exacerbate that problem. Mixing rems and pixels doesn't seem to make sense either right now. However, we can and will continue to evaluate this in future releases.

Then more recently (in its comments):

I highly doubt we'll be shipping with rems at this point. Changing everything—beyond font-sizes—is a huge task and one that comes with few benefits to offset that. Double the lines of code for font-sizes aside, supporting rems in any other way seems tedious at best. That said, we can always revisit in a future release. For now, we're sticking with pixels.

Having grown dissatisfied with a large number of Bootstrap's features, not least of which is it's lack of em-support, I strongly suggest looking at Susy if you just want grids, or Zurb Foundation 4 for the whole enchilada. Don't let Bootstrap's popularity cloud your judgement. Anyone can build something with Bootstrap, which is exactly its problem - it's designed for people with minimal web-experience. Just because there are lots of McDonalds' in the world doesn't mean it's a healthy place to eat.

[Edit] OK. This was a silly thing to say. Since I wrote this, I've used BS3 and it has upped its game considerably. I shouldn't have made such a throwaway comment, but I still believe that it has made a bad decision in using pixels for font-sizing. As well as accessibility issues, ems are useful in other ways.

[Update] Looks like rems will be supported in V4 (Mdo quoted from here):

For those following along, we'll be able to change from pixels to REMs in v4 when we drop IE8 support. Can't do much until then.

[Update Feb '17] Bootstrap 4 is still in Alpha, but shows use of rems in its Typography docs, but doesn't show use of rems in its layout docs.

Solution 2:

Don't let Bootstrap's popularity cloud your judgement. Anyone can build something with Bootstrap, which is exactly its problem - it's designed for people with minimal web-experience. Just because there are lots of McDonalds' in the world doesn't mean it's a healthy place to eat.

You could argue not to let it cloud your judgement in a negative way. It's a solid framework and if you bother to invest the time into how to use it effectively, the majority of your argument falls on it's head.

Whilst it's often used by people with minimal experience - and there's nothing wrong with that - it's also used by people with a lot of experience.

At very least, it's an invaluable prototyping tool. At very best, it's completely customisable. You can pick and choose, modify, add to - which is why it's called a 'framework'.

I've been using it effectively on some of my projects for over two years - it's as lean as you want it to be. I've used just the form framework, just the grids, the entire codebase and customised it to suit my needs. In many ways, it's 'upped' my game, getting me further into preprocessing, using variables, honing the way I structure projects.

Yes, there are some issues. px for font sizes and using Less are two. However, because it's entirely open source, you can find options to remedy both of those easily.

I investigated Foundation and liked what I saw, but I'm in the unfortunate position of having to support IE8, as many devs are. Foundation has dropped support for IE8, making it a 'no go' for me. Despite this, I'm not about to dismiss an entire framework, most specifically something that is free to use and free to modify based solely on a few issues!

Heck, in one project, I lifted parts of Foundation and parts of Bootstrap and added my own custom code - that's the beauty of open source.

Solution 3:

If you still prefer Bootstrap with em and rem support you can take a look at this - https://github.com/ivayloc/twbs-rem-em there is no need to make any calculation to convert pixels in rem or em units, there is build in @mixins for this - @include rem(property, values) - also fallback to px and for em convertion you can use em(value).

Solution 4:

Whilst I use Bootstrap extensively, there's a few areas where accessibility takes the back burner. I guess there's inevitable trade-offs with a platform that's used so extensively.

I completely get why they've opted to retain pixels for font-size. The inheritance issues with em's for a framework's fonts are a total nightmare.

rems are an alternative option, but browser support is still problematical.

You could create your own rems mixin and replace every line of less which uses the base font size variable.

That's the beauty of bootstrap - and frameworks like it - it's a solid base to work from.

Yes, I've mentioned there's elements to twitter bootstrap which aren't that accessible - one small example, the use of 'display: none' instead of using clip. I'm pretty damn sure there's a valid reason for this - and again, you can very easily modify this if you want.

Bootstrap isn't flawless, but then, I doubt it was ever intended to be the final answer to all your requirements. It's a base - a 'bootstrap' - learn it and utilise it properly, add to it, mix it all up - at the very least, it's an awesome framework to prototype with, or to throw together a quick site. Going further, there's some really solid groundwork within that can be applied to any website.