

CSS hack: Predictable block elements - bitsweet
http://coderwall.com/p/rwm-3g?utm_campaign=protip&q=css&i=1&p=1

======
acabal
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.

~~~
dspillett
_> 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.

~~~
tomp
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.

------
helipad
Paul Irish posted a good article on the ins and outs of using it on __every
__element. If it's good enough for him...

"Border box ftw": <http://paulirish.com/2012/box-sizing-border-box-ftw/>

~~~
efields
This is the original source of the * approach to box-sizing. The OP is a
ripoff.

~~~
mnicole
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.

~~~
Timmy_C
Coderwall does give you links to contact the author if you'd like to suggest
something. His Twitter handle is on his profile page.

~~~
mnicole
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.

------
projectedoptics
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.)

Polyfill for supporting IE < 8: <https://github.com/Schepp/box-sizing-
polyfill>

------
leephillips
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.

------
iMark
_> "box-sizing" has been supported in IE since version 8. Other browsers still
require a vendor prefix_

Interesting. The Safari documentation still lists the vendor prefix version,
but the browser itself supports "box-sizing" directly, as does Chrome.

------
xentronium
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)

------
gojomo
Sounds reasonable, but are there any downsides to consider before adopting...

    
    
       * { box-sizing: border-box; }
    

everywhere...?

~~~
jonespen
Not according to Paul Irish: <http://paulirish.com/2012/box-sizing-border-box-
ftw/>

The biggest downside is that its only supported in IE8+

~~~
atirip
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.

