iPad Orientation CSS (Revised)

It doesn’t take much foresight to anticipate that with the rise of Natural User Interfaces (NUIs) like the iPhone and iPad, UI designers will have a greater responsibility to optimize for orientation-based contexts. As such, it’s quite prescient that today, the folks at Cloud Four demonstrated how to serve up stylesheets based on device orientation.

Since I have a feeling I’ll be using this quite a bit in the future, I wanted to build on Cloud Four’s work and find a way to alleviate the following issues:

Extra HTTP requests
Not iPad-specific
Lack of reusability

So, without further ado, here’s my proposed revision to the iPad orientation CSS:

<!-- css -->
@media only screen and (max-device-width: 1024px) and (orientation:portrait) { 
    .landscape { display: none; }
}
@media only screen and (max-device-width: 1024px) and (orientation:landscape) { 
    .portrait { display: none; }
}

<!-- example markup -->
<h1 class="portrait">Your device orientation is "portrait"<h1>
<h1 class="landscape">Your device orientation is "landscape"<h1>

As you can see, I’ve also changed the markup in a predictable way. An explanation of the changes and the reasoning behind them can be found below.

1. Extra HTTP requests

Depending on how much work you put into crafting and taking advantage of orientation-based display, you could have entirely different layouts contained in landscape.css and portrait.css. Since extra HTTP requests can bog down page-load time, it would be better performing to embed the media queries into a single stylesheet, if not your main stylesheet as follows:

@media (orientation:portrait) { } @media (orientation:landscape) { }

The orientation-specific code could then be inserted in between the curly braces. Note that I’ve also removed the “all and” at the beginning of the media query — this is acceptable shorthand per the W3C spec. For more information on CSS3 media queries, please reference the W3C Candidate Recommendation.

2. Not iPad-specific

This CSS targets devices based on their orientation, or (as the W3C explains) based on whether the height of the device is greater or less than the width of the device. What if you only want to target the iPhone and/or iPad and not browsers though? I’m not advocating making Apple devices the new Internet Explorers, but there’s some value in having greater control of your presentation, should you need it.

I posted recently on how to serve up iPad-specific CSS using media queries. To do so, you would change your media queries to target only devices with the “screen” media type that have the maximum device width of the iPad:

@media only screen and (max-device-width: 1024px) and (orientation:portrait) { }


@media only screen and (max-device-width: 1024px) and (orientation:landscape) { }

By extension, if you wanted to serve up iPhone and iPad-specific CSS, you would change your media queries to the following:

@media only screen and (max-device-width: 1024px) and (orientation:portrait), only screen and (max-device-width: 480px) and (orientation:portrait)  { }


@media only screen and (max-device-width: 1024px) and (orientation:landscape), only screen and (max-device-width: 480px) and (orientation:landscape)  { }

3. Lack of reusability

Using classes instead of ID’s to denote orientation-based styles would make it a little easier to manage the logic.

<h1 class="portrait">You're Viewing in Portrait Mode<h1> <h1 class="landscape">You're Viewing in Landscape Mode<h1>

I’m sure Cloud Four didn’t intend to establish ID’s as a convention for this functionality in their example, but I think considering reusability here is important. How can we make sure the “portrait”/”landscape” semantics are all that’s required to potentially display completely different layouts? Just apply the appropriate classes to whichever elements you want to target with a specific orientation.

Having to duplicate code is cringe-worthy, but understandably necessary if we need to replace content and don’t want to use Javascript. What if, however, instead of replacing content, we want to repurpose the existing content? For example, we might want to change the width of an element based on orientation without replacing it wholesale. In this situation, I don’t believe using classes to abstract the logic is appropriate; all of the styling should be directly targeting the elements from the orientation conditional CSS:

<!-- css -->
#content { width: 960px; }
@media only screen and (max-device-width: 1024px) and (orientation:portrait) {   
    #content { width: 720px; } 
}

<!-- markup -->
<div id="content"></div>

Conclusion

The mechanics of optimizing presentation should be fairly invisible to the user. If possible, we should be able to do nothing but tweak static parts of fluid layouts to better accommodate different device widths; however, that doesn’t mean we should overlook opportunities to better optimize content for the user. And while the iPad might not be the spawn of unicorn and wizard, it’s certainly different.

It’s a mobile device that has the potential to be used as often and in as many contexts as a smartphone, but introduces a whole host of additional accessibility scenarios to worry about.

It has a screen size we’re accustomed to designing for, but that’s not an excuse to stop supporting non-iPhone mobile users.

It supports web standards.

Its interface presents us with novel ways of delighting users, but might lead us to fail less-privileged users whom we’re not as interested in designing for.

More than ever, we are accountable to our users as vanguards of usability, accessibility and progressive enhancement. So let’s keep moving forward, and let’s keep providing best-in-class interfaces for everyone, everywhere.