
The Revenge of the IE Box Model? - cbr
http://www.jefftk.com/news/2012-02-18.html
======
jasonkester
Notice that the author mentions CSS1 was published in 1996. IE3, the first
version with CSS support was also released in 1996, meaning it was in
development well before the W3C got together and decided on what they thought
the standard should be.

It's not like they read the "standard", then deliberately misinterpreted it,
as is the popular belief. Rather, they just picked a sane model and
implemented it. If anything, it would have to have been the W3C who
deliberately wrote their spec to leave IE out in the cold.

Naturally, I don't think either one was the case. It seems that the IE team
made the correct choice (as it's very difficult to argue that the IE box model
is not in fact a better way of thinking about boxes), and the standards team
(who weren't actually in the business of building browsers) made a less good
choice.

If only the Netscape team weren't so (possibly for good reason) angry with
Microsoft, they might not have switched they way they sized boxes when they
built Navigator 6, and we would have had a much less painful time writing web
apps these last 10 years.

Shame. At this point, it's probably too late, as we're all thoroughly trained
to deal with the idiosyncracies of the W3C box model to bother using the CSS
hack mentioned in the article to get us back to a sane box model where a box
with a width:100px actually renders as a 100 pixel wide box.

~~~
recursive
> Shame. At this point, it's probably too late, as we're all thoroughly
> trained to deal with the idiosyncracies of the W3C box model to bother using
> the CSS hack mentioned in the article to get us back to a sane box model
> where a box with a width:100px actually renders as a 100 pixel wide box.

It's never too late to do the right thing. As an extreme example, everyone
who's used to it now, will eventually die, and I'd venture to say the web will
outlive them all. (although probably not in its current form, but that's kind
of the point) CSS3's solution is a good one because it allows people that are
used to it to keep using their old dodgy hacks, and it also allows people who
prefer logical consistency to opt in to that. It's definitely not too late.

~~~
glhaynes
_everyone who's used to it now, will eventually die_

True, but there's a continuity of already-written code and learning, both from
those alive now and from that already-written code, that keeps things that
aren't sufficiently bothersome from getting changed.

------
blahedo
The real issue with which one "seems right" in some sort of intuitive sense is
that it varies with what I'm doing. If I'm sizing something that is
fundamentally a _container_ , then I care about the size of the whole box,
including padding (and probably also border), for all the reasons that the
pro-ie-box-model people have said.

On the other hand, if what I'm sizing is something that is fundamentally
_content_ , then it's the W3C box model that seems more appropriate. "I want
this paragraph to be 25em wide" probably means you actually want 25em worth of
width actually dedicated to the letters themselves. "Scale this image to 320px
width" makes a lot of sense if the image is natively some multiple of 320
pixels wide, and if the actual width the image itself gets is only 314 pixels
due to border and padding, well, your image quality degrades.

The really-right solution is to be able to say "assume this box model for
certain types of elements, and assume this other box model for other types of
elements, and also let me override it on a per-element basis." Which the new
CSS lets you do. Win!

------
lutusp
A quote from the article: "Logically, a box is measured from border to border.
Take a physical box, any box. Put something in it that is distinctly smaller
than the box. Ask anyone to measure the width of the box. He'll measure the
distance between the sides of the box (the 'borders'). No one will think of
measuring the content of the box."

I won't try to imagine the originator's reason for taking this view, but to me
it undermines the reason for having a nonzero-width border between the inside
of the box and the outside. I would have argued that the border of a CSS box
is like the wall of a physical box, with an inside width and an outside width.
Inside the border, we can adjust appearance with padding. Outside the border,
we can adjust spacing between elements with margin. To a page designer, the
"width" of the box should be the width of its interior.

Imagine a country that needs to establish the limits of its territory. There
is a line on the maps between their territory and that of its neighbors. They
decide to establish a border region, a finite-width "no man's land" (that only
women can visit). Do they draw the "border" inside the established frontier,
or outside it?

But these are all flawed arguments, and this is well-recognized in the
container industry, who always specify a container's interior width, and an
exterior width. To fill the box, one needs to know the interior width. To ship
the box, one needs to know the exterior width. The difference is the wall
thickness, and the corollary in CSS is the border width.

So the argument "Logically, a box is measured from border to border ..." is
true, but would only be a useful description if the border had zero thickness.

But the argument that follows: "No one will think of measuring the content of
the box", in which "content" is meant to contrast with "width", is obviously
wrong -- to many, content size is exactly what measuring width means.

And as others have said here, it's far too late to be having this
conversation. Standards must precede their application, not follow them.

------
zyb09
Yeah, I agree IE box model makes more sense. Padding is basically useless if
it adds to width, most of the time you end up creating inner divs with margins
to simulate padding. Didn't know you can toggle the behavior in Moz/WebKit,
good to know!

~~~
phpnode
supported in IE8+ too

------
jinushaun
IE's box model always made more sense than the Standard. Why would I ever want
100% width plus an additional 1px of border adding scroll bars to my page?!

------
ndefinite
With 4 layers to the onion wouldn't it be easier to have 4 width measures?
Then you could simply decide which width is most relevant to your application
(outer margin, border, padding, or content).

There's different use cases, without listing them all just think how many
times you've had to calculate the one you don't have access to

------
Edootjuh
Both models have an advantage. The padding outside the width makes it easy to
make a border that doesn't touch the box, while the padding inside the box
makes... well... padding a box easier.

Personally, I find the padding inside the box more valuable so when I found
the `* { box-sizing: border-box }` post I decided to use it, and it's also
what I expected it to behave like when starting web design.

------
vonuebelgarten
"[1] Technically the new rendering engine, Gecko, predates the Phoenix
Firebird Firefox project. When Phoenix 0.1 was released in September 2002,
Netscape had been using Gecko since November 2000's version 6. By that time IE
was over 85% of the web, though."

Why do people always forget Mozilla (the browser, not the organization itself)
?

------
mbala
Lets take a practical example.

Look at Uhaul 17' truck
[http://www.uhaul.com/reservations/images/Equipment/Trucks/17...](http://www.uhaul.com/reservations/images/Equipment/Trucks/17Dimensions.png).
What do you care most? Inside or outside dimension?

~~~
ghurlman
When I'm lining up trucks to fit in the lot?

The outside dimension.

------
wavephorm
IE did it right.

This problem gets exposed any time you try to do something like:

    
    
      width:100%; border:1px
    

Cause you can't see the border. It's really stupid, the spec got it wrong.

------
recoiledsnake
>Adopting IE's approach here then might have told Microsoft "you can do
whatever you want with IE and we'll adjust the standards to make it legal".

No, making an exception for this one case won't send that message. No one is
telling them to change the standards for the rest of the quirks, many of which
are arbitrary or just convention.

------
warfangle
IE's box model made more sense, but everyone else coded to the standard.

And yet, even IE9 has major CSS bugs.

For example, say you want rounded corners. Cool, it does border-radius!

For example, say you want gradients. Cool, it does ... well, sorta. ms-linear-
gradient works fine on its own. border radius works on its own. But combine
them together, and you're in for a world of hurt:

The box shadow, and border radius, show up fine. But the radius doesn't clip
off the corners from the gradient - so you get a perfectly weird looking
element.

I give them a B for effort, an F for actual usage.

