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:

1
2
3
4
5
6
7

/* apply a natural box layout model to all elements, but allowing components to change */
html {
  box-sizing: border-box;
}
*, *:before, *:after {
  box-sizing: inherit;
}

Update August 2014: This code was updated to match new box-sizing best practices. Also prefixes are pretty much dead.

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 <= 28 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.com/#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.

Performance

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 you aren’t getting 90+ Page Speed scores, it’s 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.

Adjustments for Third Party Content

Any third party widgets add content directly into the page may need extra attention. Any widgets inside an iframe (like Disqus’s new theme) are naturally insulated from the parent page’s layout styles. If you need to make adjustments to the third party content you can apply box-sizing: content-box; to the widget and its descendants. This may not be trivial as form controls in particular are border-box by default, so you’ll also have to account for that.

This Wednesday, me and a ragtag team of like-minded developers launched Move the Web Forward, an initiative to direct people’s passions into productive efforts that assist not only the web community but the entire web platform. People often feel the need to “give back”, but when it comes to contributing it’s a challenge to find the right place. This is something I’ve seen happen firsthand in the jQuery and HTML5 Boilerplate communities.

The MWF effort was inspired by a tweet by WebKit extraordinaire Dimitri Glazkov.

Me and Divya started brainstorming on an etherpad. We rounded up some folks on Google+ and IRC and started collecting a lot of excellent resources. Soon after a design was in the making and we started working in an open repo on github…

At this point, I want to call out Mat Marquis aka @wilto, in particular, for really taking early ownership of this project and spearheading the design and frontend development. His efforts really made the site communicate its content effectively.

Naturally the site is on github if you’d like to contribute. We have a few issues open that we’ll be improving the site with. (Also, let me just say for projects like this, a cron job to pull latest from Github makes for such a relaxing workflow.)

Thanks to Divya, Mat, Aaron Forsander, Connor Montgomery, Stephanie Rewis (great writeup!), Nicolas Gallagher, Addy, and all these awesome folk. Truly a socially developed site; everyone collaborating on IRC, etherpad and github (with as many having commit rights as possible). Fun project to work on and I hope to see everyone find the right place for them to get more involved in actively making the web as awesome as you want it to be.

Beyond all the people who signed up (with the avatars) on the site to commit to things.. We’ve seen some moves in the community already:

• Ben Schwarz is joining the CSSWG to redesign how specs look and act
• Connor Montgomery, wrote up a patch regarding fullscreen support in Firefox
• Josh Adam is inspired to become better
• Alex Ball is going to contribute to BuddyPress
• Lots of folks in the accompanying Smashing Magazine article are ready to dig in.
• Colin Gourlay will be documenting what he learns more

\o\ \o/ /o/

While a lot of conversation has moved to twitter and G+, hugely useful information is still published regularly to blogs. I’ve shared collections of frontend development feeds twice before. Now I’m back, but with three choices:

Frontend development exploration, techniques, tips. Lots of JavaScript. 275 feeds.

Standards development and browser dev news. 56 feeds.

Blogs focusing on building large webapps (new!) 22 feeds.

Also, a short commentary on blogging vs tweeting.. while a lot of people have changed to twitter+jsfiddle only, tweets are not available via search after 30 days, so if you expect anything you share to last, blog it for real. :)

Also please subscribe to these guys which do a great job of highlighting the top stories of the week:

• JavaScript Weekly
• Web Design Weekly
• HTML5 Weekly