If you use it sparsingly, like on specific div's only - and you can do that, because box-model:border-box only _really_ matters and is _really-really_ good when dealing with percentage widths, you can fix it with 'behaviour' and css calculations. Done that.
It means that a 300px wide image won't fit inside a 300px wide box any more.
You need to decide whether your sizing for each element depends on your layout or your content, and choose accordingly. If one way is more useful to you nearly all of the time, then use it that way.
We use it for the Chartbeat dashboard (demo here: http://chartbeat.com/demo/) and it's been delightful, but we also made the decision while we were already doing a redesign. This meant we weren't just adding another rule to the page which would change everything; we wrote new CSS with this concept in mind.
My biggest gripe with Coderwall is that without comments, there's a lot of stolen content in addition to no way to correct someone when they're off about something or give them a better suggestion.
Correcting someone on Twitter draws a lot more attention to the conversation than necessary and, in my experience, people react more defensively because of it. I also don't think it makes for very good UX to have to go to an entirely different site to ask questions or get refined answers to posts, especially when those conversations are relevant to everyone else who reads it.
Funny thing is that this is how "classic" IE (<=6?) used to calculate things. I personally always found it to be the more sensible way. Not sure why the standards body decided to do the opposite, and then only implement border-box as an afterthought.
> Not sure why the standards body decided to do the opposite
I've always assumed that they were going by how designers/publishers/typographers traditionally measure things - the "the way it is done" rather than necessarily "the way that is right".
Personally I feel that only counting the content area is right (it sits right in my head), but it is sometimes less convenient in reality because of other limitations of the document and styling models (for example because sometimes know the dimensions of the outer parts as they are inherited from elsewhere). Having the option gives us the best of both worlds, assuming it doesn't get implemented oddly and cause further browser incompatibility issues.
The problem is that there is no "right way", there is only "useful way". Sometimes, you need to specify the width of the content, other times, you need to specify the width of the box so that it fits with the other boxes. Personally, the way I would implement it, is have two css properties, content-width and box-width, that could not be set at the same time.
Title is a bit misleading, it's a valid CSS property, not a hack. And the width of block elements has always been predictable, albeit slightly confusing (width + padding + border = element width, etc.)
Life would be so much easier if instead of "width" we had "content-width" and "total-width", wouldn't it? (conflicts would have to be resolved one way or another, though)
Tempting, but may be a bad idea. Within hours of applying this to my personal site I got emails that the layout was broken, from people using older browsers.
20 comments
[ 3.7 ms ] story [ 50.2 ms ] threadThe biggest downside is that its only supported in IE8+
2. No IE < 8 support
>> You might get up in arms about the universal * selector. Apparently you've heard its slow. Firstly, it's not. It is as fast as h1 as a selector
You need to decide whether your sizing for each element depends on your layout or your content, and choose accordingly. If one way is more useful to you nearly all of the time, then use it that way.
However, also be aware that the star rule is the least performant rule in CSS (http://stackoverflow.com/questions/1714096/why-is-the-css-st...).
"Border box ftw": http://paulirish.com/2012/box-sizing-border-box-ftw/
I've always assumed that they were going by how designers/publishers/typographers traditionally measure things - the "the way it is done" rather than necessarily "the way that is right".
Personally I feel that only counting the content area is right (it sits right in my head), but it is sometimes less convenient in reality because of other limitations of the document and styling models (for example because sometimes know the dimensions of the outer parts as they are inherited from elsewhere). Having the option gives us the best of both worlds, assuming it doesn't get implemented oddly and cause further browser incompatibility issues.
Polyfill for supporting IE < 8: https://github.com/Schepp/box-sizing-polyfill
Interesting. The Safari documentation still lists the vendor prefix version, but the browser itself supports "box-sizing" directly, as does Chrome.