As it's been said in the comments, it's amazing that after years of lobbying IE to change its box model to match W3C, we realize that maybe IE's model made more sense after all.
> it's amazing that after years of lobbying IE to change its box model to match W3C, we realize that maybe IE's model made more sense after all.
Not really. Everybody I've known (in about a decade) has felt the IE box model made more sense.
But here's the thing: it wasn't the standard, the standard was not going to change its default box model, and dealing with a single slightly worse box model would always be better than dealing with two completely different box models.
box-sizing is the alternative, and a pretty good one. But I don't think anyone ever read about the differences between the W3C box model and the MSIE box model and thought "wow, the W3C box model makes so much more sense".
I've felt for years that the "broken" IE model made more sense. Your element has a height and width, padding pushes inward against interior content and margin pushes outward against exterior content.
Glad to see others think this too, I always thought it was just me.
>padding pushes inward against interior content and margin pushes outward against exterior content.
That actually seems the wrong way round to me. If you think about a document, the margin is what separates text from the edge of the page (or interior padding, if you will). Padding, to me, implies an area around an element that other elements can't touch.
No, you're looking at it the wrong way. What you call the paper's margin is actually the paper's padding. Or better yet, when you are setting the margin of a document you are actually setting the margin of all the text on the document to the defined width.
That's what `box-sizing: border-box` is! You can't just change the default because that would break existing websites and the W3C's box model was adopted by every other browser.
If individual vendors mess up when implementing the spec from the standards body (which they are a member of) then they should have to clean up their own mess. IE did eventually change the default in IE6 and added quirks mode for compatibility with websites designed for <IE6.
Even if the majority of people preferred the IE5.5 box model, it didn't follow the spec and it is therefore wrong. We have standards specifications on the web to maintain cross-browser compatibility; if browser vendors don't follow them then whats the point?
Even if the majority of people preferred the IE5.5 box model, it didn't follow the spec and it is therefore wrong
Specs should standardize what's generally considered a good idea. They are not written in stone and have no value in and on itself. If IE's old model was consensually better (and I'm not sure it was), the spec should have changed, not the other way around.
After all these years writing CSS, I'm very biased and it's hard to evaluate which is better. I was aware of border-box, but I thought it was Webkit only. Though I probably won't make the switch altogether, I'm glad to know we have a choice.
This article was an eye-opener - I write CSS all the damn time and hadn't even clocked box-sizing yet.
I don't wanna know how many hours I've spent calculating widths-after-padding(-but-wait-it's-different-on-both-sides) and commenting the CSS so other developers know why this element is width: 169px even though the container is 200px...
Wow, yeah. For years I've been using the container-div idiom, where the outer one sets the width, and the inner one imposes border and padding against a width: auto.
I don't know what I did, but after I doodled a bit and scrolled the page around using the middle mouse button, this youtube video popped up over the page: http://www.youtube.com/watch?v=E6x_-xKl-Fg
Also the konami code makes the same sort of unicorns appear that were on the video.
As I pointed out on twitter http://twitter.com/#!/jhummel/status/169561232045649921 it seems that the * selector doesn't apply to pseudo elements. If you're going to take this route it might be a good idea to include *, ::after, ::before { box-sizing: border-box } to make sure everything is being sized the same.
Where the traditional box model starts to make sense is with fixed-size elements, such as images. Adding padding to an element shouldn't alter the dimensions of the contents within the element.
Using your analogy, if I have to transport an item, and I want to pad it sufficiently, I should be looking for a bigger box. Not trying to shrink the item.
Works fine on my own machine (13, Linux). But that doesn't help people who are stuck on machines where it doesn't. I suppose the code could detect low frame rates and reduce quality or shut down?
I love you Paul Irish. I was just complaining about this exact same issue about 3 days ago and when I found this article I was like YES HE AGREES WITH ME!
Especially when dealing with fluid layouts, this guy is a lifesaver
Yes, trying to do fluid layouts with percents and borders is a huge pain without this. Too bad it doesn't work with IE7 as I'm still seeing about 5% market share from there. But at least it's declining fast.
Weird timing - after years of coding I literally found this box-sizing solution today on SO just a couple hours before seeing it here on HN.
Yeah same, found it like 3 days ago and was like thank god. I'm going to create a fix for IE7, whether it's a polyfill or sass wizardry, and I'll make a post about it when I do. Easy fluid responsive layouts for all!
Good god, it's about time this hits the mainstream dev community.
The W3C box model is IMO one of the worst design flaws in front-end dev. It's a model that doesn't follow that of a real box! When you have padding (stuffed newspaper, peanuts, etc) in a packing box, the actual width and height of the box doesn't change! Border-width(or the thickness of the cardboard) is also included in the box dimensions.
I've only heard very weak reasons in the past for the W3C version and I'm surprised we haven't gotten past it. I think border-box will become more important as we head towards cross-platform responsively designed apps and sites with tons of layout decisions to consider. With simple sites up until now, you could afford the loss of control or the cognitive overhead to figure out workarounds. But now, I don't want to think the unintuitive way every time I'm making a layout decision for different screens.
I've found border-box to be especially helpful with mobile layouts. I can set the width of my text inputs to 100% and not worry about weird side-scrolling breakage. And of course save time by not having to specify widths for the inputs. or max-widths or whatever.
I was working on my portfolio site (link in my profile) and was frustrated with the CSS layout rules. It makes a lot more sense (at least to me) for the way it works with box-sizing: border-box than what it was previously.
If I were not afraid of having my portfolio site also easily accessible by HR in various different companies (many still with IE 6) I'd have used the experimental tags. Instead I used a work-around.
Incredible. I wish someone had told me this a few years ago, would have saved me a ton of grief. Jeremy Keith said it best in the comments: "box-sizing: border-box is the bee's knees."
The way I have been getting around this until the last year or so was just double wrapping divs. Setting a wrapper to have the width you want with 0 margin and padding, and then assigning the padding and margin you want to the inner div does essentially the same thing
Right, exactly, and in a complex layout that adds a significant amount of extra markup. Not to mention trying to find which of the 4 or 5 columns is the one that's breaking the width of their container and causing the last column to break below the rest. It works, and has worked for me for a long time, but it's a hack.
oh, without a doubt. I kissed the earth when I found that IE 8 supported border-box, my point was just that there were hacks around the issue before now.
Not as badly as you might think! Playing around with the new box model on a test site and on the bootstrap site (via firebug), I only found four noticeable changes in appearance:
- The search form was noticeably shorter and more cramped. I fixed this by adding height: 100% to the interior text input element
- Text inputs are less wide than they should be when you use bootstrap's span classes
- The navbar's vertical and horizontal dividers disappeared. I fixed this by adding 1px of padding to either the side or bottom of the divider, as the case required.
Was I the only one that for some reason got a Youtube-video that all of a sudden popped up and started playing a short video about ESPN being hacked or something?
Might have been a glitch of some sort, but I'd suggest OP should check his source code to see if he hasn't been compromised of some sort.
omg hacked! Nah it's cool. I wired that up.
The unicorns konami trigger that was featured in the video was introduced by my blog so it's a bit of an homage or something. Thxthx.
Hey for some reason I can't add your Google Reader Frontend feed collections to my subscriptions. Clicking on the "Subscribe" buttons doesn't produce any result. Win XP and Chrome here.
I worked on a project recently where the previous designer did this and it was absolutely maddening. Switching the box model can be useful sometimes, but it makes no sense to me why you would do this globally.
The old microsoft box model was basically this one, but the implementation was so full of bugs that it ended up being "test and change until it shows the way you want".
The W3C box model spec forms a set of consistent rules that make sense. It's not the spec that's wrong. Just because it doesn't fit with your original intuition doesn't make it wrong.
It's not just an issue with intuition it simply makes it far harder to do many types of layout.
One of the biggest failings of the W3C model was that you could not combine a percentage width with fixed margin. If you wanted a fluid layout but which still incorporated consistent margins it was impossible to achieve without an entirely unnecessary nesting of divs.
Border-box completely eliminated this and poor old Microsoft (in this one instance) were forced to fall in with the less helpful "standard".
A spec that doesn't work the way most people think about the problem and that makes it harder to do what you want in a page layout is wrong more or less by default.
The W3C box model would only be useful if the W3C also provided a way to specify a width as "percentage of parent box width minus a fixed number of units" to compensate for the padding adding to the total width.
However, they did not, which means that in order to make a decent flowing layout, you have to change your document markup to insert artificial and otherwise unnecessary elements (DIV tags usually).
Thus the original model was flawed, did not make sense, and ultimately was not consistent with their own stated goals (separation of content and style).
[edit: FWIW petenixey said essentially the same thing, and what's really clever is that he said it first.]
I'm glad to hear that, but it's long overdue and the border-box model already solves the same problem with less markup (and most importantly, without creating an implicit dependency between the padding and width styles).
