Shared publicly  - 
After criticizing IE for their broken box model for years, web developers are now excited about a CSS option to use that model in all browsers. What's going on?
Chris Demetriad's profile photoYitzchak Schaffer's profile photoDylan Anderson's profile photoJeff Kaufman's profile photo
Not sure if "excited" is the right word here. Some frameworks (like extjs) choose the IE box model just so it's one less variable across browsers.
This is exactly what CSS vendor prefixes are for! Every browser maker gets to implement their view of the world, then bleeding-edge web devs try things out, then the standard gets written. In my opinion, this made the CSS3 flexbox spec better, though it does take forever to get it done.

Too bad IE developers are arguing against vendor prefixes, though I guess that's not surprising at all.
+Jeff Kaufman Both box models have their purposes, so now that the browsers can handle the additional complexity, having both options available to authors is the right call. The CSS box model makes perfect sense in the context of that CSS1 specification, where the width and height properties were primarily intended for sizing of images. (The base profile of CSS1 doesn't even require rendering engines to honor CSS heights for anything but images and plugins.) In that context, authors probably do want the height and width properties to size the content (the image itself) instead of the painted area (to the outside of the border).

Then, the standards committee continued the same behavior when they added positioning capabilities in CSS2, even though that choice of box model tends to handicap the development of fluid designs (as you point out in your post). Given the various tradeoffs at stake during the development of CSS2, I'm just glad the committee had the integrity to stick to their guns with the CSS box model instead of, say, special-casing elements with percentage widths to use the border-box model. (If you think nobody could be that crazy, please consider the atrocious mess that is the vague table layout algorithm in CSS2. The committee decided to [try to] specify the existing table layout behavior in IE and Netscape 4; the resulting spec is inconsistent with the rest of CSS while failing to comprehensively specify a single intended behavior.)

+Victor Costan True, but bringing up vendor prefixes in this particular context is anachronistic. In the days of IE 5 and 6, vendor prefixing wasn't yet an accepted practice for proprietary developer-facing APIs. In fact, the standards community developed the current consensus around vendor prefixes specifically because of the incorrect box model and other less-significant misinterpretations of the spec in Microsoft's implementation.
The IE box model better, but IE's using it made the box models inconsistent between browsers, and inconsistency is way worse. The decision to support both models at once appears to have been made long ago; it's just that now someone's noticed enough old browsers have died off to use it.
The flaw of the original box model is not subtle. It is completely impossible to layout a page using the original box model if you want to completely fill the screen and no more, but it can be done with ie's model. The reason so many pages use tables for layout is due to the utter uselessness of the original box model for full screen layout.
+Peter Olszowka I don't believe that's true: with a pair of nested divs you can do everything the IE model does.
Give me an example with non-zero margin, border, and padding and the space divided into three portions of 20% / 30% / 50%.
+Peter Olszowka You should be able to do this with three divs with zero margin, padding, and border set with widths to 20%, 30%, and 50%, each containing another div with the desired margin, padding, and border.
How do I force the inner div to occupy the full space of the container div leaving room for margin, border, and padding?
I don't have access to my web server from work, so I can't show you right now, but now try putting something too wide to fit inside the left inner and specifying "overflow: auto". The box will just grow rather than display with a scroll bar because you really haven't constrained the width.
Also, on IE9 on Windows7, I got a horizontal scroll bar on the page for some window widths. I think that may be a browser bug due to using integer rather than floating arithmetic to do the width computations.
+Peter Olszowka +Jeff Kaufman Which positioning approach are you using to put those three divs side by side? I'm not sure whether you're talking about the same thing.

In any case, if your explicit goal is to mimic the table layout model as closely as possible, the obvious CSS solution is to ditch the box models and just use the table layout model: use display:table-cell for each of Jeff's outer divs on those columns, and if you want extra guarantees that the arithmetic won't cause horizontal scrollbars, wrap it all in a container with display:table-row (or display:table) and width:100%. (Added in edit: Note that this won't work in IE < 8, Safari < 4, etc -- but those browsers are increasingly irrelevant.)

That said, I'm not sure why you couldn't put your overflow:auto on the outer div for each column (since that is width-constrained) and use the crude hammer that is overflow-x:hidden on the nearest overflow:auto ancestor (probably body in this case) if it's essential to get rid of your horizontal scrollbar.

There's also always absolute positioning without defined widths, if your design constraints allow you to use absolute positioning:

#col-left { position:absolute; left:0; right:80%; }
#col-middle { position:absolute; left:20%; right:50%; }
#col-right { position:absolute; left:50%; right:0; }

(Correction from edit: Syntax error and column ordering in example CSS.)
I think box-sizing:border-box is reintroduced just for convenience to use with CSS3 calculations (please look at the examples) not to recover a buggy (coincidental or intentional) misimplementation of standard box-model
Discussing who was right makes no sense, standards always have to be followed (even for arbitrary decisions) to ensure interoperability. This is a NEW choice in the standard, even when it matches de IE faulty box-model, it has now a purpose.
We derided IE because they were the only ones using it, and it wasn't optional. Having the OPTION to use it in all browsers is great, because it's behaviour can be expected & predicted.
This is a riot, I was just working on a project where I cognitive-dissonanced against the standard box model WRT combined width, right before I went to read CodeProject and found this post.
It's helpful to remember that up until Internet Explorer 5.5, Microsoft was mimicing what the leading browser did. Starting in 2001, with Internet Explorer 6, the box model followed the W3C CSS specification.
I don't really like changes to be honest. I admit IE's box model sounds better but I am a bit reluctant. All I'd like is to have all these games ended so we can really focus on semantics, good practices, etc.
Add a comment...