The Lodge is members-only design/dev videos and Office Hours.

Next Office Hours Session: "Programming Fundamentals" Dec 02 - 2:00 PM Eastern

Advanced Articles

Box Sizing

The box-sizing property can make building CSS layouts easier and a lot more intuitive. It's such a boon for developers that here at CSS-Tricks we observe International Box-Sizing Awareness Day in February.

But, how is it so helpful and beloved that it deserves its own internet holiday? Time for a little bit of CSS history.

Box Model History

Since the dawn of CSS, the box model has worked like this by default:

width + padding + border = actual visible/rendered width of an element's box

height + padding + border = actual visible/rendered height of an element's box

This can be a little counter-intuitive, since the width and height you set for an element both go out the window as soon as you start adding padding and borders to the element.

Back in the old days of web design, early versions of Internet Explorer (<= IE6) handled the box model differently when it was in "quirks mode". The "quirks" box model worked like this: width = actual visible/rendered width of an element's box height = actual visible/rendered height of an element's box The border and padding values were moved inside the element's box, cutting into the width/height of the box rather than expanding it.

The box at the top shows the default box model. The box at the bottom shows what was once the "quirks mode" interpretation of the box model.

Some people preferred this "quirky" interpretation of the box model and considered it more intuitive. It's a valid point. Having the actual visible width of a box turn out differently from what you declared in the CSS is a bit mind bending.

But, in the days of fixed-width design, it wasn't particularly complicated to work with the default box model once you understood it. You could do a bit of arithmetic to figure out how many pixels you needed to trim off of an element's declared width or height to accommodate its padding and border. The problem for present-day developers is that those absolute pixel lengths don't translate to responsive design, so the same math doesn't apply anymore.

As responsive design (or, as it was once known, "fluid" or "liquid" layout) started to gain popularity, developers and designers wished for an update to the box model. The great designer Jon Hicks, known for his excellent fluid width designs, had this to say on the subject in the CSS Wishlist we put together in 2008:

I would love a different box model! I find it bizarre that padding and border add the width of an object, and would love to be able to give something like a textarea 100% width and 3px padding without worrying what it’s going to do the layout. Perhaps something like padding-inside as a new selector?

In that vein I also wish I could specify a 100% width for an element, minus a set fixed width. Again, very useful when creating fluid designs with form elements!

Present-Day box-sizing

Those wishes were granted when the box-sizing property was introduced in CSS3. Though box-sizing has three possible values (content-box, padding-box, and border-box), the most popular value is border-box.

Today, the current versions of all browsers use the original "width or height + padding + border = actual width or height" box model. With box-sizing: border-box;, we can change the box model to what was once the "quirky" way, where an element's specified width and height aren't affected by padding or borders. This has proven so useful in responsive design that it's found its way into reset styles.

At this point you may be asking yourself, "Is it possible that Old IE did something right?" Plenty of people think so.


This demo shows how border-box can help make responsive layouts more manageable. The parent div's width is 50%, and it has 3 children with different widths, padding, and margins. Click the border-box button to get all the children in the right place inside the parent.

See the Pen Box Sizing Layout Demo by CSS-Tricks (@css-tricks) on CodePen.

Good, Better, and (Probably) Best box-sizing Reset Methods

The "Old" border-box Reset

The earliest box-sizing: border-box; reset looked like this:

* {
  box-sizing: border-box;

This works fairly well, but it leaves out pseudo elements, which can lead to some unexpected results. A revised reset that covers pseudo elements quickly emerged:

Universal Box Sizing

*, *:before, *:after {
  box-sizing: border-box;

This method selected pseudo elements as well, improving the normalizing effect of border-box. But, the * selector makes it difficult for developers to use content-box or padding-box elsewhere in the CSS. Which brings us to the current frontrunner for best practice:

Universal Box Sizing with Inheritance

html {
  box-sizing: border-box;
*, *:before, *:after {
  box-sizing: inherit;

This reset gives you more flexibility than its predecessors — you can use content-box or padding-box (where supported) at will, without worrying about a universal selector overriding your CSS. We went into more depth on this technique and the reasoning behind it in "Inheriting box-sizing Probably Slightly Better Best Practice". One potential gripe with it is that box-sizing isn't normally inherited, so it's specialized behavior, not quite the same as something you'd normally put in a reset.

Vendor Prefixes

Every current browser supports box-sizing: border-box; unprefixed, so the need for vendor prefixes is fading. But, if you need to support older versions of Safari (< 5.1), Chrome (< 10), and Firefox (< 29), you should include the prefixes -webkit and -moz, like this:

html {
  -webkit-box-sizing: border-box;
  -moz-box-sizing: border-box;
  box-sizing: border-box;
*, *:before, *:after {
  -webkit-box-sizing: inherit;
  -moz-box-sizing: inherit;
  box-sizing: inherit;

Known Issues

box-sizing: border-box; is supported in the current versions of all major browsers. The less-commonly used padding-box is only supported in Firefox at the moment. There's more comprehensive information about browser support in our box-sizing almanac entry.

There are a few issues with older versions of Internet Explorer (8 and older). IE 8 doesn't recognize border-box on elements with min/max-width or min/max-height (this used to affect Firefox too, but it was fixed in 2012). IE 7 and below do not recognize box-sizing at all, but there's a polyfill that can help.

Fix Inserted HTML5 Content with HTML5 innerShiv

When working with HTML5 today, many of you know that you'll need to include the "HTML5 shiv" to ensure that CSS will recognize and be able to style those elements in browsers that aren't yet hip to HTML5.

<!--[if IE]>
  <script src="//"></script>

Credit for that to Remy Sharp, Jon Neal, John Resig and anybody else who contributed to that idea. Also for the benefit of those non-hip browsers, it's best to reset many of the HTML5 elements to block-level as they should be:

article, aside, figure, footer, header, hgroup,
menu, nav, section { display: block; }

Now we're all set to use and style HTML5 elements. But wait! What happens if we dynamically add HTML5 to the page via JavaScript.

var s = document.createElement('div');
s.innerHTML = "<section>Hi!</section>";

Or in jQuery:


Hip browsers do fine, but Internet Explorer will once again not recognize the new element and not apply CSS to it.

Joe Bartlett has written a great work-around to the problem called HTML5 innerShiv and I thought more people should be aware of it.

Update January 2013: This is now included in the canonical html5shiv project, you should use that. The rest of this project is a bit outdated. You don't need to do it this way anymore if you use the html5shiv.

Using it

Please note that this script does not require jQuery. It's just vanilla JavaScript and will work with any library or library at all.

1. Download

Download the script and insert it onto your page. Or copy and paste the script into other JavaScript you are already loading if you want to avoid an extra HTTP Request.

2. Wrap all HTML content in innerShiv function before inserting

Here is the same jQuery example as above, made to work using innerShiv:


Quick demo.

Guidelines for URI Design

This is a guest post by Jacob Gillespie who started an interesting thread on Forrst about this topic. I invited him to post it here, to which he graciously accepted.

Over the past several years, I have taken an interest in usability and web design. One of the areas that seems to be often overlooked when it comes to design of a site is the design of the URIs on that site. Modern CMS systems allow for varying degrees of URI customization, but the defaults are often not as usable as they could be, and URIs are often placed last in the design process.

Clean URIs are one component of a clean website, and it is an important one. The majority of end-user access to the Internet involves a URI, and whether or not the user actually enters the URI, they are working with one nonetheless.

First, I would like to talk about the guiding principles behind URI design, then talk about the practical implementation of the principles.


Understanding border-image

The new CSS3 property border-image is a little tricky, but it can allow you to create flexible boxes with custom borders (or drop shadows, if that's your thing) with a single div and a single image. In this article I explain how the border-image shorthand property works in today's browsers.


CSS Content

CSS has a property called content. It can only be used with the pseudo elements :after and :before. It is written like a pseudo selector (with the colon), but it's called a pseudo element because it's not actually selecting anything that exists on the page but adding something new to the page. This is what it looks like:

.email-address:before {
   content: "Email address: ";

With this CSS in place, we could have this HTML:

   <li class="email-address"></li>

And the output would be like:

• Email address:

Maybe that example doesn't get you drooling, but pseduo element content can be quite useful and do cool things. Let's go through some ideas and considerations.


Rendering CSS

I admittedly don't think about this idea very often... how efficient is the CSS that we write, in terms of how quickly the browser can render it?

This is definitely something that browser vendors care about (the faster pages load the happier people are using their products). Mozilla has an article about best practices. Google is also always on a crusade to make the web faster. They also have an article about it.

Let's cover some of the big ideas they present, and then discuss the practicalities of it all.


Pointer Events & Disabling Current Page Links

It is a long-standing web design standard that the logo in the header area links to the homepage of the site. Another standard is that when displaying the navigation of a site, to highlight in some way the "current" page, if it is present in the navigation. I think those are great standards. The logo-link thing is so ubiquitous that your users will likely automatically try it if you've coded it that way or not. The current navigation thing is just good ol' horse-sense for grounding a users and making them feel good about their current location in a websites hierarchy.

But here is another good design standard: don't have links to the same page you are on, on that page.

The idea here is twofold:

  1. When you see a link, it looks like a link, it behaves like a link, that says "click this and be taken elsewhere." If the link takes you back to the same page you are on, that's kinda weird.
  2. It is a waste of server resources to reload a page for no reason.

How can you accomplish this without a bunch of development work and changing markup? CSS of course!


More than one way… (delegate edition)

There was a question in the forums about affecting non-hovered items. The effect they were after is that they had an unordered list of items and when they were rolled over, they would all dim (lower opacity) except the one hovered.

This can be done with CSS, using pseduo-selectors.

ul li:not(:hover) { opacity: 0.5; }

However we know that pseudo-selectors don't have very good cross-browser support. And for that matter, opacity doesn't either. jQuery is pretty good at mitigating cross-browser problems, so l thought I might give that a spin. In attempting it, I had a nice little learning journey.


Data URIs

Did you know that you don't have to link to an external image file when using an <img> element in HTML, or declaring a background-image in CSS? You can embed the image data directly into the document with data URIs.

With CSS, it looks like this:

li {
    left center;
  padding: 5px 0 5px 25px;

With HTML, it looks like this:


The format, to be specific:

data:[<mime type>][;charset=<charset>][;base64],<encoded data></encoded></charset></mime>

Basically, a super long string of gibberish characters. It's not gibberish to the browser though of course. This data is interpreted as the type of file you are saying it is.

You can see a really dumb demo page here. I'll be covering the important parts next.


There's a whole bunch of content on CSS-Tricks.

Search for Stuff   •   Browse the Archives

Get the Newsletter ... or get the RSS feed