Targeting small screens

Early last week, I spoke to packed crowds at Web Design World in Boston. Clearly the conference scene is heating back up, as budgets for events and off-site training seem to be reappearing. The two sessions I presented (“Beautiful Interfaces with CSS” and “Throwing Tables out the Window“) were lots of fun. I had to bolt to the airport to catch a flight after my last talk. So I didn’t get to stick around to see the rest of the conference or talk to more of the attendees over the next two days.

However, I got to field a few questions from those who came up after each session. All questions were good, and quite relevant to what many of us do every day. Considering this, I thought I’d start sharing some of the questions people are asking after these conferences, along with my extemporaneous responses — sometimes informed, sometimes not so well-informed.

I don’t always have the answers on the spot, but I like to help find the answers when I can. And I think it’s helpful to know what our peers are asking about. If anything, these questions form the base for interesting discussion, and they pull in other people who can help provide answers or steer you and me in the right direction.

One question in Boston dealt with how to address portable devices (like phones and PDAs). Specifically, [my own paraphrased version] this gentleman was frustrated over certain devices, like the Pocket PC, which ignores style sheets linked with a handheld media type, but tries to apply any screen media type style sheets. It badly bungles portions of CSS, breaking the display of a style sheet intended for larger desktop browser windows. He would be fine if there was a way to hide screen media type style sheets from mobile browsers like we typically do with Netscape 4. But Pocket PC’s weakened support of CSS, along with trying to fit a larger desktop browser design into a small window, left him wondering what choices he had.

I’ve heard similar complaints in the past about the browser on Danger’s Hiptop.

First, my thoughts on why most mobile browsers don’t currently support the handheld media type. Then a potential solution for the short-term until they do. (I should state that these are completely my own observations and theories, and I’m an outsider to the entire mobile industry.)

Show of hands for handheld support?

So why isn’t the handheld media type supported more widely by now? Why aren’t mobile browser software companies doing the right thing from the start?

We’ve seen an explosion in the last year of mobile phones and PDAs that support web browsing (to some capacity). They’re doing a better and better job of it. Companies who make the browsing software for these devices want everyone using them to have the “richest” possible experience when they attempt to browse the web. If mobile browsers rendered a web page like it was 1996 without any styles applied — as would be the case with most sites that don’t offer a handheld style sheet — there would be a harsh disconnect between what people knew a certain site looked like viewed with their desktop or laptop computer, versus what it looked like on their phone or PDA. Some of the branding and familiar design elements of the site might be lost if mobile browsers didn’t attempt to render everything they could. These browsers render as much of the style for each site as they can. This often leads to problems for developers who try to do the right thing by supplying a handheld media type style sheet.

It’s a chicken and egg thing. Mobile browser software companies aren’t building in support for the handheld media type because virtually no sites are authored with a handheld media type style sheet — yet. However, designers and developers won’t start using the handheld media type until they know there are at least a few mobile browsers that reliably support handheld style sheets, and can immediately see the benefits of providing these additional style sheets.

Clearly, this mobile browsing thing isn’t another flash in the pan. It’s here to stay and it’s only getting more popular. We need to account for the millions of mobile devices attempting to hit our sites. And we need to be designing and building our sites to work everywhere. This includes devices for people with disabilities as well as mobile and all other forms of utility browsers we haven’t even seen come to market yet.

We don’t want to go back to 1997, where we had to build different versions of our sites for each new browser that entered the market. True, in some cases, sites may need to be customized for the best mobile experience, and this may mean a completely different architecture, let alone HTML structure. But when we have the chance, we want to optimize the design or presentation of content based on what type of device is used to view that content.

Things needs to change. It requires action from both browser makers and the designers and developers creating the leading-edge sites. Those sites set examples for everyone else. Neither side needs to think whether or not to go first, they just need to go.

Before I continue, I should note at least one company whose browser correctly supports the handheld media type. Opera has taken considerable steps toward dealing with the challenges of rendering web pages on mobile devices with its Small-Screen Rendering technology. For the majority of web pages that aren’t yet using handheld style sheets, Opera will optimize the page using its SSR technology. However, when Opera detects a page with an existing handheld media type style sheet, Opera assumes the author optimized the page for small screens, correctly applies the handheld style sheet, and disables SSR so as not to interfere with the author’s intentions. So in Opera, pages styled with handheld style sheets render as the author intends. But pages without a handheld style sheet get the SSR treatment. A brilliant fallback solution.

Until that day…

Even as Opera sets a good example, what about other browsers that aren’t yet supporting the handheld media type? How do we design and author our sites with robust style sheets applied to the same basic HTML, forming an attractive, usable site no matter what type of browser or device is used to access the site?

My response to this gentleman involved using JavaScript to force support for handheld style sheets and detect a screen size smaller than X. Some of you may not prefer to use JavaScript for browser type or window-width detection. But until more mobile browsers support the handheld media type, we need some type of proactive fallback solution so we can effectively target small screens and optimize designs for them.

I first suggested he go ahead and add a secondary handheld media style sheet. Then use JavaScript to detect smaller screen sizes. If detected, change the secondary style sheet to both screen and handheld, adding to (and overriding) the default screen media type style sheet. The secondary style sheet (intended for mobile browsers) might contain rules that eliminate floats and absolute positioning used for page layout, and remove any fixed widths for columns and containers. Ideally, a handheld style sheet allows the design to shift to a one-column flexible-width layout that shrinks or expands to fit available screen width.

The problem with my first suggested approach? Many of these new mobile browsers don’t completely support JavaScript yet — if at all. Others disable JavaScript by default for security or “user convenience” purposes. Bah humbug!

Take two

So how about the inverse of that approach?

What if we started by applying a very basic style sheet as both screen and handheld media types. The basic style sheet would only apply simple rules for color, typography, link treatment, and simple list styling. No complex floated columns or absolute positioning. This style sheet would take care of all CSS-supporting devices, whether or not they support the handheld media type.

Then, we use JavaScript to detect wider browser widths — those that might typically imply a desktop browser. If JavaScript is supported, and a wide width is detected (say 620px or greater — or maybe even 750 if your design only works at 750 or greater), then we assume not only a desktop browser, but that enough window real estate exists to render a multi-column design as intended. In this case, we add the main style sheet that divides the page into our standard multi-column layout. Browsers that either don’t support JavaScript (or where it’s been disabled) or browsers that don’t report wide enough screen size only get the basic style sheet.

Seems like that would work. Of course I only know enough JavaScript to hack my way through existing code, not enough to write my own from scratch. So I’m not even going to attempt to write something or create a test example. Others should feel free to suggest or create code, or test this approach however possible.

I’ll note that this is a very similar idea to the solution Cameron Adams recently devised for the opposite problem: how to provide more content or more design when the browser window is extra-wide. (See his Resolution dependent layout, 21 Sep 2004.) In this case, I’m simply recommending going back one step before what Cameron is doing. A simple, basic style sheet is applied as both screen and handheld media types, and takes care of the lowest common denominator that still supports CSS. Then detection of wider window widths results in the application of a more advanced style sheet that breaks the page into multiple columns. Then Cameron’s idea enters in for applying yet more styles for ultra-wide window widths.

Killing the FOUC

One important note if all the above is possible. I might also suggest setting a cookie with JavaScript if a wider window width is detected. Once a cookie is set, server-side code could check for the cookie on subsequent page views, and determine whether or not to add the main style sheet (or not) before resulting HTML is streamed to the client. This way, we avoid the FOUC for any page beyond the first page view.

Feedback, expansions, modifications, pitfalls? Code samples, examples, or other ideas?