Hacker News new | past | comments | ask | show | jobs | submit login
The Revenge of the IE Box Model? (jefftk.com)
49 points by jefftk on Feb 18, 2012 | hide | past | web | favorite | 19 comments



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.


> It's not like they read the "standard", then deliberately misinterpreted it, as is the popular belief.

Is there anybody out there who believes that?

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

There's no hack, it's an official CSS property which switches to the "IE" box model. And considering how useful it is (I've said it in the past, I'll say it again, I've never encountered anybody who thought the W3C box model was objectively superior to the MSIE one, it's just that one was the specified, cross-browser, standard model) I have no doubt whatsoever it will be used. A lot.

That web developers have had to put up with it for the last ~5 years does not matter, it's still cognitive load and it still has to be learned by new developers. `box-sizing` lowers developer cognitive load, it'll get used whenever it can be used.


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


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.


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 this "extreme example" somehow proves your point that it's "never too late"? If it includes people having put it with this dying, then I think, it IS too late.


"IE3, the first version with CSS support was also released in 1996"

I'm pretty sure that while IE3 and even IE4 had some CSS support they didn't implement the box model yet, padding-inside or padding-outside.

(But I wasn't sure enough to put it in the post.)

It's also likely that Microsoft knew what was in the spec before it was finalized and officially published.


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!


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.


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!


supported in IE8+ too


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?!


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


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.


"[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) ?


Lets take a practical example.

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


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

The outside dimension.


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.


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


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.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: