I’ve put a demo on Github where you can also see the source code.

Two columns, both with solid colours

background: #fff url(css3faux-i/cols.png);
background-image: -o-linear-gradient(left, #fff 639px, #bed751 640px);
background-image: -moz-linear-gradient(left, #fff 639px, #bed751 640px);
background-image: -webkit-linear-gradient(left, #fff 639px, #bed751 640px);
background-image: -ms-linear-gradient(left, #fff 639px, #bed751 640px);
background-image: linear-gradient(left, #fff 639px, #bed751 640px);

Two columns, with a one pixel divider

background: #fff url(css3faux-i/div.png);
background-image: -o-linear-gradient(left, #fff 639px, #bed751 640px, #fff 641px);
background-image: -moz-linear-gradient(left, #fff 639px, #bed751 640px, #fff 641px);
background-image: -webkit-linear-gradient(left, #fff 639px, #bed751 640px, #fff 641px);
background-image: -ms-linear-gradient(left, #fff 639px, #bed751 640px, #fff 641px);
background-image: linear-gradient(left, #fff 639px, #bed751 640px, #fff 641px);

Two columns, one with a gradient

background: #fff url(css3faux-i/gradient.png);
background-image: -o-linear-gradient(left, #fff 639px, #bed751 640px, #efffa5 100%);
background-image: -moz-linear-gradient(left, #fff 639px, #bed751 640px, #efffa5 100%);
background-image: -webkit-linear-gradient(left, #fff 639px, #bed751 640px, #efffa5 100%);
background-image: -ms-linear-gradient(left, #fff 639px, #bed751 640px, #efffa5 100%);
background-image: linear-gradient(left, #fff 639px, #bed751 640px, #efffa5 100%);

For a few sites, we used Paul Irish’s conditional HTML classes hacks. Without workarounds, this puts IE in compatibility mode.

Recently, we decided to go back to attribute hacks.

Using LESS CSS and compiling with less.app, it’s possible to store the hacks in a single location and remove them once the browsers die.

The hacks we use are:

/* IE6 */
#something {
  _color: blue;
}

/* IE6, IE7 */
#something {
  *color: blue;
}

Around the time we switched, Mathias Bynens wrote a post detailing much the same conclusions we reached. I won’t rehash them here.

Excuse the dull and highly unfashionable post. It’s main purpose is so we can go to bigredtin.com/iehacks when memory fails us. We use this blog a resource.

The cause – but not the fault – lays with Eric Meyer’s original CSS reset, subsequently included in the YUI CSS framework, among others.

Eric warned that he didn’t “recommend that you just use this in its unaltered state” but people did so anyway. Including the code:

:focus {
  outline: 0;
}

The problem became so widespread that Eric has apologised for it, even though it wasn’t his fault people ignored his advice! In the second version of his reset, he removed the code above.

At Soupgiant, we take a two-fold approach to link focus styles. We leave the outline in place because users have come to expect it. To increase the contrast of focused links further, we reverse the foreground and background colours too.

a:link, a:visited {
  color: #00f;
  background: transparent;
  text-decoration: underline;
}
a:focus {
  color: #fff;
  background: #00f;
  text-decoration: none;
}
a:hover, a:active {
  color: #00f;
  background: transparent;
  text-decoration: none;
}

While it seems we are doubling up on some code, it’s a necessary evil as multiple pseudo-classes can be applied to single a link at once (for example: :hover and :focus).

For the cost of a few extra bytes, we believe it adds significantly to the usability of our sites. For that reason, we’ve included it in Minimum Page: our reset-free, CSS starting point.

Minimum Page comes from a frustration with CSS resets and bases. Ripping down the styling only to rebuild many of the same styles is unnecessary, especially for defaults common to all browsers.

To encourage people to consider the code they insert in their site, the styles aren’t provided in a minimised form. Developers should edit the original base to make generic, site wide changes.

It’s exactly what we use to start all of our CSS at Soupgiant. We think it’s important to share.

• Find out more
• View on github

#nav {
  float: none !important;
  /* where did I float this? */
}
/* ...jumble of code... */
ul#nav {
    float: left;
}

There are, however, instances where the !important declaration is the best tool for the job.

Responsive Web

The increase of users accessing web sites via mobile devices has redefined the way many design for the web. Rather than considering the desktop first, they now consider the mobile user. Andy Clarke’s 320 and Up is one reaction to this.

A requirement of the responsive web is that images expand and contract according to the width of the browser. To achieve this, the advice to define the width and height in the HTML has been reversed, an image should now be added without these attributes.

<img src="img.png" width="30" height="30" />

This leads to problems when redesigning a site, images in previous blog posts and older content could have the width and height defined. If the site uses a CMS with a visual editor, it may add the dimension to an image by default and content editors may unwittingly break the layout by leaving them in place.

To allow for this, I usually add the following to the CSS

img {
  height: auto !important;
  max-width: 100% !important;
}

Print Styles

There are certain elements that are almost always hidden from print styles: skip links, navigation, and oversized footers, for example. Backgrounds are also removed as they’re not printed by default. Changes to the screen layout won’t alter these needs. To avoid future problems, it is legitimate to include the following in your style sheet:

@media print {
  #nav, #footer, .sidebar {
    display: none !important;
  }
  .has-a-background {
    background: #fff !important;
  }
}

Leave a comment with your thoughts if you frequently use !important for other purposes, agree or disagree.

Update 16 Nov, 2011: changed img code block.

Currently, web development is undergoing some major transitions: the HTML5 spec is being developed and CSS3 is being implemented. The browser wars have returned, although this time around, it’s a battle to win developers’ hearts by implementing the newest standards.

Now is the time for developers to re-evaluate their past practices; moving on from the old and embracing the new. I kept that ethos in mind when upgrading the Soupgiant WordPress base theme recently. Among other things we were porting it to HTML5.

I really tried to adopt the commonly advocated view that it’s okay to require website visitors have JavaScript enabled. It was going very well, right up to the final hurdle when I couldn’t resist checking the site I was working on without JavaScript.

Everything looked fine in Chrome, Firefox, and Opera. It was, predictably, Internet Explorer that threw a spanner in the works. For an artist’s impression, visit the demo in IE8 (screenshot via WebPageTest):

HTML5 as seen in IE8

Without Remy Sharp’s HTML5 enabling script the site I was working on was unusable, if anything, it looked worse than the demo provided.

I couldn’t, in good faith, sell a website to a client that some visitors would find unstyled, half styled or difficult to follow in places. I didn’t want to throw out the baby with the bathwater, the additional meaning provided by HTML5 elements is just too great. <header>, <section>, <nav>, <article>, etc all provide meaning to a document that it’s difficult to justify going without.

It’s with the additional meaning in mind that I decided to go with – what I’ve dubbed – HTML4.5. HTML5 provides the meaning while using traditional HTML 4 tags as hooks for styling. It introduces a bit of tag soup, as instead of <article id="content"> ... </article> the code becomes <div id="content"><article> ... </article></div>.

The improvement to site I was working on was immediate, as you can see by visiting the html4.5 demo in IE8 (screenshot via WebPageTest):

HTML4.5 as seen in IE8

I don’t care about tag soup

If given the choice between an unusable website for some visitors or a little tag bloat, I’ll take the bloat any day of the week. In the demo the bloat adds an extra 14 bytes. On the home page for the site I was working on, it’s 40 bytes. I save plenty more than 40 bytes by minimising my JavaScript and CSS (a single key combo with the YUI Compressor TextMate bundle), so I’m not too concerned about the side effects.

A technically beautiful site is the ideal but if a portion of your visitors can’t use it, then the beauty isn’t even skin deep. As Drew McLellan said recently on 24 ways, progressive enhancement is “also known as doing our jobs properly.”

“Safari, Chrome and Internet Explorer leave a blank space in place of the styled text while the web font is loading. Opera and Firefox show text with the default font which switches over when the web font has loaded, resulting in the so-called Flash of Unstyled Text (aka FOUT).”

Richard Rutter wrote an excellent piece about how to avoid these different behaviours. I thought it was worth quoting and linking to twice.

One of the disadvantages of using Selectivizr is it rules out using a CDN for one’s style sheets. To quote their site:

Style sheets MUST be hosted on the same domain as the page due to browser security restrictions. Likewise, style sheets loaded using the file: protocol will not work.

Normally, particularly for low traffic sites, this wouldn’t be of great concern. As we share style sheets across sites (both Big Red Tin & Soupgiant use the same CSS) and use the CDN feature of W3 Total Cache on our hosted WordPress sites, it could cause problems down the track.

After umming and ahhing for a couple of days, the following solution involving conditional comments, occurred to us:

<!--[if gte IE 9]><!-->
<link rel="stylesheet" href="http://cdn.example.com/styles.css" type="text/css">
<!--<![endif]-->

<!--[if lte IE 8]>
<link rel="stylesheet" href="/styles.css" type="text/css">
<![endif]-->

With a few lines of conditional comments, browsers supporting the relevant selectors natively can take advantage of the performance boost from a CDN while developers can take advantage of the advanced selector support provided by Selectivizr for IE<9 users.

We’ve set up a quick demonstration in which three paragraphs have different ARIA roles – featured, unfeatured and neverfeatured – different styles are applied to each paragraph using [role=something]. The demo renders fully in: IE 6-9beta, Firefox (Win & Mac), Chrome (Mac), Safari (Mac), and Opera (Mac).

It parses your css and returns a copy with all external media “baked” right into it as Base64 encoded datasets. The number of time consuming http-requests on your website is decreased significantly, resulting in a massive speed-boost.

While baking images into your CSS to lower HTTP requests reduces the rendering time of your site overall, the downside is that CSS files block the initial rendering of your site. While an unbaked site may render and be built up as external images load, a baked site will not render until both the CSS and baked images have loaded. This has the strange effect of making it seem like the page is actually taking longer to load.

I’ve thrown together a quick example of an unbaked page and its baked equivalent. In this example, the unbaked page begins rendering earlier than its baked counterpart but finishes later.

In an attempt to kick off rendering earlier, I tried what I’ve named a half-baked idea: splitting the standard CSS into one file and the baked images into another. My hope was that browsers would render the standard CSS while the other was still loading. As you can see on the example page,  this failed.

With CSS only solutions delaying rendering of the page, it’s time to pull JavaScript out of our toolbox. Anyone whose read my article on delaying loading of print CSS will find the solution eerily familiar. The CSS files are still split into the standard files and the file containing the baked-in images, the one with the baked in images is wrapped in <noscript> tags in the HTML head.

<link rel="stylesheet" href="halfbaked-1.css" type="text/css" />
<noscript><link rel="stylesheet" href="jshalfbaked-2.css" type="text/css" /></noscript>

This prevents the second/baked stylesheet from loading during the initial rendering of the page. Without this file blocking rendering, this version of the example begins rendering as quickly as the first, unbaked, example.

The second/baked stylesheet needs to be added using the JavaScript below:

<script type="text/javascript">
window.onload = function(){
  var cssNode = document.createElement('link');
  cssNode.type = 'text/css';
  cssNode.rel = 'stylesheet';
  cssNode.href = 'jshalfbaked-2.css';
  cssNode.media = 'all';
  document.getElementsByTagName("head")[0].appendChild(cssNode);
}
</script>

Using the method above for baking images into your CSS will give you the best of both worlds, your page will render quickly with a basic structure before a single HTTP request is used to load all of your images.

I used Web Page Test to measure the first-run load times using IE9 Beta, averaged over 10 tests. On the test pages, with only a few images, the advantage of a baked stylesheet isn’t apparent, on a site with more images it would quickly become so.

As the Spritebaker info page says, IE versions prior to IE8 don’t understand data-URIs, so you’ll need to use a generous sprinkling of conditional comments to load images the old fashioned way in these browsers.

The examples above were tested on IE9 Beta, Chrome 6.0, Safari 5.0, Opera 10.10 and Firefox 3.6.9. Individual results may vary.

We’d love to hear of your experiences with baking stylesheets, or other techniques you use to speed up apparent rendering of your page, especially if it slows the total load/rendering time.

Another question to ask is whether all this is actually worth the effort – even when reduced through automation. On Big Red Tin, the print.css is 595 bytes, the delay in rendering is negligible.

Chris and Jeff at Digging into WordPress picked up the article and posted it on their site. In turn it was picked up elsewhere and became the surprise hit of the summer at Big Red Tin. Not bad when one is shivering through a bitter Melbourne winter.

As a result of the interest, I decided to convert the code from the original post into a plugin and add it to the WordPress plugin directory.

Further Testing

As I warned in the original article, I’d tested the code in very limited circumstances and found it had worked. Fine for a code sample but not enough for a sub version-1.0-release plugin. Additional testing showed:

1. Stylesheets intended for IE, through conditional comments, were loading in all browsers
2. When loading multiple stylesheets, the correct order was not maintained in all browsers

If jQuery was available I wanted to use it for JavaScript event management otherwise I’d use purpose-written JavaScript. There’s no point, after all, of worrying about the rendering delay caused by 600-1000 bytes only to load a 71KB (or 24KB gzipped) file in its place.

Other things I wanted to do included:

1. Put the PHP in a class to reduce the risk of clashing function/class names
2. Put the JavaScript in its own namespace
3. Keep the output code as small as possible

To support conditional comments for IE required adding each stylesheet within a separate <script> tag, using this method the output HTML takes the following form:

<script>
  // add global print.css
</script>
<!--[if IE 6]>
  <script type='text/javascript'>
    // add ie6 specific print.css
  </script>
<![endif]-->

This violates my aim to keep output as small as possible but footprint has to take second place to bug-free. I could have translated the code to use JavaScript conditional comments by translating the IE version to the JavaScript engine it uses but this could lead to future-proofing problems.

To maintain the order of stylesheets, I added each event to an array of functions and then used a single event to loop through the array of functions. If jQuery is used, I add multiple events because jQuery runs events on a first in first out basis.

Putting the PHP in a class and the JavaScript in its own namespace is fairly self-explanatory. Google is your friend if you wish to read up further on this.

Minimising the footprint was also a simple step. I wrote the JavaScript out in full with friendly variable names. Once I was happy with the code, I ran the code through the YUI JavaScript compressor, commented out the original JavaScript in the plugin file and output the compressed version in its place.

The JavaScript is output inline (within the HTML) to avoid additional HTTP requests. I was in two minds about this because browser caching is lost in the process. So it may change in a later version.

I’ve worked out another way to keep the footprint small. Rather than creating a function to pass the stylesheet’s URL and ID to brt_print.add(url, id), I wrote out the full function for each style sheet. I’ll fix that in the next release.

You can download the Delay Print CSS Plugin from the WordPress plugin repository.