Monday, December 19, 2005

Retrofit your Web pages for wireless compatibility

If you're like many Web developers, you have no idea how to ensure that your Web pages are accessible to wireless devices. Because you probably don't want to maintain Web and wireless versions of the same site or take on the overhead of Extensible Markup Language (XML) transformations, this article shows you a more practical approach to wireless compatibility. With some well-designed XHTML, a bit of CSS, and the media attribute, you can do wonders.

The days when Web pages were viewed only on Web browsers are long behind us. In fact, even the days when Web pages were viewed mostly on Web browsers are coming to an end. With hundreds of mobile devices available and millions of them in use -- most now Internet-capable -- it's almost assured that if your Web site or application is popular, it will be viewed on a mobile device. As a Web developer, the question is how far are you willing to go for wireless? Most Web developers don't particularly want to take on a second specialization in wireless development, but trends show that you do need your Web pages to be usable by wireless devices -- so what are your options?

Developers already using XML for their site or application code will probably do best to stay on that track and use Extensible Stylesheet Language (XSL) stylesheets for wireless formats. Those dependent on wireless traffic may benefit from building multiple versions of the same site. But the rest of us need less costly options -- preferably ones that let us use what we've got, rather than starting from scratch.

In this article, I'll show you an easy way to upgrade your Web pages for wireless compatibility. If you're already coding your Web pages using HTML 4.01 Strict or XHTML and styling them with CSS, then you've done more than half of the work of making them accessible to wireless devices. What's left to do, as you'll see, is a breeze.

First, a little background

The following technologies should be familiar to you if you're doing serious Web development, but just in case, here are the basics:

Assuming you've got a "plain vanilla" Web site, you're probably using some mixture of HTML 4.01 (the current standard) and a bit of older HTML, as well as possibly a little bit of CSS. The first thing you'll need to do is upgrade your Web pages to something a little more strict, as I'll explain below. (If you're already using HTML 4.01 Strict or XHTML you're ahead of the game -- jump to "Getting started.")



Back to top


From HTML to XHTML

If you don't already know it, HTML is on the move. The presentation HTML most Web developers cut their teeth on is nearly phased out, with newer versions like HTML 4.01 Strict and XHTML 1.0 being readily adopted by newer (and especially Web 2.0) browsers. If you're not already up on the different versions of HTML and XHTML you might want to check out an introductory article or book on the topic (see Resources). Basically, today's HTML falls into the following categories:

Aww, why so strict?

You might be thinking, "Why go to HTML Strict, as long as I'm using CSS for all my styling and presentation?" This classic I'll discipline myself argument never actually pans out -- at least not over the long term. No matter how disciplined you are, if you can make a quick change here or there with presentation HTML, you eventually will. By moving to HTML 4.01 (and XHTML 1.0) Strict, you're restricting yourself: you can't use presentation HTML, no matter how much you might want to. More importantly, when the boss is screaming at you to get that menu changed from green to blue, you'll take the time to make that change in your CSS, not your markup.

The benefits of XHTML

If you're serious about supporting wireless devices, you need to be using at least HTML 4.01 Strict for your Web pages, and you should seriously consider moving to XHTML 1.0 Strict. Getting to HTML 4.01 Strict forces you to drop any presentation in your HTML in favor of CSS, which is the first step to good, flexible Web design. CSS is also essential if you want to build Web apps that easily support wireless devices, because you can apply one CSS set of rules for Web browsers and another for mobile devices.

After you've moved to HTML 4.01 Strict (if you're unsure about how to do that, see the Resources section for relevant links), you'll want to think seriously about moving to XHTML 1.0 Strict. XHTML is simply the most current version of markup around, and that carries with it some significant benefits:

As an additional bonus, more and more wireless devices are providing support for XHTML. While that doesn't necessarily mean that these devices won't support HTML 4.01 Strict, it does mean that they're going to support XHTML specifically, and as you move to XHTML 1.1 and the new wireless modules in that version of XHTML, you're going to get significant advantages over using just HTML 4.01, even with the CSS techniques discussed in this article.



Back to top


Getting started

For the purpose of the examples, I'll assume you've upgraded to HTML 4.01 Strict or XHTM 1.0 Strict. The first step after you've upgraded your HTML is to be sure you supply a DOCTYPE for the page. Listing 1 shows the DOCTYPE for HTML 4.01 Strict.


Listing 1. Using the HTML 4.01 Strict DOCTYPE





                     "http://www.w3.org/TR/html4/strict.dtd">

 
   
   Simple HTML Page



This should be the first line in your HTML document, before the html element. You should also include the meta tag, which specifies your character set: the W3C validator (discussed below) doesn't like not knowing the encoding of your document.

Listing 2 shows the DOCTYPE for XHTML 1.0 Strict.


Listing 2. Using the XHTML 1.0 Strict DOCTYPE



   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

 
   
   Simple XHTML Page

IE and the XML declaration

XML gurus will wonder why Listing 2 doesn't have the XML declaration, the line that starts with . Unfortunately, Internet Explorer (only the world's most popular browser) chokes on that line, so you must ensure that the first line of your XHTML is the DOCTYPE line, not the XML declaration.

You'll notice a few differences in the XHTML compared to the HTML, but you should be able to figure them out fairly easily. The biggest change is that XHTML requires you to close all your elements (use, for example, and
instead of and
), and you'll also need to add the xmlns attribute on the html element. A good book or article will guide you through these semantic details. See the Resources section for pointers.

Can you validate that?

It's one thing to say you're going to upgrade your pages to a specific version of HTML or XHTML; it's another to actually get them there. Rather than just reading some articles, making a few changes, and assuming you're done, you should always validate your files. The World Wide Web Consortium (W3C) defines all the standards being discussed in this article, and its validator tool lets you check your HTML or XHTML and make sure you're compliant.

After you have your DOCTYPE in place, surf on over to the W3C Validation Service. There you can upload your files (or paste in the source), and validate them. Figure 1 shows a successful validation; this will let you know for sure that your page meets the standard you're going for.


Figure 1. Validating XHTML and getting the green light
A valid document results in green messages
One at a time

When you're validating and dealing with errors, fix them one at a time. The validator often reports one error, and then successive errors show up as a result of that initial error. So don't bother trying to go down the entire list; instead, fix one error, re-validate, and see if that clears up other problems (it usually will).

Making mistakes is a pain, although it's common enough, and almost always the first step between starting and finishing. In cases where your HTML or XHTML is invalid, the W3C validator gives you red error messages like the ones in Figure 2.


Figure 2. Validating XHTML and getting a list of errors
An invalid document results in red error messages

When you get messages like this one, don't worry -- just use them as a guide to fixing what's wrong with your page, and then re-validate until you get the nice green message shown in Figure 1.



Back to top


And then there was CSS...

After you've removed all the presentation code from your page (with the help of the W3C validator), it's time to add in some CSS. Like HTML and XHTML, CSS has tons of great features, but for the purpose of this article you need to follow two basic steps:

  1. Move all of your CSS into one (or more) external stylesheets, ending in a .css extension.
  2. Reference your stylesheets in your HTML or XHTML using a link element.

I'll take you through all the steps of moving your CSS to external files in just a second, but first let's concentrate on getting that all-important link right. Listing 3 shows the XHTML to link correctly to an external stylesheet.


Listing 3. Linking to an external CSS stylesheet




                     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

 
   
   Simple XHTML Page





Back to top


Setting up external CSS

Moving your CSS code into external stylesheets is the key to making your Web pages accessible to wireless devices. External stylesheets can be easily applied to different presentation environments such as Web browsers and wireless devices. The steps are as follows:

  1. Move all your CSS into external stylesheets (that is, dump it from inline code).
  2. Segregate your stylesheets into logical groupings: one for browsers, one for wireless devices, one for printing, and so forth.
  3. Use the media attribute on the HTML 4.01 or XHTML link element to assign specific stylesheets to different viewers of your page.

As you're in transition to external stylesheets it's also a good idea to think about stylesheet naming. A typical CSS stylesheet is named something like lounge.css or starbuzz.css or perhaps my-site.css. There's nothing wrong with that, although -- as you'll see in the next few sections -- there's nothing particularly great about it either.

When you start to develop CSS stylesheets for each type of device you serve, you're going to want to name stylesheets according to both the site or purpose they serve (like "lounge" or "starbuzz"), and the type of device they style for. So for your core sheets, you might want to consider a name like lounge-web.css or starbuzz-web.css. This makes it very clear -- to you, to colleagues, and to that new junior programmer who just got hired and knows nothing about your systems -- that the purpose of that particular CSS stylesheet is to serve Web browsers (or at least clients that access the Web traditionally). You could even use something like lounge-browser.css if you wanted to really be specific. This may seem like overkill now, but it's about to really pay off.

Let's see what happens as I follow the steps to move from inline CSS to external stylesheets.

1. Dump inline CSS

The first thing you need to do is get any inline CSS out of your pages. Listing 4 shows a typical HTML page with CSS added to the beginning of the page.


Listing 4. Inline CSS








 
 
 elisabethfreeman.com





There's nothing particularly wrong with this page: it works great, looks good, and uses CSS for presentation instead of deprecated HTML. However, the CSS is applied to this page for every type of viewer, whether it's a printer, Web browser, mobile phone, handheld, or aural screen reader. That's the problem with inline CSS -- it's tied to the page and is thus largely inflexible. Fortunately, the switch to external stylesheets is relatively simple, as shown in Listing 5.


Listing 5. Moving to external CSS







 
 
 elisabethfreeman.com
         type="text/css" href="ef.css">





In Listing 5 you can see that a fairly small change adds a lot of flexibility. The external stylesheet can easily be applied to all the pages on your Web site or application (or all the pages in a particular section of your site), resulting in a nice, uniform look and feel. More importantly, moving all that inline CSS into external files sets you up nicely for using multiple stylesheets.

2. Group stylesheets

Lots of times you'll find that in one stylesheet you end up with hundreds -- and sometimes even thousands -- of rules. There's nothing particularly problematic about that (other than the maintenance nightmare), but using multiple stylesheets lets you break up your stylesheets a little more logically. Putting all your table-related rules in one sheet and your core HTML rules in another (for example) will make your site a lot easier to maintain, because a two- or three-hundred-line sheet is much easier to read than a single sheet that encompasses every single rule.

Things get more interesting when you decide that you want your overall site or application to have a common look and feel, but you want some pages or sections to be differentiated. For this, you might have a basic sheet that lays out the rules for all pages, and then particular sheets that add or modify those rules for certain sections. For example, consider a setup like this:

Applying multiple stylesheets

After you've set up multiple stylesheets you can simply reference more than one link element in a page. Listing 6 shows a single stylesheet for the heading section of the core site's pages.


Listing 6. Using a single stylesheet



  
 Welcome to Cyber-Autos, Inc.


If you wanted to work on the financing section, though, you'd want to apply both the core sheet and the finance sheet. That's trivial after you've set up external CSS and grouped your rules into multiple stylesheets. You just need to add another link element in, as shown in Listing 7.


Listing 7. Applying more than one stylesheet



 
 Cyber-Autos, Inc. :: Apply for Financing


Are you starting to see the power of external CSS with multiple stylesheets? Augmenting the rules in one sheet with another makes it easy to define different layers of styling. And, because the rules in later sheets override rules in earlier ones, you can easily pick and choose from existing rules as you create new pages or sections, or upgrade your site's look and feel. (For example, you might choose to use 80 percent of the core rules for a redesign but redefine a few rules for a new look and feel.) The result is a highly configurable site that offers a uniform look and feel and lets you define differences between logical sections.

3. Assign stylesheets to different viewers

So far, the tricks I've shown you mostly apply to normal Web development -- using the most current HTML or XHTML and external stylesheets to make your pages nice and organized. Now it's time to think about making the pages accessible to different viewers. You've already seen the basics of using the link element to link to external stylesheets (in Listing 3 and Listing 7), but here's where it becomes even more powerful. Adding the media attribute to the link element allows you to indicate the viewer type to be assigned to each stylesheet. The most common values for this attribute are as follows:



Back to top


Working with different media

So, suppose you have a highly graphical site -- maybe the flashy opening section of that automotive site, with pictures of cars and descriptive text -- and you want to allow for printing. You obviously want to strip out most of the formatting, which either won't show up on a printer at all or would look terrible. So, you create a new stylesheet called auto-print.css that sets the basic font to a serif style (generally considered the best type of font for print), and focuses on the text. To ensure that auto-print.css is used for pages to be printed you would add the second link element shown in Listing 8.


Listing 8. Adding a stylesheet for printing




 Cyber-Autos, Inc. :: Welcome
 
    media="print" />


That's simple enough, right? Now let's say that you also want to add a wireless stylesheet into this mix, so that users checking out your automotive site from their Treos could get some useful content. Obviously, there's a lot to be said about laying out a site for wireless visitors, but for the sake of this first example, let's just say you decide to strip out all formatting for a streamlined, bandwidth-light version of your site. Listing 9 shows how you would link to a stylesheet for wireless devices.


Listing 9. Adding another stylesheet for wireless devices




 Cyber-Autos, Inc. :: Welcome
 
 
    media="handheld" />


Don't forget to set the media type!

Listing 9 looks pretty good, but it presents a hidden problem. Do you remember what the media type defaults to if none is specified? It's all. So the first link, which refers to auto-core.css, is automatically applied to all viewer types. And, as you may recall, when multiple stylesheets are specified, they're combined, with rules in later sheets overriding rules in earlier sheets.

Given the current code, the printing and handheld device pages will be styled by their individual stylesheets (auto-print.css and auto-wireless.css, respectively), but they'll also take on the rules of auto-core.css. That may be what you want -- uniformity, right? -- but it's probably not. If auto-core.css adds any background images, or performs absolute positioning, or even sets the color or style of fonts, some of these styles will likely "bleed" into your printable or handheld device pages. Because you don't want to mess up an otherwise great looking page on a specific device, you need to specify the media type on the core stylesheet, as show in Listing 10.


Listing 10. Setting the media type




 Cyber-Autos, Inc. :: Welcome
 media="screen"/>


This small -- and easily forgotten!-- change will ensure that auto-core.css is applied only to browsers, leaving auto-print.css and auto-wireless.css to handle all the styling for the devices they target. The result is a better site with more specific styling for different devices. Perfect!



Back to top


Wireless design notes

After you know how to apply a specific set of CSS rules to wireless clients, you've got to do some thinking about what to show to those clients. Unfortunately, this is largely application- and page-specific work. In other words, there's no basic set of rules for making Web pages suitable for display on wireless and handheld devices.

I'll spend the remainder of the article looking at some of the basic principles and common problems you should consider when styling your Web pages for viewing on wireless devices. Before I even start on the design notes let me reiterate the essential lessons learned in the first half of this article: If you have presentation code in your HTML itself, you're in for a world of hurt; it will be nearly impossible to manage good design for different devices. Before spending hours tweaking your CSS for a handheld, make sure that your pages use completely HTML 4.01 Strict (if not XHTML 1.0 Strict) markup, and that you've correctly set the media type up on your link elements. With those things done your pages are set up to work across wireless devices, and what's left are the actual design considerations.

Slim, low, little

Wireless devices have slow network connections and little room for display. If you're serious about wireless compatibility you need to design your Web pages accordingly. The many things you can do to help wireless displays fall into three basic categories:

  1. Create or style a version of your site that is slim and will fit on narrow device screens.
  2. Provide low-bandwidth versions of your site.
  3. Get the most important content on the initial screen of your little handheld; it's problematic to scroll down on phones.

So for example, you should consider dropping out all images in your stylesheet rules for handhelds; the less images a handheld has to load, the faster your pages will appear. If you need a small banner image, that's probably okay, but showing fancy backgrounds or stylized content just doesn't make sense on handheld devices.

But my phone supports ...

Plenty of newer phones and phone-organizer hybrids support frames, Flash, Java™ plug-ins, JavaScript, and other such fancy features. If you write your code with such devices in mind, however, you leave the majority of users behind. Not everyone can afford a $500 wireless device. If you're aiming for true wireless compatibility you need to support mainstream Nokia phones as much as you do high-end devices like Treo, Blackberry, and Sidekick.

You should also avoid using frames, as well as fancy menus and scripts. If you provide menus and scripts on your screen-viewed site, be sure to set your CSS to fall-back to text versions of menus and remove scripts for wireless devices. Frames are a bad idea in any environment, so just avoid them completely.

In addition to avoiding scripts, you should assume that handheld devices aren't going to work with Flash animations, Java plug-ins, events in JavaScript like onClick or onBlur... unfortunately, the list of unsupported things just goes on and on. In general, you need to ensure your sites are simple, mostly text, and stick to a one-column design if you want to ensure good wireless device compatibility.

A tiny little window...

To address the narrow width of handheld devices, consider using the CSS max-width property, as shown in Listing 11.


Listing 11. Setting the maximum width for handhelds




body {
 max-width:  200px;
}

div#content {
 max-width:  100px;
}

div#links {
 max-width: 50px;
}


This ensures that your pages stay slim, and fit in typical handheld windows. You may also want to hide portions of your page that aren't needed. For example, if that fancy logo and footer just aren't really needed on wireless devices, use display:none; see Listing 12 for a simple example.


Listing 12. Hiding non-essential elements




body {
 max-width:  200px;
}

div#content {
 max-width:  100px;
}

div#links {
 max-width: 50px;
}

#menu {
 display: none;
}

#footer {
 display: none;
}



Consider using similar rules to shrink down banner images (remember, you're removing any other non-essential images), hiding extraneous text, using text-only images, and anything else you can think of to create small, handheld-friendly displays.

The classic div problem

The classic div problem is worth knowing about if you ever need to convert a highly dynamic site to wireless-capable views. To start, take a look at Listing 13, which shows a typical div-based XHTML page. It's made up of several basic sections:


Listing 13. A typical div-based XHTML page




                      "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">


 
 Cyber-Autos, Inc.
 
 
 


 

 

 

   
Welcome to Cyber-Autos!

   

 


 

]]>


For the screen, you might float the sidebar over to the right (in fact, that's a very typical approach), meaning that the main body content appears on the left. In other words, CSS is used to position the divs on the screen, rather than their position within the actual XHTML file. That's problematic on a handheld, however, because you're not going to be able to use absolute positioning and float -- at least, not if you want to support more than the latest handheld devices.

The typical handheld device reads your XHTML from top to bottom (no surprise here, right?) but absolute and relative positioning, as well as floating divs, are dicey at best on handheld devices. So no matter what you have in your CSS, the handheld would read a page like Listing 13, and show first the header, then the sidebar, and finally the main section. To avoid this problem you may have to make changes to the structure of your XHTML. Even though you shouldn't code presentation into your XHTML, you occasionally may have to make changes to that structure that have an effect on presentation (it's a subtle difference, but a difference nonetheless).

If you looked at the div-based page shown in Listing 13 on a handheld, you'd see an image at the top (which is almost certainly unnecessary on a wireless device), then the menu and further information links, and then -- finally -- the main page content. To get around this, first consider completely hiding the header (using display: none). After you've removed the image (which really has no bearing on a handheld) you can insert text instead, or just count on the page title to do the job. Next, you might want to hide the entire sidebar section. Alternatively, you could move that div below the main content, which is where your structure does have some bearing on your content. Because wireless devices -- or devices that don't support CSS in full -- read the page in order, you should try to position important content as high on the page as possible, so it's seen first.

As a corollary, items that are temporary (like a special deal) or less important (advertisements for a sister company or division that sells tires, for example) should be placed lower on the page. They'll be below the visible screen on most handheld devices, but you can use CSS to move them nearer the top of the page -- or to different columns -- on CSS-capable viewers.



Back to top


In conclusion

Obviously, there are as many ways to handle the demands of wireless devices as there are actual devices! In many cases, you will actually be able to tailor your approach to serving wireless content to the types of phones or handhelds you're targeting. For example, if you know that you're only serving content to internal employees, and they're all carrying Blackberry or Treo devices, you may choose to get a little fancier, or just allow the devices to download an XHTML mobile application (something that's beyond the scope of this article, but referenced in the Resources section). If you're serving content to every possible phone and device, however, your solution will obviously have to be more general.

The ideas in this article are best suited to existing Web pages that need to support -- at least to the degree possible -- wireless devices with minimal changes to the pages. You can do a lot more by designing wireless sites or apps from scratch, or by creating complicated Website Meta Language (WML) or VoiceXML applications specifically for phones. The technique I've demonstrated here is for situations where you don't have the time and resources for such solutions, or where the handheld isn't the company's primary target. In these cases you can get by with just a little CSS and some well-planned page layout.



Back to top


Resources

Learn

Get products and technologies

Discuss


Back to top


About the author

Photo of Brett McLaughlin

Brett McLaughlin has worked in computers since the Logo days. (Remember the little triangle?) In recent years, he's become one of the most well-known authors and programmers in the Java technology and XML communities. He's worked for Nextel Communications, implementing complex enterprise systems; at Lutris Technologies, actually writing application servers; and most recently at O'Reilly Media, Inc., where he continues to write and edit books that matter. His most recent book, Java 5.0 Tiger: A Developer's Notebook, is the first book available on the newest version of Java technology, and his classic Java and XML remains one of the definitive works on using XML technologies in the Java language.



source:http://www-128.ibm.com/developerworks/wireless/library/wi-css/?ca=dgr-lnxw01WirelessPages


# posted by dark master : 12/19/2005 10:14:00 AM
Comments: Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?