Home > front-end development > * { box-sizing: border-box } FTW

* { box-sizing: border-box } FTW

February 1st, 2012

One of my least favorite parts about layout with CSS is the relationship of width and padding. You're busy defining widths to match your grid or general column proportions, then down the line you start to add in text, which necessitates defining padding for those boxes. And 'lo and behold, you now are subtracting pixels from your original width so the box doesn't expand.

Ugh. If I say the width is 200px, gosh darn it, it's gonna be a 200px wide box even if I have 20px of padding. So as you know, this is NOT how the box model has worked for the past ten years. Wikipedia has a great history of this box model. Jeff Kaufman also dove into the history

Anyway, I have a recommendation for your CSS going forward:

/* apply a natural box layout model to all elements */
* { -moz-box-sizing: border-box; -webkit-box-sizing: border-box; box-sizing: border-box; }

This gives you the box model you want. Applies it to all elements. Turns out many browsers already use border-box for a lot of form elements (which is why inputs and textareas look diff at width:100%;) But applying this to all elements is safe and wise.

Browser support

Due to browser support, this recommendation is only for projects that support IE8 and up. (Full browser compat at MDN) Firefox still needs the -moz- prefix, and <= iOS4, Android <= 2.3 need the -webkit-, but everyone else uses the unprefixed. You can find more info about a box-sizing polyfill for IE6 & 7 at html5please.us/#box-sizing (which was developed with * { box-sizing: border-box!).

Is it safe to use?

Totally. jQuery works pretty great with it (except this). As mentioned, browser support is excellent. And a number of projects use this layout model by default, including the WebKit Web Inspector (aka Chrome DevTools). I heard from Dutch front-end developer Yathura Thorn on his experience:

We've been using *{box-sizing: border-box;} in one of my projects (deployed in production, averaging over 1mln visits a month) at work for about a year now, and it seems to be holding up just fine. The project has been tested in IE8 & 9 and the latests Firefox and Chrome versions and we've had no problems. All jQuery (+UI) offset calculations and animations run fine, even in any element we've displayed as inline-block. As of late we've started testing the project on mobile devices (iPhone, iPad and Android) and we've had no issues regarding box-sizing with any of them yet, so it seems to work just fine.

One of my favorite use-cases that border-box solves well is columns. I might want to divide up my grid with 50% or 20% columns, but want to add padding via px or em. Without CSS's upcoming calc() this is impossible... unless you use border-box. So easy. :) Another good one is applying 100% width and then wanting to add a padding to that element.


Lastly on @miketaylr's inquiry, I also tested perf overhead. Anecdotal evidence suggests border-box isn't significant.

You might get up in arms about the universal * selector. Apparently you've heard its slow. Firstly, it's not. It is as fast as h1 as a selector. It can be slow when you specifically use it like .foo > *, so don't do that. Aside from that, you are not allowed to care about the performance of * unless you concatenate all your javascript, have it at the bottom, minify your css and js, gzip all your assets, and losslessly compress all your images. If aren't getting 90+ Page Speed scores, its way too early to be thinking about selector optimization. See also: CSS Selector Performance has changed! (For the better) by Nicole Sullivan.

So... enjoy and hope you'll find this a far more natural layout model.

02.01.2012: Added a section on performance

2012.02.03: Included webkit prefixed property and usecase of a 100% width box.

2012.02.22: Added link to Jeff Kaufman's history page.

front-end development

  1. February 1st, 2012 at 09:19 #1

    Just curious if you've done any performance testing? I know Opera has a CSS profiler, but I haven't fired it up yet.

  2. February 1st, 2012 at 09:20 #2

    So happy to hear this being advocated by a premiere developer. I've been complaining about CSS's box model since making the switch from table-based design back in the late 90s. Ending up having to set your 600px-wide column to 587px or whatnot to account for borders and padding is highly annoying and can make going back through the CSS time-consuming. I'm definitely looking forward to using the new box-sizing options on my future projects that don't need to be backward compatible with legacy browsers.

  3. February 1st, 2012 at 09:23 #3

    On Quirksmode.org, it says this: "No browser supports box-sizing in combination with min- or max- width or height."

    This statement is baffling and I haven't ever really tested it. It doesn't intuitively make sense why min- or max- width would be prohibited, but do you know anything about this, Paul?

  4. February 1st, 2012 at 09:25 #4

    Nice article Paul, definitely a feature I will begin to implement in my projects. It may be hard trying to learn a correct box-model though…

  5. Luke Browell
    February 1st, 2012 at 09:26 #5

    true this has been around a while, but I've always avoided it in production due to the apparent dearth of test cases in the wild.

  6. February 1st, 2012 at 09:30 #6

    Interesting idea as old browsers die… and to think we made IE fix their box model. Maybe we should have lobbied the W3C to change their box model instead. I hear this frustration from devs all the time.

    If we could use conditional comments on a doctype, we could let old IE use doctype switching and render the old box model in quirks and use border-box for newer browsers. But that would put everybody into quirks (if I recall correctly)…

  7. February 1st, 2012 at 09:33 #7

    If you put a comment or anything above the DTD then it'll throw IE6 into quirksmode, which will make things work in IE6 as well.
    As a side note, I'm pretty sure you need to add the -webkit- prefix for iOS.

  8. February 1st, 2012 at 09:38 #8

    @Thierry Not just in IE6 — comments before the DOCTYPE trigger quirks mode in IE7, IE8 and IE9 as well.

    Unfortunately quirks mode may have other side effects. Here’s a list of things that work differently when quirks mode is triggered in Gecko. Are you sure none of these (other than the different box model) apply to IE?

  9. February 1st, 2012 at 09:39 #9

    I was just popping by to say what Thierry just did. According to http://caniuse.com/css3-boxsizing you still need the -webkit- prefix for iOS. I don't think it'd be a bad idea for older Safari as well.

  10. February 1st, 2012 at 09:40 #10

    @Mathias In all IE? I didn't recall that. Is the xml prolog an exception or does it trigger QM across the board too? Regarding differences, there are plenty, but the suggestion worth it if we're only "fixing" IE6 as it would be better to deal with QM issues in that browser rather than having a totally broken layout (imho). One of the many issue I recall is that IE in QM will obey this rule:
    element {font:20px;}
    instead of ignoring it because of the lack of font-family

  11. February 1st, 2012 at 09:41 #11

    Pleasantly surprised that you support this idea.
    Never dare to use box-sizing like that. I have so the habit of recalculate widths without paddings.
    But why not try on a next project!

  12. February 1st, 2012 at 09:43 #12

    I'm a big fan of this technique and have been using it in a number of mobile web apps (and increasingly) website projects. Its a really welcome way to create a sensible baseline to work from for cross platform development.

  13. February 1st, 2012 at 09:52 #13

    Time to find out which iOS still uses prefixed. I imagine it's pre iOS 5, but we can verify…

  14. Justin
    February 1st, 2012 at 09:55 #14

    I'm also a fan of changing box-sizing—to an extent. I think it's only appropriate with fluid applications since percentage widths generate unpredictable sizes.

    Changing all elements would only be repeating your objection to the box model in reverse. Now you have to account for the math on the _inside_ of the element. This is in many ways harder to keep track of because there's no longer a value in your stylesheet that displays the width. Want an image that's the same size as the content width of the wrapper? Now you have to subtract the padding/margins/borders from the width—instead of just using the width.

  15. Derek Watson
    February 1st, 2012 at 09:57 #15

    This seems like a buggy and highly unconventional solution to a simple problem. Instead, put your width on a container elements and padding on child elements. You'll find it works perfectly in all cases and you won't have to explain yourself at length to other developers on the project.

  16. February 1st, 2012 at 09:59 #16

    Webkit changeset 71348 (thanks peter beverloo!) removed the prefix.. It happened 15 months ago and dropped into Webkit Version 534.12. This means it's in iOS5, but iOS4 still uses the prefixed one.

  17. February 1st, 2012 at 09:59 #17

    For anyone using SASS, I wrote a SASS/Compass border-box polyfill that takes your values and outputs equivalent CSS for IE6 & 7. Take a look if you're looking for a non-JavaScript alternative.


  18. February 1st, 2012 at 10:07 #18

    Or just use margins on the inner elements instead of using padding on the container. Allows for more flexibility too. I rarely use padding, only if I need to reserve space for icons and such.

  19. February 1st, 2012 at 10:13 #19

    box-sizing: border-box is the bee's knees.

  20. Gavin Smith
    February 1st, 2012 at 10:22 #20

    @Derek Watson
    Sometimes there's no way to add a child element to apply padding to that isn't otherwise completely unnecessary. What's the bigger evil, playing the CSS gods with new but fairly well supported box model adjustments or unnecessary markup?

    I say the latter. By a long shot.

  21. February 1st, 2012 at 10:37 #21

    @Derek – I disagree that it's buggy or highly unconventional. Box-sizing as a property has been around for a long time, and is stable enough that it's now (mostly) non-prefixed. And look, a LOT of us have hated the W3C box model from day 1 and found it completely unintuitive. I've been waiting for IE7 numbers to drop enough to start using it. So it's a completely conventional and legit solution. It makes CSS easier to work with. And with the behavior polyfill, maybe now's the time.

  22. Fyrd
    February 1st, 2012 at 10:41 #22

    Yeah, I incorrectly had the caniuse value for iOS Safari 5 requiring the prefix, but fixed it now. :)

  23. February 1st, 2012 at 10:58 #23

    I ran into an issue yesterday on iPad1 related to box-sizing, hence why I knew about the prefix issue. I learned the hard way… as usual ;)

    Regarding what we used to call the "broken box model", I think the issue is that you do not own the content box and any change in border or padding impacts that content area. I understand that it can be easier for people to style boxes that way, but it's not a magic wand, you end up dealing with different issues.

    For example, if you style a nested container using something like "width:50%" does it makes sense to you that what you get is *not* 50% of the width of the parent box?

  24. February 1st, 2012 at 11:16 #24

    box-sizing: border-box; can help with a lot of odd issues you run into when working on fluid/flexible layouts. @Richard Herrera – I'm interested to check out your SASS polyfill for IE7/6. My worry in using it has been on older mobile devices that don't support it, though I admit, there are probably other more pressing issues on older mobiles. For the time being, I've been using border-box on a few responsive sites with good results.

  25. Collin Miller
    February 1st, 2012 at 11:16 #25

    Hey Paul, thanks for the tip. I've been struggling with this lately and didn't know just how compatible this is.


  26. Steve Davis
    February 1st, 2012 at 11:24 #26

    Nice. I'd ask you to add it to the HTML5 BP, but if it doesn't work for IE7 and below, we can wait.

  27. Mitch Malone
    February 1st, 2012 at 11:26 #27

    If you add padding to the child elements, the layout won't get all wonky (assuming you're floating divs). Haven't played with box-sizing stuff but it looks intriguing.

  28. February 1st, 2012 at 11:33 #28

    Hey Paul,

    Looking at the head of paulirish.com you have

    No moz in there. Should it be?

    Does using an * in the CSS replace this?

  29. February 1st, 2012 at 11:36 #29

    I've been developing sites with box-sizing set to border-box for a couple of years now, and I love it. I include it in the reset of our base project template, github.com/stephband/template.

    The principal problem to watch out for is using it in conjunction with min-/max-width and min-/max-height. Generally, in webkit it behaves as expected, but some other browsers still treat these properties as content-box properties, amongst other weirdness. See, for example, FF has problems with min/max-height:


    These are minor issues if you're aware of them. The other problem is IE7 support, but I have a tendency to hack IE7 with it's own stylesheet towards the end of a project, and I don't have any qualms about fixing sizes for an otherwise flexible website for that browser.

  30. cwebba1
    February 1st, 2012 at 11:55 #30

    Thank you Paul Irish. I'd like to know how does one turn box-sizing: border-box; off? As you may know, doing percentage math for responsive with list elements and padding gets mind-numbing. What I found, working from mobile on up, is that I was unable to turn it off and go back. I had to contain the box-sizing: border-box; declaration into an @query with a min/max declaration. How does one un-border-box?

  31. February 1st, 2012 at 12:01 #31


    .unborderbox { box-sizing: content-box; }
  32. February 1st, 2012 at 12:02 #32

    @thierrykoblentz And then there's the issue where images behave as blocks, rather than as inline-blocks. I played with the idea of triggering Quirks Mode when I started using border-box a couple of years ago, and quickly dismissed it because of the other rendering issues it introduces, and because of changes to the JavaScript DOM.

  33. February 1st, 2012 at 12:14 #33

    @stephband "Images behave as block"? I don't recall that at all. That would be true for IE5 too then and I don't recall that either… Are you 100% sure? And under what condition did that happen? I cannot believe QM alone triggers that.

  34. February 1st, 2012 at 12:26 #35

    Great, gonna use this on future projects.

    And, +1 for "If aren't getting 90+ Page Speed scores, its way too early to be thinking about selector optimization"

  35. February 1st, 2012 at 12:39 #36

    @thierrykoblentz Yeah, no baseline space underneath them. It's a couple of years since I tested so not 100% – but it's documented here: http://www.quirksmode.org/css/quirksmode.html

  36. Jacob Rask
    February 1st, 2012 at 13:17 #37

    Apart from box-sizing, for quick prototyping I sometimes also add * { position: relative; }.

  37. February 1st, 2012 at 13:58 #38

    @cwebba1 You can "go back" to the default W3C box model by overriding the * rule with "box-sizing: content-box"

  38. gri3fon
    February 1st, 2012 at 17:12 #39

    sorry, can't help this but could you, please, add a bit more space at the bottom to play with or may be include a reset button?


  39. Binyamin
    February 1st, 2012 at 22:18 #40

    None can argument, that using the right parameter for right selector, like `.compact-box { box-sizing: border-box; }`, would perform the best result. Avoiding universal selector will just have improve your CSS.

    IE7 has buggy CSS universal selector support http://reference.sitepoint.com/css/universalselector#compatibilitysection , but even so it has no native CSS parameter `box-sizing` support.

  40. February 1st, 2012 at 22:26 #41

    This made my week! I've been itching to go scorched-earth on the old box model and your endorsement of

    box-sizing: border-box;

    is all the convincing I need to never look back. Let's move that web forward!

  41. Declan
    February 1st, 2012 at 23:11 #42

    How haven't I heard of this! This is great! sass has been handy in the past for me to overcome the issue. I've always thought it was the stupidest thing ever, and +1 on using it for padding + % widths! Plans to incorporate into Boilerplate at all? I think it might be going into mine.

  42. Richard Ayotte
    February 2nd, 2012 at 01:46 #43

    The lack of layout features in CSS 2 is the problem, not the box model. When CSS 3 Template Layout, Flexible Box Layout, Multi-column Layout or Grid Layout modules are widely supported this won't be an issue. I don't think switching box models in the interim is a good idea though. Learning a new behaviour can be time consuming and frustrating. I would use border-box for specific elements when needed instead. IE is the hold up again… Maybe an IE boycott/blackout should be organized. It was done for SOPA, why not for IE ;) It wouldn't be total blackout. Only a blackout if you're using IE.

  43. February 2nd, 2012 at 01:48 #44

    Great article. I shed a little tear every time I read such an article as in my company we still have to support IE6. I would love if we could wipe peoples memory of IE6 using a normalizer, MIB style. It would make developers life far easier. Hoohum….

  44. Felix
    February 2nd, 2012 at 02:53 #45

    @Thierry Koblentz
    Yepp, had do do this. Tested in iOS 4.1.

  45. February 2nd, 2012 at 05:09 #46

    Cheers Paul !!!
    This is easy and clear. I'm going to apply this on future projects :)

  46. February 2nd, 2012 at 05:32 #47

    Well done

  47. Justin
    February 2nd, 2012 at 06:38 #48

    @Thierry Koblentz

    Thank you. That's was another very important negative implication I forgot to mention.

  48. February 2nd, 2012 at 06:49 #49

    I've always said that the box model was jacked. In the real world, a box doesn't get BIGGER if you put something inside it.

  49. February 2nd, 2012 at 06:55 #50

    I think, box-sizing is one of the overrated features of CSS3. I never use and I (probably) never will use it!

  50. Ward
    February 2nd, 2012 at 08:40 #51

    Hey! This website gets a 56 on page speed! lol Joking aside, at the end, when you said "…minify your css and js, gzip all your assets, and losslessly compress all your images" did you mean "lossily"? You know, the good ole jpg action?

  51. February 2nd, 2012 at 16:58 #52

    Funny, a few years back, this was one of the things I recommended to Sencha for ExtJS4. Since they had some of their own layout stuff going on, they had the typical "redundant layout" problem going on — they would size some things and then get sizes recursively. I convinced them to change a few things, this being one of them (you can look up the SenchaCon conference materials from 2010). It eliminated having to ask the browser for the real width of things.

    PS: You didn't mention the backstory of how IE always did things this way and the W3C changed it to make IE not standards compliant. A long time ago, I guess. Sorta spiteful, but we are only human!

  52. February 3rd, 2012 at 03:15 #53

    What about performance for IE<8 with the behaviour attached? Is it really bad?

  53. February 3rd, 2012 at 06:52 #54

    I've also written simple Javascript (instead of the htc behaviour) as polyfill for old IE

  54. fpiat
    February 3rd, 2012 at 07:20 #55

    Not a direct link to this post: the color you use for the text make it really hard to read for someone like me whose eyes are not so good. The size of the typo is also very small and I must ctrl + several times. (:-((

  55. February 3rd, 2012 at 08:09 #56

    I asked Ricardo, who wrote the polyfill, and he had good things to say about its performance. So, I'd just recommend you to test it out. :)

  56. cnwtx
    February 3rd, 2012 at 09:02 #57

    @Jacob Rask, setting everything to position:relative will also happen to very nicely crash IE6, which may or may not be a bad thing. :)

  57. Chris
    February 3rd, 2012 at 09:11 #58

    The Android browser, at least in Gingerbread, requires -webkit-box-sizing for this to work too.

  58. February 3rd, 2012 at 15:42 #59

    "Not just in IE6 — comments before the DOCTYPE trigger quirks mode in IE7, IE8 and IE9 as well."
    @Mathias But you can use X-UA-Compatible to force IE8 or later standard mode even without a DOCTYPE.

  59. February 3rd, 2012 at 16:53 #60

    Oh, you think you're a smart guy, huh? Well, what do you do with this:



    (Even the random JSBin-generated URL calls it a "bug"!)

    In all seriousness, I'm almost prone to think that this is why the "wrong" box model was preferred by browsers all these years.

  60. Christian Augustin
    February 4th, 2012 at 00:15 #61

    @Yuhong Bao: Have you actually tried and verified that it works with IE8? My experiences with IE8, Conditional Comments around "head" and X-UA-Compatible suggest another behavior, but it may work with a comment before the DOCTYPE declaration …

  61. February 4th, 2012 at 14:48 #62

    i've always just 'double-wrapped' my divs — it's tedious but bulletproof:

  62. February 4th, 2012 at 14:49 #63

    i've always just 'double-wrapped' my divs — it's tedious but bulletproof:

  63. February 4th, 2012 at 14:50 #64

    (sorry — comments #fail )

    i've always just 'double-wrapped' my divs — it's tedious but bulletproof:

      [div style="width:50%"][div style="padding:10px"]
      [div style="width:50%"][div style="padding:10px"]
  64. February 5th, 2012 at 14:37 #65

    This does break some third-party widgets like Disqus, since they add styles that assume the default box model. Of course we can solve that by using greater selectivity to bring back box-sizing: content-box within specific contexts — not ideal for maintainability, but then neither is the default box model. :)

  65. February 6th, 2012 at 05:50 #66


    You would be far better just doing

    box-sizing: content-box;

    And adding that class to the containers. Much easier to maintain.

  66. February 6th, 2012 at 06:03 #67

    A new day, a new lesson. Thanks Paul for the this article and for the http://html5please.us/#box-sizing I din't know this site.

  67. Mike
    February 6th, 2012 at 06:57 #68

    Don't know what you are talking about.
    See: http://jsbin.com/odebug/4/edit#html,live
    The problem is you set height. Change it to min-height, or remove it (also add some padding to the bottom).

  68. February 6th, 2012 at 07:52 #69

    Box-sizing saves us I am tired of using calculator while styling :) Thx paul !!

  69. February 7th, 2012 at 00:31 #70


    True, and with a height like that, it's not an extremely realistic situation. Maybe this will illustrate better what I was trying to show:


    No height, but with unusually high padding values, again causing the inner element to break out of its container. And again, not realistic, but just illustrating what almost feels like a weakness in that type of box model.

    I'm not saying this is a real problem, I'm just wondering if maybe this is why the standard box model was preferred. For practicality, the border-box method is best, but theoretically, the standard method works better in any situation.

  70. fireh
    February 7th, 2012 at 14:01 #71

    Well if you're building an application you would want to constraint your content to a predetermined layout down to the pixel, chances are you also use 12px font and 10px font.
    If it is a content based, you would want your content to determined the layout and use large font so it is easier to read.

  71. February 7th, 2012 at 16:32 #72

    Im looking to fix all known bugs with border-box in jquery in version 1.8. I've been saying for a while that all signs point to wide adoption of border-box, especially on mobile. If anyone here is using border-box and jquery and finds a bug please file it at: http://bugs.jquery.com Thanks!

  72. February 7th, 2012 at 20:14 #73

    This post has just made my life so much easier, works a treat with dealing with inputs and textareas, which otherwise are quite a hassle. I'm bookmarking your blog!

  73. February 8th, 2012 at 06:39 #74

    Like your post.. LOVE your background!

  74. February 8th, 2012 at 08:22 #75

    Thanks Paul!

    I'm new to CSS and was getting frustrated with the common box model – it just didn't make sense to me. This will simplify my life!

  75. David Grahm
    February 8th, 2012 at 15:28 #76

    You can't expect people to take this seriously when saying border-box usage is safe and wise, followed up by it not being supported below IE8. The majority just doesn't have the luxery to drop that browser range for years to come.

  76. Mr C
    February 8th, 2012 at 17:48 #77

    great tip, but non-square images with border / padding / margin appear to lose aspect ratio. presumably the same will happen to video too.

    would this be a sensible tweak?

    *:not(img,video) { }

  77. Larry Gerndt
    February 8th, 2012 at 20:30 #78

    I took this post to heart, it resonates as a simple way to make life easier

  78. Peter van Grieken
    February 9th, 2012 at 13:53 #79

    So, did anyone test PPK's remark about this?

    "box-sizing does not work in combination with min- or max-width or -height."

    - http://www.quirksmode.org/css/box.html

  79. February 10th, 2012 at 00:32 #80

    Putting this to the test 'in the wild' next week.
    Have been testing out on an 'adaptive' layout last couple of days on:
    desktop, iphone, ipad, small android.
    So far so cool!
    of interested > http://www.booniesfootwear.co.nz

  80. February 10th, 2012 at 00:34 #81
  81. February 13th, 2012 at 11:22 #82

    The development of technology. We did not catch it.

  82. Stefan Melnychenko
    February 15th, 2012 at 07:06 #83

    Brilliant Paul. I've been frustrated with this since the start. Can't wait to try it out!

  83. February 15th, 2012 at 20:13 #84

    Just linking up Chris Coyier's great post on his experience with this and applying * to other properties:

  84. February 16th, 2012 at 08:00 #85

    @Louis Comment out "height: 200px;" and it's fine.

  85. February 16th, 2012 at 09:08 #86

    Interesting that Internet Explorer got this one right on the first try.

  86. February 16th, 2012 at 09:26 #87

    Cool article, but I think it could use more live demos!

  87. February 16th, 2012 at 11:31 #88

    You know what else works in IE8+ and all other modern browsers?


    Shave a few kilobytes off your JS includes by dropping the selector engine out of jQuery- huge win if your target browsers are in this sweet spot.

  88. February 16th, 2012 at 12:29 #89

    Oh thank god, finally! No more container divs with padding!

  89. Oce
    February 16th, 2012 at 13:19 #90

    Awesomeness! Will experiment with use with min/max-width in different browser. Thanks!

  90. February 16th, 2012 at 16:56 #91

    For those using Compass/SASS:

    @import "compass/css3/box-sizing"
    * { @include box-sizing(border-box); }

  91. February 16th, 2012 at 17:10 #92

    @David Graham, did you miss the part about the fallback for IE6/IE7? You CAN use this today.

  92. February 17th, 2012 at 03:19 #93

    Not only is this a good prospect for seasoned developers, but it removes a complexity that stumps many a new comer.

  93. February 17th, 2012 at 06:51 #94

    "I might want to divide up my grid with 50% or 20% columns, but want to add padding via px or em."

    This is why I never end up using percentages for widths, even when they make SO much sense. Every time I try to use a percentage, padding mucks it up and I have to move to pixels.

    Time to try it again. Thanks!

  94. Ufuk Kayserilioglu
    February 17th, 2012 at 09:11 #95

    So the Internet Explorer box-model bug [1] was not a bug but a feature? :)

    [1] http://en.wikipedia.org/wiki/Internet_Explorer_box_model_bug

  95. Adam
    February 17th, 2012 at 11:36 #96

    @Dan Linn
    The author writes that you don't need to worry about universal * selector performance, but if you're in an environment where IE6 is still used then you should worry. In pages with large tables (lots of DOM nodes), the * selector can slow things quite a bit. As I remember it may have been a factor of 10 difference in some cases. Thankfully I don't have to worry about IE6 in my current job — hopefully you can say the same.

  96. February 19th, 2012 at 11:09 #97

    I see a little issue with changing the box-sizing property though. If you're designing a site that will support plugins or external widgets, it may break their appearance as they may not have been intended to have such property.

    I suppose this could be fixed by strictly determining where will external markup go, but still…

  97. Tom
    February 21st, 2012 at 06:17 #98

    Haha, your note on performance made me giggle :)

  98. February 21st, 2012 at 13:23 #99

    In both ExtJS 4+ and Sencha Touch 2+ we have been using box-sizing: border-box. It greatly simplifies your CSS, layouts and many of the calculations we had to do in JavaScript before. Glad to see others are starting to see the benefits of this.

  99. February 22nd, 2012 at 10:01 #100

    Thank you for this article! I had never thought about about it in the way that you discussed that if a box has a specified width, that the width shouldn't change just because we add padding. It's very true!

    I will definitely be using this technique in the future.

  100. paul
    February 22nd, 2012 at 18:10 #101

    I've been wanting to use border-box for a few years now and have only used it in 1 or 2 projects where IE6&7 support wasn't an issue. I just can't wait to finally drop support for IE7!

  101. February 23rd, 2012 at 00:39 #102

    Thumb up, I was just having this thought now :D

  102. February 23rd, 2012 at 01:23 #103

    When defining widths in percentages, in general it makes sense to define paddings in percentages as well. But using the border-box model is a great solution for borders which sadly cannot be defined in percentages.

For code blocks, use <pre lang="javascript">. css and html4strict are also accepted.