The more traffic your website receives, the higher the likelihood of it being accessed by unlikely or unusual devices. Whereas smaller websites can afford to ignore or neglect particular devices and/or web browsers, for larger websites they may make up a large enough number to require consideration as an important user group. Larger companies take great care of their brand and their customer experience, and at the very least you should be showing anyone interested enough to visit your website a reasonable experience regardless of what they are using to view it. To that end, you need to implement various methods to detect their platform and serve the most appropriate content.

The media attribute in the link tag we use to reference external style sheets is intended to identify the kind of device the style sheet is aimed at. Where devices/browsers support this, they will ignore irrelevant or unknown style sheet media types, and not include the contents of the file. It is worth noting that most modern browsers will still download the file, even where they do not intend to parse the contents.^[52] This means this method is not of use from a performance perspective—it actually incurs more HTTP requests than not using it—but is only of use for targeting specific browsers or devices.

You can actually target media via three methods. The first is within the link tags, like so:

<link rel="stylesheet" href="style.css" media="screen" />

The second is via the @import directive:

@import url(style.css) screen;

@import commands must always precede any other rules in a style sheet (except for other @import commands). Again, most modern browsers download the file, even though they will not parse the contents of the file. Regardless, we don't recommend you use @import rules because they block the parsing of the rest of the file.

The final method is the @media directive, which allows us to use only certain parts of files with certain media types. Here's an example:

@media screen {
   body {
      font-family: arial;
   }
}

This would only target browsers and devices that report support for the screen media type.

For all three of these methods, you can comma-separate the media value to target multiple types, like so:

<link rel="stylesheet" href="style.css" media="screen, print" />

@import url(style.css) screen, print;

@media screen, print {
   body {
      font-family: arial;
   }
}

In these instances, if the browser or device supports only one of the media types, the file/rules will still be parsed.

For each media type, there are certain factors it is important to take into account. These are referred to as media groups.

Paged media (media that consists of pages—like a printed document—rather than one long document like a web page presented on a screen) supports some extra properties that continuous media does not^[53] Grid media (as opposed to bitmap media) considers fixed-width characters to be of importance. For example, braille media needs characters to be of a predictable and consistent width for users to be able to understand it. We can group by static, interactive, or both, indicating whether the target is read-only or can be interacted with. Media can also be grouped as visual, audio, speech (for screen readers) or tactile (for devices that communicate with touch; braille, for example).

Let's take a look at the media types defined in the CSS2 specification.

<link rel="stylesheet" href="style.css" media="speech, aural" />

Media types can give us the ability to target some of the devices we might expect to be browsing our sites, but their implementation in the devices is patchy. New devices are more predictable in their support, particularly those that your high-traffic websites are likely to see considerable visitors from. Again, these devices are likely to form a small fraction of your total traffic, but a large amount of people nonetheless. Media queries give us much better control over the devices and browsers we're targeting.

A media query is made up of two parts: a media type and zero or more queries that will be checked against the media features. When the media type matches the one of the device and all the queries are true, the media query is applied. If more than one media query is listed (using a comma-separated list), only one of the media queries needs to be true.

Here's a quick example:

<link rel="stylesheet" href="style.css" media="screen and (min-width:800px) and (max-
width:1500px)" />

As well as targeting browsers and devices that support the "screen" media type, we are also stating that the width of the viewport of the device must be at least 800 and at most 1,500 pixels. The features we are naming in the brackets above are known as "media features". You can comma separate media queries (exactly as with media types) as shorthand, like so:

<link rel="stylesheet" href="style.css" media="tv, projection, screen and (min-width:800px) and (max-
width:1500px)" />

In this instance, each comma-separated valued is evaluated in its entirety, (the parts following the "and" only apply to the media type immediately preceding them). The preceding media query is the same as the following:

<link rel="stylesheet" href="style.css" media="tv" />
<link rel="stylesheet" href="style.css" media="projection" />
<link rel="stylesheet" href="style.css" media="screen and (min-width:800px) and (max-
width:1500px)" />

You can use multiple "and" clauses in each list. You can also use "not" to negate an entire media query. However, you cannot negate individual parts of the query. The following will work:

<link rel="stylesheet" href="style.css" media="not screen and (min-width:800px) and (max-
width:1500px)" />

This will parse style.css for only any browser or device that would fail the query without the "not" keyword applied (the media type screen is unsupported, or the width of the viewport is less than 800 pixels, or the width of the viewport is greater than 1500 pixels). The following (and other variants to attempt the same) does not work:

<link rel="stylesheet" href="style.css" media="screen and (min-width:800px) and not (max-
width:1500px)" />

This lack of granularity can be frustrating for any developer used to basic conditional logic. To target multiple feature sets in this manner, it is necessary to first apply the default behavior to all devices then override this behavior for each device, like this:

/* Applied to every device and browser */
body {
   color: black;
}

@media screen and (min-width:800px) {
   /* Only applied to screen devices with a viewport width of at least 800 pixels */
body {
   color: red;
   }
}

Whenever a media query is not understood by the user agent (browser or device), it is considered to be "not all"—that is, it will not apply the contents of the linked style sheet or query.

The "only" keyword can be used to ensure that only CSS3-compliant browsers will apply the style sheet.

<link rel="stylesheet" href="style.css" media="only screen" />

Using the "only" keyword in the beginning of a media query will hide the media query from older browsers that don't support them (since they will think "only" is the name of a media type), while conforming browsers will ignore the "only" keyword and check for the media query that follows it.

As well as in the link tag, media queries can be used in the other two ways in your CSS files, exactly as media types alone can be used:

@import url(style.css) screen and (min-width:800px) and (max-width:1500px);

@media screen and (min-width:800px) and (max-width:1500px) {
   body {
      font-family: arial;
   }
}

When a media feature will evaluate to a value other than zero (regardless of unit), you do not need to provide a value. For example:

<link rel="stylesheet" href="style.css" media="all and (width)" />

This style sheet would always be applied because the width of the viewport will always be greater than zero (except perhaps for primarily audible devices). You wouldn't use this method; we just include it as an example.

Before we get too deep into the media features available, it's worth spending a moment discussing the viewport itself. The viewport is the available rendering size on the device, not including any browser chrome.

With the introduction of Mobile Safari, Apple also introduced the viewport meta tag^[55].

The viewport meta tag gives you some control over the size and behavior of the viewport. Although this is HTML, it is important to cover to understand some of the concepts we will deal with in this chapter. Here's a simple example:

<meta name="viewport" content="width=device-width" />

The name "viewport" identifies this meta tag. The content attribute contains the values we want to pass. The properties are key/value pairs divided with an equals sign; you can comma-separate them to have as many as you like. There are two important constants we can use:

There are also six important properties we can use:

The vital thing to take away from this is that the viewport may exceed the visible area, but will never be less than the visible area. This is important because we use viewport in media features. There are many media features defined in the CSS3 specifications. We'll list these in the following sections.

@media screen and (aspect-ratio: 4/3) {
   ...
}

<link rel="stylesheet" href="style.css" media="screen and (min-color-index:1,001)" />

Modernizr (http://www.modernizr.com/), created by developers Faruk Ateş, Paul Irish, and Alex Sexton, is a JavaScript library that detects and exposes browser functionality. It works by adding classes to the html element of a page; these classes indicate whether or not a particular feature (HTML5 and CSS3 features, to be exact) is present in the browser. Modernizr does not enable the functionality in the browser; it merely states whether it is available or not. It also adds support for styling the new HTML5 elements in less-capable browsers like Internet Explorer.

To use Modernizr, you just need to link to it in the head of your HTML document, like so:

<script src="js/modernizr-1.6.min.js"></script>

Second, you need to add a class of "no-js" to your html tag. This will be the default state of the page. If JavaScript is off, Modernizr will not work, and you will be able to detect this and provide a non-JavaScript version of the page to your users:

<html class="no-js">

If JavaScript is enabled, various classes, similar to the following, will replace this class:

<html class="js canvas canvastext geolocation rgba hsla multiplebgs borderimage borderradius boxshadow opacity no-cssanimations csscolumns no-cssgradients no-cssreflections csstransforms no-csstransforms3d no-csstransitions video audio cufon-active fontface cufon-ready">

In the preceding example, we can see that the browser in question (Firefox 3.6, in this case) does not support CSS animations, CSS gradients, CSS reflections, CSS transforms in 3D, or CSS transitions (from the classes "no-cssanimations," "no-cssgradients," "no-cssreflections," "no-csstransform3d," and "no-csstransitions," respectively). It does support the other features, like canvas and geolocation.

With this knowledge, we can now write CSS accordingly. Let's imagine we want to add multiple backgrounds to the body element of a page. We can first specify the default style for all browsers and then override that style with a more specific one that will only target browsers that support the feature, as such:

body {
        background: url(simple.png) top left repeat-x;

}
.multiplebgs body {
        background: url(multiple-top.png) top left repeat-x,
        url(multiple-bottom.png) bottom left repeat-x;
}

In the case of the html element shown previously, Firefox 3.6 would understand and show the multiple backgrounds. Internet Explorer 8, for example, would only display the "simple.jpg" background image, as the class it would use would be "no-multiplebgs" instead.

It is also important to notice that in the preceding example, Firefox 3.6 would actually download both images because both rules could be applied (even though the less specific rule is overridden), so even though we are making sure to cater for users that can and can't see the features, we're penalizing those who can by making them download a completely unnecessary file. We could have avoided this by using ".no-multiplebgs body" in our first rule, rather than just "body."

Although a simple and useful solution, before you consider using it, remember that Modernizr will make for very verbose CSS that is downloaded by all users and not necessarily applied, and add a JavaScript dependency to your CSS, which is far from ideal.

Print style sheets need to be considered as a special case. Users will often want to print pages from your site, and you can cater to their needs in a way that's different from how you would cater to typical users. Users printing your content are engaged users, and frustrating them with unnecessary content or pages that won't fit well on their media will reduce their goodwill toward your site and your company. On the other hand, providing them with just the information they need in a legible and friendly format shows attention to detail and consideration to their needs. Making a basic print style sheet is very easy, and if your markup and CSS is well thought out, often it will be very concise and work well across your entire site.

Including a print style sheet is easy. We'll reiterate how best to achieve that here:

<link rel="stylesheet" href="print.css" media="print" />

You could use the @import command to achieve the same thing, but this would not work for very old browsers. You could also use the @media command to target print devices specifically, but again this would exclude older browsers. There are several things you need to consider including in this style sheet for users who are printing your content.

In his excellent article on A List Apart (http://www.alistapart.com/articles/goingtoprint/), Eric Meyer suggests using the :after pseudo-element to append the URLs linked to after their link text. This makes perfect sense; without the URL, the link text is effectively useless when printed. Here is a simplified version of the code he uses to achieve this:

a:after {
        content: " (" attr(href) ") ";
}

He goes on to say that this method will not work well with links relative to the root of the site, and offers a solution for this:

a[href^="/"]:after {
        content: " (http://www.alistapart.com" attr(href) ") ";
}

These solutions are not perfect. URLs that are relative to the current document will still not display their full path, and links at the end of a sentence will display a space after the closing bracket and before the period, but it is a great improvement on the alternative.

Here's an example of a printed A List Apart page:

Figure 7-1. An example printout from A List Apart

Print and other paged media support several extra rules and properties to continuous media. The page itself can be targeted with @page for applying margins at the global level, like so:

@page {
   margin: 2cm 3cm;
}

You could apply the margin to the body element instead, but then you wouldn't get the margin at the bottom of each page.

There are also pseudo-classes for left and right pages. When printing double-sided documents, the second page is a "left" page, the third a "right" page, the fourth a "left," and so on. It is common to consider a larger gutter area between the pages in case the user staples or binds these pages together. This is easy to achieve:

@page:left {
   margin-right: 4cm;
}

@page:right {
   margin-left: 4cm;
}

You can also target the first page specifically, with the :first pseudo-class. The first page is neither considered left nor right:

@page:first{
   margin: 10cm;
}

Controlling Page Breaks

Several properties exist with the intent of giving us more control over where our pages are broken. The first three are page-break specific:

• page-break-before

• page-break-after

• page-break-inside

page-break-before and page-break-after accept five possible values (six if you include "inherit", which is their default):

• auto

  • This will have no effect on the printed output. Pages will be split wherever the printer (or paged device) runs out of space.

• always

  • A page break will always be forced before (or after, as appropriate) the element.

• avoid

  • The device will attempt to avoid page breaks before (or after, as appropriate) the element.

• left

  • The device will insert page breaks before (or after, as appropriate) so that the next page will be a "left" page (and can therefore be targeted with the :left pseudo-class).

• right

  • The device will insert page breaks before (or after, as appropriate) so that the next page will be a "right" page (and can therefore be targeted with the :right pseudo-class).

page-break-inside only supports "auto" and "avoid" from this list.

Tip

If you use thead, tbody, and tfoot tags within your tables, the header and footers will repeat on every page making the tables easier to read. Table rows may still be split, which can be avoided with the following CSS in your print style sheet:

tr {
  page-break-inside: avoid;
}

You can read more about print behavior for tables at http://www.w3.org/TR/CSS2/tables.html.

Building print style sheets is an easy and worthwhile thing to do, from an accessibility and a usability point of view. Big websites don't always cater for printers, and as such give their users a poor experience; taking this step can help separate your site from the rest. Again, for a high-traffic website, more and more of your users are going to want to print your pages, perhaps because they don't have mobile Internet-enabled devices. There are examples of real-life print style sheets in Figures 7-2, 7-3 and 7-4.

Figure 7-2. Gap doesn't hide unnecessary elements or set its text to a dark color—as a result, much of the text is invisible, and the first printed page has no useful content.

Figure 7-3. Virgin's website prints a huge mess before it gets to any content.

Figure 7-4. The Onion lets its advertising get in the way of its content.

As always, the browser implementation is inconsistent, and you still need to test your code. You can check the results of your work quickly in print previews rather than killing trees. You can also quickly switch the media type of your link tag (or @import or @media rules) to "all", but be aware that browsers may apply different styles by default to print style sheets than they do to screen ones. You can read the CSS 2.1 specification for paged media at http://www.w3.org/TR/2009/CR-CSS2-20090908/page.html#page-box. CSS3 adds more features to allow you to control page number counters, widowed lines (lines left at the top of the page) and orphaned lines (lines left at the bottom of the page). Although support is patchy now, it doesn't hurt to implement these. Read more about them at http://dev.w3.org/csswg/css3-page/.

The methods your users have of accessing your website are growing dramatically all the time. Many of your typical users are likely to now have several means of reaching the Internet: home computer, work computer, perhaps a set-top box of some kind, and cellular telephone. The cell phone has come a long way from the brick-shaped kilo of the 1980s, and many are now capable computers in their own right. They can access your data via many different technologies including WiFi, GPRS, 2G, and 3G, and faster standards are emerging all the time. For high-traffic websites, the likelihood of serving your data to mobile devices is very high, and your users will expect a lot from you. In fact, users in developing countries may bypass computers altogether and only own a mobile device. Tablets are also rapidly gaining in popularity and can be considered mobile devices.

There are some things in particular you need to consider when serving websites to mobile devices:

You have several solutions for catering to your mobile users.

Another Website

The optimum solution is to provide different sites to mobile users. Redirecting your users based on server-side user agent detection (for example, to http://m.facebook.com or http://touch.facebook.com) allows you to build a complete experience for them based upon their likely resolutions and their latent and slow network speeds. Unfortunately, for all but the most popular devices, this is a hard thing to achieve. For one thing, the manufacturers of the browsers on that device (be it something proprietary, Opera Mini, Mobile Safari, Firefox Mobile, or otherwise) have gone to a lot of effort to ensure that users of those browsers can enjoy a decent experience, even on a small screen. Secondly, the user agents available are changing all the time with new ones crawling out of the woodwork every day.^[59]

Facebook redirects you to a touch version of the full site when accessed via an iPhone (see Figure 7-5). It is also clever enough to use the accept-language HTTP header to present the correct language (the language the device is using) to the user.

Figure 7-5. Facebook on the iPhone (above, portrait mode; below, landscape mode).

You can only realistically target the most common of these. You can use media queries to provide a link to the mobile site in a prominent position for devices with small heights and widths, but then remember that some of the newest devices have very high pixel densities and can easily have a higher resolution screen than a desktop machine. If you do provide a separate website, there are a few things you should do:

• Provide a link to the mobile website, in case you fail to detect and redirect the user correctly.

• Provide a link to the regular website, too. If the user follows it, remember his preference.

• Provide your images as CSS sprites as much as possible. Those HTTP requests are going to really hurt for mobile browsers.

• Consider text links instead of images.

• Consider a single column layout.

• Aim toward vertical scrolling rather than horizontal.

• Increase the font-size value.

• Avoid relying on any interactions that depend upon a mouse, such as :hover.

• Avoid relying on any interactions that depend upon a keyboard, such as :focus.

• Use :active states for touch screen devices and :focus states for devices with buttons.

• Avoid floated elements.

• Remember that users may change orientation, and cater for both landscape and portrait. Using percentages and a fluid layout rather than fixed pixel sizes will help you with this.

• Use HTML5 input types like "tel" and "email" to give the device hints on how to help the user enter information. Devices that don't support these types will gracefully degrade to text.

• Avoid CPU-intensive operations such as offloading to the GPU (read about this in Chapter 8), transforms, transitions, and animations.

• Although using the accept-language header to detect language is clever—and the geolocation API to detect location—avoid trying to detect location with IP addresses. This is notoriously unreliable.

The downside of this technique is it requires you to maintain two websites. If you can use the same content and a templating system to do this, it may make it less painful to achieve. This will give your users the best experience.

Pizza Express delivers a cut-down version of its website to mobile devices, with extra functionality such as detecting your location, and allowing you to dial that restaurant from within the browser. This is a good example of how you should be thinking about the mobile devices: not just ticking a box, but giving the best solution you can to everyone regardless of device.

Figure 7-6. Pizza Express' website on Mobile Safari

<a href="tel:12345678901">(123) 456-7890</a>

There are other devices you should consider, which you may or may not be able to target. Set-top boxes with built-in web browsers, games consoles, native browsers in Smart TVs, Google TV, and so on. Each of these will have its own capabilities and features. We recommend testing on everything you can.

Search engine spiders (programs that scan your website by "crawling" all of the links they can find and sending the results back to the search engine) can be considered devices in their own right. They have their own unique user agents, and their own unique capabilities. Search engine optimization (SEO) is the practice of ensuring that these spiders have the best chance of reaching all your content and that it is as appropriate as possible when they do reach it. SEO is of huge importance to big companies since it can be a driver of vast amounts of traffic, and thus vast amounts of sales (or whatever the goal of your website is). SEO, like accessibility, needs to be considered from the outset, and implemented in a consistent and sane manner.

To discuss SEO techniques in any great detail would warrant its own book, but we will mention some high-level points here. First we'll talk about the differences between white, gray, and black hat techniques:

Many people think they have found new and clever ways to cheat the search engines. In reality, all they are doing is wasting their time, giving their users a worse experience, wasting time that would be better spent improving their website, and delaying the inevitable. The search engines will figure out what you are doing in the long run, and they will penalize you for it. The truth is that the only one who knows exactly what will rank well against the search engine's algorithms is the search engine. Even then, your request could get directed to one of many servers with different versions of the algorithm, and the algorithm is likely to change often. Some general guidelines exist, however. To get good search engine ranking, it is important to

Really, this is just in line with making good quality websites, which we hope you are aiming to do anyway. Having good content is what the search engines appreciate the most. Making your content semantic and valid (including using microformats, and common class names and IDs) helps the search engines understand the content and your intent, and present it in a more comprehensive and attractive fashion on their search results page.

Depending on the search engine, the spiders have different capabilities as devices. Some parse JavaScript, some don't; some parse CSS, some don't. On the whole, search engines do now understand and apply CSS to the page. Typically, if they understand text to be invisible for whatever (gray hat) reason, they will not rank your page for this content or the words within it. If you are using JavaScript to show and hide pieces of information (for example, in a tabbed box), this means the tabs that are not active at page load will not have their content indexed. If the search engine supports JavaScript, then when crawling the links on the page, if a particular link makes content visible the search engine may choose to spider that content, although it is likely to consider it less important than text that showed initially.

For (at least) this reason, you should aim for your website to display in a sensible manner with JavaScript disabled. For a tabbed box, it would make sense to show each tab in the markup as a heading with the contents of the tab directly beneath. When the page loads,^[60] your JavaScript can rearrange the page as need be, and attach the classes necessary to set up the tabs properly. As we mentioned before, this is a good approach for accessibility, too; if you make your site semantic and accessible, you get some SEO thrown in for free.

Another thing search engines are valuing more and more is the performance of your website. If your site downloads fast and validates, you can get an easy boost in your rankings. If you have been following the guidelines laid out in this book, hopefully your CSS is small and fast and you don't have too many HTTP requests on the page. Using a content delivery network (CDN—see Chapter 8) can also give you a speed improvement, which the search engines will appreciate.

This chapter aimed to teach you about some of the devices you can expect your users to be using, and how best to target them. Media types and media queries are often useful, but they are not the panacea some of us might wish they were. Trying to keep your site easy to read and browse from the word go will pay dividends in these scenarios.

The next chapter is concerned with the performance of your CSS, and intends to teach you about how HTTP requests and responses work, caching strategies, and how to get the best out of both.