The answer is to test your sites in as many browsers as you can. The types of browsers that you’re able to install will depend on the operating systems to which you have access. At the very least, you should test in Internet Explorer 6, 7, 8, and 9, as well as the latest versions of Firefox, Opera, Safari, and Chrome. Additionally, even if you’re not providing a different experience for mobile users, it’s worth checking how the site behaves on the iPhone, iPad, and other mobile devices, making sure that everything is usable via a touch interface. That’s not to say that the site should look identical in all of these browsers. The experience for an IE6 user could be very different from an IE9 user—but you should aim to have the content accessible and the site usable.

When starting work on a new site, you should first consider the kind of person who will be using the site, as well as the likely browsers and devices that they’ll be using. If you are redesigning a website, you’re in luck! There should be some existing information in the web statistics as to which browsers are being used. Even if it is a brand new site, you should be able to draw some conclusions based on the audience. For example, many really old Internet Explorer browsers (IE6 and 7) can be found in large companies in the UK who require it for legacy internal products. If your site is aimed at these users, you may find that you need to provide more support for these old browsers. If your site is aimed at young people, or is particularly useful to people on the go, you might have more mobile devices than average browsing the site. You might also have other sites, for which you have access to statistics, that serve a similar audience. There are also a number of sites that publish statistics, such as StatCounter. It offers an analytics service, collating the data from all the sites that run its service to provide some idea of browser and version trends. By looking at the browsers and devices that your users most frequently employ, you can put together a browser support policy for your site. This can outline the browsers that you test in, and the level of support you offer in terms of the design.

This approach is a simple example of progressive enhancement. Essentially our IE6 layout has all the basics in place. By using CSS, we’ve added detail that’s unsupported in the older browsers, though those browsers still display a basic, readable experience. This concept of progressive enhancement is crucial to robust front-end development. You start simple for the browsers that have little support, and layer in CSS properties, JavaScript, and other enhancements for the most capable browsers. Everyone then has a decent experience, and those with newer, more capable devices gain all the additional finesse of a modern user interface. For very complex layouts that rely heavily on new CSS features and have very little traffic from browsers such as IE6, you may wish to take this approach a step further and serve a very simple stylesheet to IE6. Andy Clarke has popularized this approach, and his Universal IE6 Stylesheet is available on Google Code. My advice is not to ignore older browsers while we still see some traffic from them; however, it’s appropriate with these problematic browsers to serve something different. Keep your content accessible, but there’s no need to try to replicate the modern web experience for ten-year-old browsers.

CSS3 selectors are one of the simplest aspects of CSS3 to create support for using JavaScript. You can do so by writing JavaScript yourself, or by writing functions to use with another library such as jQuery, or by including a JavaScript plugin that automatically adds support for selectors. We’ll take a look at an example from an earlier chapter where we learned how to stripe alternate table rows using nth-child, as seen in Figure 7.4. The CSS3 nth-child selector is used as follows:

.datatable tr:nth-child(odd) {
  background-color: #dfe7f2;
  color: #000000;
}

Internet Explorer 8 has no support for nth-child, so there are no striped rows, as you can see in Figure 7.5. One way to patch this is by using Selectivizr. This script provides CSS3 selector support to Internet Explorer, and does so without you needing to make any other changes to your CSS. A script that adds in support like this is sometimes referred to as a polyfill. Selectivizr requires another JavaScript library to work. You can see on the website which libraries it works with, but if you’re already using a library, it’s quite likely to be included. As my page doesn’t already use a library, I’ve chosen to include jQuery. I add the jQuery include, and then download and link in Selectivizr: If I reload my page in Internet Explorer, I can see the striped table rows as evident in Figure 7.6.

Using Selectivizr is a great solution if you have a lot of CSS3 selectors in use; however, you should take care that your pages are still comprehensible without it being included just in case a user has an old version of IE and JavaScript disabled, blocked, or failing to load for some reason. If you only have one or two CSS3 selectors to patch, and would rather skip the inclusion of Selectivizr or its ilk, you could write your own JavaScript to plug this particular hole. Again, I’m using jQuery as the library. One very nice benefit of jQuery is that it uses CSS selectors to target elements. So if you know how to access an element using CSS, you should find jQuery quite straightforward to use for these patches. I include jQuery, then write a simple little function that adds a class of odd to every other table row. In reality, you’d probably include a JavaScript file here with a number of functions in it: We now need to make a small change to our CSS: adding a selector that looks for a class of odd alongside our nth-child selector: This will cause the rows to be striped in older browsers as long as they support JavaScript. Whether you use Selectivizr or decide to write your own JavaScript is up to you. As most of our projects use jQuery anyway, and we tend to have a JavaScript file that deals with any UI requirements, I often create a fixSelectors function that goes through and adds classes to enable support for CSS3 selectors. This does involve a little more work than just including Selectivizr; however, it does mean that I’m always aware of what the JavaScript is doing. For very rapid development, or when you are prototyping layouts, scripts such as Selectivizr are very useful. Browsers lacking support for these selectors are going to become far less commonly used, making the employment of Selectivizr more compelling as there’s no need for additional CSS selectors. If the browsers eventually stop registering in the stats on your site, you can simply remove the JavaScript include.

The Selectivizr polyfill is designed to provide CSS3 selector support in Internet Explorer 6, 7, and 8, so there’s no reason to have WebKit or Gecko browsers downloading it. We can use conditional comments to serve this script to only certain versions of IE:

Conditional comments were introduced by Internet Explorer as a proprietary method of serving content to specific versions of Internet Explorer. They can be used to include an additional stylesheet to fix problems in certain versions of IE, or, as we’re doing in this example, to include polyfills that only target certain versions of IE. In our example, we’re stating that if the browser is greater than or equal to IE6 AND less than or equal to IE8, it should load the JavaScript. Non-IE browsers and Internet Explorer 9 and above will ignore it. Here are some further examples of useful conditional comments. This would include ie6fixes.css if the browser is IE6:

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

This includes ie7fixes.css if the browser is equal to IE7:

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

This code will reveal a stylesheet to all versions of Internet Explorer less than or equal to version 7. It’s useful if you have some layout fixes for both these old browsers:

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

For further examples of conditional comments and a full guide to their use, see the SitePoint CSS Reference page.

One solution is to use a polyfill script that adds support for border-radius along with other CSS3 properties. CSS3 PIE (Progressive Internet Explorer) is one such script. We can take a look at how this works using our example page. In Internet Explorer 8, our layout displays very much as it does in earlier versions of Internet Explorer, with no rounded corners or drop shadows as in Figure 7.7. Download CSS PIE and unzip the files. The file PIE.htc needs to be placed into your site. In any rule set that contains rounded corners or drop shadows, add the behavior as shown in our code. The path to PIE.htc needs to be relative to the page rather than the CSS file, so I would suggest that in a live site you make it a path from root; for example, behavior: url(/path/to/PIE.htc);: If you now view your page in Internet Explorer 6, 7, or 8, you should find that rounded corners and drop shadows are working. Although not quite as slick as the pure CSS implementation, it does work, as you can see in Figure 7.8.

PIE is added to your site using a proprietary Internet Explorer property: the behavior property. This property enables you to attach a script to your CSS. The script is in a .htc file (HTML component). Other browsers will ignore this property, and only Internet Explorer will attempt to run your .htc files. Similar scripts are available that attempt to support other unsupported features such as CSS3 transforms. It’s worth mentioning that whenever you use one of these scripts, you should carefully test all the target browsers, as it’s possible that problems will be introduced by their inclusion. An alternative solution would be to avoid using CSS3 at all and return to older methods of using images to achieve this effect. Depending on the number of older browser users and the particular effect you require, this may sometimes be necessary. What’s great about using a polyfill like PIE is that at the point in time when these older browser users cease to visit your site, you can simply remove the behavior. Otherwise, if you add extra markup and images to create the layout without using CSS3, this weight is then downloaded by all users, and you’d need to rebuild the site in the future to take advantage of CSS3.

I’d advise you to avoid worrying too much about these old browsers while developing your site unless you’re in the unfortunate position of having a large number of users on such browsers (a situation that is becoming less common each month). Develop in an up-to-date browser, validate your markup and CSS, and get everything working as you want it for modern browsers first. I believe strongly that you should refrain from cluttering your markup with fixes for very old browsers, and continually checking and trying to fix issues as you go tends to lead to that temptation. There will probably be some problems in IE6 when you first look at your layout. These might be small predicaments such as incorrect padding between page elements, or larger issues such as huge sections of your page disappearing or displaying in an odd place. There’s no need to panic! Most IE6 issues can be easily resolved by specifying some different style rules for this particular browser. The same goes for IE7, although I find there are fewer layout problems to fix in this browser.

Internet Explorer below version 9 won’t recognize the new HTML5 elements, and will not apply CSS to elements that it fails to recognize. If you want to use these elements, you can add the HTML5 shiv^[2] to your document as demonstrated in this boilerplate document from HTML5 Doctor:

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8" />
  <title>HTML 5 complete</title>
  <!--[ lte IE 8]>
  <script src="http://html5shiv.googlecode.com/svn/trunk/html5.js">
    </script>
  <![endif]-->
<style>
  article, aside, details, figcaption, figure, footer, header,
  hgroup, menu, nav, section { display: block; }
</style>
</head>
<body>
  <p>Hello World</p>
</body>
</html>

In this document, you can also see that the HTML5 structural elements have been set to display: block. This would normally happen inside your stylesheet for the page. We’ll be covering the display property in Chapter 9 more thoroughly; but by setting these elements to display: block, we’re able to apply CSS to them much as we would a div element on our page.

The new HTML5 semantic elements offer far better ways of marking up sections of your pages than simply using a div element. If navigation is marked up using the nav element, a device could indicate to the user where the navigation was on the page; knowing where the header and footer of a document is offers potential in terms of being able to parse and extract content for reuse. If you decide to take advantage of these elements, you need to be aware that any CSS used to style them won’t be applied by Internet Explorer 8 and below. The HTML5 shiv JavaScript will enable these elements to be styled; however, you are then building in a reliance on JavaScript for users of those browsers. Depending on the traffic to your site, you can decide whether using these semantic elements and thus requiring JavaScript is acceptable. The alternative is to continue using the div element to mark up areas on your page (perhaps adding a class or ID using the HTML5 semantic element name) until such time as the nonsupporting browsers are enough of an acceptable minority for you to feel happy about switching. The decisions you make are likely to be different for each site depending on the site and audience.

There are now far fewer serious browser bugs in commonly used CSS, but new issues mean that we can’t afford to test in just one modern browser before launching a site. We need to check that our content is readable in older browsers when using CSS3, and we’re likely to find that fonts (especially custom fonts imported using @font-face) render differently across operating systems. Some browsers are available across all operating systems; Firefox, Chrome, and Opera, for example, can be installed on Windows, OS X, and Linux. There is a version of Safari, the default browser on OS X, for Windows. As Chrome is based on WebKit—the same rendering engine as Safari—there are many similarities across these two browsers; however, it’s unwise to assume that if it works in one it will work in the other (such as the support of CSS3, for example). They are, after all, on different release cycles.

In my experience, the best way to test Internet Explorer is to use a proper version of Internet Explorer in a virtual machine. The free virtualization software, VirtualBox, is very capable when used for this purpose. You do need a reasonable amount of disk space and memory to run virtual machines—especially if you have several open at once. If this is a problem for you, Utilu IE Collection may be helpful; it installs a collection of standalone versions of Internet Explorer. I would suggest doing this inside a virtual machine even if you are a Windows user, to avoid creating any issues with your primary Internet Explorer browser.

There are simpler solutions for Internet Explorer testing. Internet Explorer itself, in recent versions, has a method for rendering pages as if it’s an earlier version. In Internet Explorer 9 Developer Tools, you can switch browser mode and view a page as if using the earlier browser. While this works reasonably well, in some cases what you see in browser mode through IE9 is different to the real browser, and browser mode itself may well have its own quirks not present in the original browser. So it might be good for a quick look during development, but I’d always suggest doing proper testing in the real browser. There are also multiple IE testing tools such as IETester; however, in my experience these are unreliable. In particular, conditional comments are often ignored (so a stylesheet or script file targeted solely at this browser may be bypassed). I’ve spent many a frustrating hour trying to work out why a client was seeing something different to us in IE6, only to discover they were running IETester to test the site and not a real IE6 browser! Therefore, I cannot advise using these tools. For an excellent write-up of Internet Explorer testing, including many of the tools I’ve mentioned in this section and much more, read “Reliable Cross-browser Testing” on Smashing Magazine.

There are two issues when it comes to testing on mobile devices. One is that they have smaller screen sizes than their desktop counterparts; the second is that the experience of using a mobile touchscreen device is different from using a desktop computer with a keyboard and mouse. So your testing needs to cover “does it look okay?” and “is it usable?” The browsers used by mobile devices tend to be fairly up to date. The iPhone and iPad use mobile Safari, which uses Webkit as its rendering engine—the same engine behind the default Android browser, and the browser used in newer Blackberry devices. In addition, there are mobile versions of Opera and Firefox. Windows phone uses a mobile browser based on the rendering engine in Internet Explorer 9. Due to these up-to-date browsers, you can often be more confident using CSS3 for phones than on the desktop. The rendering is generally the same as desktop versions of these rendering engines—albeit at a small screen size, and in Chapter 9 we’ll be discussing how you might support those smaller screens in particular. For current information on mobile browsers and devices, I’d suggest visiting the mobile section of QuirksMode.org run by Peter-Paul Koch and Mobile HTML5 by Maximiliano Firtman, where a large amount of information on mobile devices and browsers is being collated. There are services that let you view how the site might display on a small device; for example, Screenfly. There are also options for taking a screen capture on mobile devices—just as with the desktop services I described earlier in the chapter. BrowserCam is one such service that covers desktop and mobile, and gives access to a wide range of different devices. Then there are some services that give remote access to a variety of devices—for example, Perfecto Mobile—although these are quite expensive. Given that the rendering engines of mobile browsers are similar to desktop rendering engines, and that the browsers tend to be up to date, you generally won’t hit too many problems in terms of layout for modern mobile phones. Where you do need to test more thoroughly is in terms of the actual experience of using your site with a touchscreen device, especially if you are using drop-down menus or any other interactions that might become fiddly on a touchscreen. If possible, I’d recommend that you have access to a couple of devices: a higher-end device such as an iPhone or Android phone with a larger screen and reasonable specs, and a cheaper device. I have a tiny Android phone that I use for this purpose; it’s the kind of phone that, in the UK, you get free on inexpensive phone plans, so it’s the sort of device that many people might be using. You can then test the experience for users of high-end phones and lower spec phones, making sure that everything is usable. At the very least, you should be checking your site on one-touch devices at this point in time.

This is a solution that helps you find the solution.

Vendor-specific extensions, starting with -moz, -webkit, and so on, are not part of the CSS3 specification, so they’ll be unrecognized by the validator and throw a warning or error. The syntax of beginning an extension to CSS with a “-” is correct, however, so the validator does understand about the existence of these extensions. Therefore, you can use the additional options fields at the W3C Markup Validator to hide these messages. At the CSS Validator, seen in Figure 7.11, open the More Options area and make sure that under Profile you have selected CSS level 3. You can then select No warnings and set the Vendor Extensions notification to show up as Warnings. This will allow you to validate your CSS for the important errors. I’d advise you to also check the warnings as well, but it can be hard to start looking for problems if you’re swamped with hundreds of messages about the legitimate use of prefixed properties.

Another point to note with regards to the Validator is that when you first validate your page, don’t panic if you see lots and lots of error messages. Deal with the first one, then validate again. Often the messages cascade from that one problem, so fixing it will also “fix” further errors. Fix each issue, then validate, and see what you’re left with.