We’ve been able to define media-specific style sheets for quite a while, but we’ve been limited to the type of output, as you saw In Making Links Printable with :ajter and content, on page 83, when we defined our print style sheet. CSS3’s media queries6 let us change the presentation
of a page based on the screen size our visitors use. Web developers have done screen size detection for years using JavaScript to obtain Information about the user’s screen size. But we can start to do that with style sheets alone. We can use media queries to determine the following:
• Resolution
• Orientation (portrait or landscape mode)
• Device width and height
• Width and height of the browser window
Because of this, media queries make It very easy for us to create alternative style sheets for mobile users.
It turns out that the AwesomeCo executive staff have all just dumped their BlackBerry devices for shiny new IPhones. The marketing director would love to see an IPhone-ready version of the blog template we built In Redefining a Blog Using Semantic Markup, on page 27. We can do that very quickly.
Our current blog Is a two-column layout, with a main content region and a sidebar. The easiest way to make this more readable on the IPhone Is to remove the floating elements so that the sidebar falls beneath the main content. That way, the reader won’t have to scroll sideways
on the device.
What About the Handheld Media Type?
The Handheld media type was designed to let us target mobile devices like we target printers, but most mobile devices want to show you the “real Internet” and so they ignore that media
type, serving the style sheet associated with the screen media type instead.
To make this work, we’ll add this code to the bottom of the blog’s style sheet:
@media only screen and (max-device-width: 480px) {
body{
width:460px;
section#sidebar, section#posts{
float: none;
width: 100%;
You can think of the code we put within the media query braces as its own style sheet, invoked when the conditions of the query are met. In this case, we resize the body of the page and turn our two-column layout into a single-column layout.
We could also use media queries when we link the style sheet, so we can keep our mobile style sheet in a separate file, like this:
<link rel=”stylesheet” type=”text/ess”
href=”CSS/mobi le. ess” media=”on7y screen and (max-device-width: 480px)”>
With that, our blog immediately becomes more readable on the iPhone. You can use this approach to build style sheets for other displays as well, such as kiosks, tablets, and displays of various sizes so that your content is readable in more places.
Falling Back
Media queries are supported in Firefox, Chrome, Safari, Opera, and Internet Explorer 9. You’ll have to rely on JavaScript fallback solutions to load additional style sheets based on the user’s device. Our example targets iPhones, so we don’t need a fallback solution—our content is readable without the media query.
However, if you want to experiment with media queries in other browsers, there is a jQuery plug-in7 that adds basic media query support to other browsers. It’s limited in that it works only with linked style sheets, and it only supports min-width and max-width in pixels. Even with those limitations, it works very well for creating different interfaces for different window sizes.
The Future
The things we talked about in this chapter improve the user interface, but people can still work with our products if their browsers don’t support these new features. People can still read the data in the table if it’s not styled with stripes; the forms will still work, even if they don’t have
rounded corners on the interface elements; and the newsletter won’t be laid out in multiple columns. It’s good to know that we can use the presentation layer to achieve these effects instead of having to resort to JavaScript or server-side solutions.
Almost all browsers support these selectors now, with the exception of Internet Explorer. As we move forward, you can expect to see IE moving to support these as well, especially the pseudoclasses. When the specification becomes final, the vendor-specific prefixes like moz
and webkit- go away. Once that happens, you’ll be able to remove your fallback code.