Mobile Web Development: Chapter 11 - Mobile Design and Development

by Brian Fling

In this chapter, I discuss the foundational principles and techniques for creating designs for multiple mobile devices. As discussed earlier, the mobile web is the only ubiquitous platform for delivering content to mobile devices. This makes it an incredibly powerful platform in terms of its reach, but like most things in mobile, every blessing comes with a curse. The price for ubiquity is that not all designs are rendered the same.

Mobile Design and Development book cover

This excerpt is from Mobile Design and Development. Mobile Design and Development fills that void with practical guidelines, standards, techniques and best practices for building mobile products from start to finish, including basic design and development principles for all mobile devices and platforms.

buy button

There are two basic approaches to creating cross-platform mobile designs: content adaptation, in which you create many versions of your site, or no content adaptation, in which you don’t. In either case, you need to have a firm understanding of how to design content for the mobile context. Though I won’t discuss the pros and cons of adapting for devices until Chapter 13, for now it is important to understand that the rendering of many of the standards and techniques I discuss in this chapter are measured on a sliding scale of consistency across multiple devices.

Now this doesn’t mean that mobile standards are not standardized. Many coming from the desktop web world mistakenly assume that because a mobile browser renders elements inconsistently, there is no web standards support within the mobile web—this isn’t exactly the case. The mobile web actually has been very standardized, with defined specifications—in some cases, standards older than the specifications we use on the Web. The problem is the technical constraints of the device and the inability to update the browser technology that ships with devices. Together with low consumption of the mobile web, the problem has been somewhat ignored for years.

That all changed, of course, after the introduction of the iPhone. I will talk about some of the changes that are occurring in the mobile web and some of the techniques specific to creating iPhone web apps in following chapter, but for now I want to introduce you to the foundation of what makes the iPhone and other advanced mobile browsers successful: creating mobile experiences under extreme constraints. It doesn’t matter what mobile devices you plan to support; they will always have the same challenge. These principles and techniques were designed and honed over the years to address exactly that.

Web Standards

The first question that probably pops into your head (as it certainly does in mine as I write this) is why we need to have a chapter specifically about mobile web development at all. Isn’t that what the concept of “Web Standards” on page 162 is all about? To separate content from presentation in order to create a ubiquitous experience that can be rendered on any device or any viewing context? In a word, yes, but unfortunately it isn’t that cut and dry.

The phrase “Web Standards” on page 162 is often used to support arguments, like “you should be supporting web standards because …” but what does it really mean? By my definition, web standards is just an easy way to say “a web page based on the XHTML

1.0 and CSS 2.1 specification, coded in such a way that the majority of presentation elements are omitted from the XHTML markup and defined in the CSS instead.” Now it is typically inferred that in doing so, your markup is immediately made more usable in other viewing contexts—for instance, search engines and accessibility devices such as screen readers and mobile devices—but that is not necessarily the case, as any search engine optimization (SEO), accessibility, and mobile web expert, respectively, will quickly tell you.

A common misconception that web designers and developers have about XHTML is that it should be treated like XML, as a structural data source rather than as a tool to mark up content like XHTML and its forefather SGML were designed to be. In fact, XHTML is not the most common language used for most large-scale mobile deployments, instead XSLT, or Extensible Stylesheet Language Transformations, is the preferred choice. In this method, content is defined as XML and then XSLT are used, along with multiple markup languages like HTML, XHTML, WML, XHTML Basic, XHTML-MP, and so on, to provide the proper rendering markup for the viewing context.

Though mobile device browsers are certainly becoming better at rendering what we refer to as “standards” consistently, that isn’t to say that XHTML 1.0 and CSS 2.1 is, or even should be, the one and only means to display content on the Web to mobile devices. The beauty of the mobile web is that it can take form in so many shapes, creating highly useful tools in many contexts. Trying to rigidly adhere to web standards dogma not only hurts the mobile web, but the desktop web as a whole, setting manufactured constraints over how the Web can evolve.

As the youngest of six sons, I can attest that my parents used very different methods to rear each of us. I can’t help but to look at the web standards community in the same way in which my parents must have looked at my brothers and myself. Each of us had our path, our own direction. Trying to apply the same rules, the same method of parenting, to each of us just didn’t work. They had to adapt to each of our personalities and foster a safe environment for each of us to learn and grow at our own pace, to discover our own potential, while still teaching us the beliefs and guiding principles my parents wanted us to share.

Following my parents’ example, I tend to look at the desktop and mobile as siblings. They have a lot in common, but they are not the same—nor will they ever be. They each have their own path and their own direction, and we cannot always expect the same guidance and methods to work exactly the same on each. The best we can do is foster each of them to reach their greatest potential.

Designing for Multiple Mobile Browsers

Designing and developing for multiple mobile browsers simultaneously is a challenge, but not an impossibility. It requires looking at your designs and code from many contexts, and being able to visualize how it will be rendered on a variety of devices in your head, as you lay down code.

For example, you are creating the markup and styles for a desktop site that has to support Internet Explorer 6, which has very quirky support for web standards techniques. You would employ a different technique to express your design, one that you know is proven to be compatible on most browsers, than if you were just going to support the latest browsers. In mobile development, we have might have 10 Internet Explorer 6s, so we have to think of our design in layers of degradation, which just happens to be the definition of progressive enhancement.

Progressive Enhancement

Progressive enhancement is the practice of using web techniques in a layered fashion to allow anyone with any web browser to access your content, regardless of its capabilities. This means that you are creating not just one ideal experience, but multiple less-ideal experiences, depending on who views it, also called graceful degradation. To illustrate this, take a look at Figure 11-1 .

Our unstyled experience or markup viewed in its rendered form is at the center. We can assume that all devices can show at least this level of presentation. However, in order to m ake sense we need to ensure our markup is written semantically, in other words, it can remain useful without a presentation. Next, we add basic styling techniques for our lowest common denominator devices that support both our markup plus very basic styling techniques. We continue to add layers until we reach the best possible experience on the outside.

This can be done with or without content adaptation, although my advice is to always start your project without. It far faster and easier to start with one code base that gracefully degrades, than immediately jumping into creating multiple versions of your site.

It should be noted that you can add a desktop layer to your site using progressive enhancement. There is absolutely nothing wrong with this approach, because you built the desktop layer on top of a layer designed for the mobile context. In fact, this is something I did with the original Mobile 2.0 event site (Figure 11-2), creating a useful

mobile experience, then creating multiple layers for different viewing contexts, and ending with the desktop.

The problems arise when you go the other way around, starting with the desktop and trying to create a useful mobile experience from it. Nine times out of ten, you end up with an awkward, barely useful version of your site that is both slow and expensive to load.

Mobile progressive enhancement techniques

The following tips are tricks I’ve been using since the early days of the mobile web. Regardless of how advanced browsers have become, I still employ these five techniques for every mobile project I do:

  • Always code your markup semantically. I like to keep a live preview window open so that I can see the rendered page as I code. This way I can ensure that the page is always usable, even with no stylesheet in place.

  • Have a device plan. Know which device classes you intend to support before you start to code. This will influence how you code your pages.

  • Have both your lowest common denominator devices and your high-end device designs before you begin to code. Try to visualize a way to create both versions from one code base.

  • Test on different mobile devices from the beginning to the end to ensure that your incremental work will display correctly in the intended devices.

  • If you plan to add a desktop layer, always create the mobile version first.


Seeing a growing need to produce a standard means of markup for multiple contexts, the W3C has begun to develop a specification for a device-independent authoring language referred to as DIAL. DIAL is an XML language profile of XHTML2, shedding its SGML roots and becoming more of a means of delivering different content to different devices by using machine readable constructs to define conditions.

Take the W3C’s example:

<!-- query the requesting device's browser resolution in dpi and store in a convenience variable--> <sel:variable name="res" value="di-cssmq-resolution('dpi')"/> <sel:select>

<sel:when expr="$res &gt; 500>

<object sel:selid="Cornish Yarg" src="yarg_hi.jpg"/> </sel:when> <sel:when expr="$res &gt; 200>

<object sel:selid="Cornish Yarg-id001" src="yarg_mid.jpg"/> </sel:when> <sel:otherwise>

<object sel:selid="Cornish Yarg-id001" src="yarg_low.gif"/> </sel:otherwise> </sel:select>

In order for DIAL to work, it must pass through at least one DIAL processor in order to render the desired view for the desired device. In other words, we are talking about content adaptation, but at least we are talking about a standardized means of content adaptation. In fact, several content adaptation server vendors already favor the DIAL specification over the proprietary XSLT techniques, even though the specification is still a working draft.

Though I think this is promising technology for mobile sites planning to employ some means of content adaptation, I’m a bit skeptical. As we’ve been seeing the future of markup standards lean toward evolutionary and not revolutionary (as in the case of HTML5 versus XHTML2, which I discuss more in the following chapter), I have a feeling it will still be some time until you are coding your site in DIAL. When desktop, mobile, and other browsers all start supporting DIAL as a client side processor, I think it will start to take off. But until then most likely it will largely remain solely a content adaptation technique.

Designing for Multiple Displays

Next on my list of things to cover is supporting multiple mobile displays. It is both a design and development dilemma, but if you ask any mobile designer, it is quite a painful headache. When trying to design and develop a mobile experience, you have to remember that your design might be viewed on a small 120-pixel screen, common on most lower-end phones, or on a 320-pixel screen common to most smartphones. Depending on the type of devices you plan to support, it is entirely possible that it could be viewed on larger screens; many smartphones now can be rotated to landscape mode, increasing the view to 480 pixels. To cover all bases, I tend to look at any screen under 760 pixels, the maximum viewable size on an 800 x 600 desktop resolution, as a possible mobile device.

Fixed versus fluid designs

Traditionally, in the mobile industry developers have opted for fixed-width designs over fluid, or percentage-based, stretchable designs. Fixed-width has provided slightly more reliable rendering across devices in the past; however, the problem with fixed-width design is that it might limit the viewable content when viewed on larger screens. We are seeing a trend toward larger screens as well as the inclusion of orientation switching in device browsers. Therefore, I recommend that you make all designs fluid by default, unless you are targeting a device that you specifically know has issues rendering a fluid design.

Single-column versus multiple-column layouts

As mobile screens get larger, does that mean we can start to use multicolumn layouts? For example, should you use sidebars or vertical navigation areas? I honestly don’t know. I will leave it up to you to determine whether it is the best presentation for your users. I’ve used a user-collapsible vertical navigation area for mobile products in the past, and my users loved that they could toggle between the two. However, the vast majority of mobile designs opt for a simple single-column layout.

There are historical, technical reasons why you might not want to employ a multicolumn layout on a lower-end device: poor support for positioning or floats, not to mention that these devices typically have smaller screens, where two columns would make the page cluttered are just a couple of examples. Also, if the user has a device with a directional or D-pad, then multiple columns would creating an awkward scrolling pattern.

My rule of thumb is actually to consider whether you’re designing for touch. If your target devices support touch, then it is okay to use multiple columns, but tread forward carefully and don’t make the page difficult to use. If the device does not support touch, then opt for a single-column design.

Device Plans

Developing a mobile product means having a device plan at the very start. Effectively, you’ve defined each of your progressive enhancement layers, determining what will be that center, common experience and what layers you intend to support. Unfortunately, I’ve seen it too many times: trouble at the late stages of developing a mobile project because there was no defined device plan. The goal is to get to the test stage without any surprises. Sure, some things might not render properly, but you should at least have an idea of why it is broken. Not having a decent device plan can mean getting into the test phase and having mind-boggling bugs that you didn’t expect—and worse, no idea how to fix them.

I think of my device plan as a passage from Sun Tzu’s The Art of War:

If you know both yourself and your enemy, you can come out of hundreds of battles

without danger.

In this case, the invading Mongols trying to breach your wall are those hundreds of devices. If you know the weakness of each of the devices you plan to support, along with what you will be able to safely accomplish, then you can have many successful mobile projects.

But getting a handle on hundreds of mobile devices is no small feat. Therefore, I use a system of classifying browsers into five broad groups. Doing this gives us a feature set and requirements to work within and support.

The Device Matrix

Table 11-1 provides a listing of popular browsers and their assigned classes, starting with A, the highest grade, to be considered on par with desktop browsers, and ending with F, the lowest possible grade.

Table 11-1. The device matrix
Class Markup CSS JavaScript
Class A XHTML, XHTML-MP, HTML5 CSS2, CSS3 Great, includes DHTML, Ajax
Class B XHTML, XHTML-MP CSS2 (Decent) Limited, some DHTML
Class C XHTML, XHTML-MP CSS2 (Limited) Limited
Class D XHTML-MP CSS2 (Basic) None
Class F XHTML-MP, WML None None

Class A mobile browsers

Some of the characteristics of a Class A mobile browser are:

  • Excellent XHTML 1.0 support.

  • Good HTML5 support; specifically, the canvas element and offline storage.

  • Excellent CSS support, including most of CSS Level 2.1 (scores 90 percent or higher on the ACID2 test) and the majority of CSS Level 3 (scores 75 percent or higher on the ACID3 test).

  • Support for web standards layouts, including absolute positioning, floats, and complex CSS-based layouts.

  • Supports image replacement techniques.

  • Excellent JavaScript support.

  • Able to toggle the display property.

  • Supports DOM events, including Ajax.

  • Considered comparable to a “desktop-grade” browser.

Class B mobile browsers

Some of the characteristics of a Class B mobile browser are:

  • Excellent XHTML 1.0 support.

  • Good CSS Level 2.1 support (scores 75 percent or higher on the ACID2 test).

  • Padding, border, and margin properties are correctly applied.

  • Can reliably apply colors to links, text, and background.

  • Supports image replacement techniques.

  • Minimum screen width: 164 pixels.

  • Can support complex tables—not necessarily nested tables—up to four cells in a row.

  • Setting a font-size of 10 pixels or more produces readable text.

  • Limited JavaScript support, being at least able to toggle the display property.

Class C mobile browsers

Some of the characteristics of a Class C mobile browser are:

  • Good XHTML 1.0 support.

  • Limited CSS Level 2.1 support (scores 50 percent or higher on the ACID2 test).

  • Limited or no JavaScript support.

Class D mobile browsers

Some of the characteristics of a Class D mobile browser are:

  • Basic XHTML.

  • Limited CSS support (CSS Level 1, or does not recognize cascading).

  • Minimum screen width: 120 pixels.

  • Hyperlinks may not be colorable by CSS.

  • Basic table support: 2 x 2 or more.

  • colspan and rowspan may not be supported.

  • “Width” expressed as a percentage may be unreliable.

  • No JavaScript support.

Class F mobile browsers

Some of the characteristics of a Class F mobile browser are:

  • No (or very unreliable) CSS support.

  • Poor table support or none at all.

  • Basic forms: text field, select option, submit button.

  • May not be able to support input mask on fields.

  • No JavaScript support.


Markup is used to make content readable by mobile browsers. Normally when we think of markup, we think of HTML, or Hypertext Markup Language, the language of the Web. In mobile, we use slightly different markup languages, depending on the scope and size of your project or on your target devices.

Back in 1996, HDML (Handheld Device Markup Language) was created by Openwave, one of the early pioneers of the mobile web. It was quickly followed by Nokia’s TTML (Tagged Text Markup Language) and other proprietary markup languages, before the WAP Forum created the WML (Wireless Markup Language) specification in 1998, which was included in the WAP 1.0 (Wireless Application Protocol) specification.

Many people coming from the Web assume the mobile web works in the same way and lives on the same protocols as the desktop web does, which isn’t the case. WAP is the stack in which the mobile web lives, but it is a protocol unto itself. Saying that WAP and the Web are synonymous would be like saying that men and women are the same. Yes, they are both humans, and technically how they function is very similar to one another, but there are some fundamental and obvious differences. Mobile devices are much more like their desktop computer counterparts today, but there are still many remnants of WAP within the current operator-delivered mobile web.

WML looks more like XML than HTML, using a strict format to markup content, organized into cards, or pages; therefore an entire WML site would be referred to as a “deck,” a term still used today to describe a mobile website. As devices and networks matured, so did the markup, moving away from the XML syntax and closer to the HTML syntax, first with the cHTML used with NTT DoCoMo’s i-mode phones, then iHTML. It was followed by XHTML and XHTML Basic, which evolved into XHTMLMP (Extensible Hypertext Markup Language—Mobile Profile), a modularization of the XHTML that we all know and love, but for mobile devices. The Open Mobile Alliance (OMA) has defined XHTML-MP as the primary language of WAP 2.0 protocol, and it has been commonly used in phones since 2002.

XHTML-MP Overview

XHTML-MP is a modularization of XHTML Basic. XHTML Basic is the subset of XHTML. In other words, if you know XHTML, chances are good that you will be comfortable with XHTML-MP. Now that XHTML Basic and XHTML-MP are virtually indistinguishable, and thanks to both standards being a subset of XHTML—the standard language of the Web—the average web developer does not need to understand a language for each medium.

XHTML-MP has evolved to become the predominant language for the mobile web, and can safely be assumed to be used in devices manufactured since 2002. Operators used to require on-deck mobile websites to be coded in both WML and XHTML-MP, using WML and the fallback. Luckily, those days are long since past. However, anyone considering the creation of mobile web content for emerging markets like African countries had better brush up on their WML skills, as it can still be found in pockets that use largely recycled phones.

XHTML versus XHTML Basic versus XHTML-MP

Some of you may be scratching your heads at this point. No doubt you’ve never seen the letter X used so many times in one page. But what does this mean for you? Should you code your mobile site in XHTML, which we use on the Web? Or maybe XHTML Basic, which is on the W3C site? What about XHTML-MP that this Open Mobile Alliance I’ve never heard about recommends?

Though they are almost indistinguishable from each other, it really just depends on the devices you plan to support. You are certainly safe with XHTML-MP on any mobile device. Although more advanced devices like the iPhone prefer XHTML over XHTMLMP, if my device plan calls for consistency on lots of lower-end devices, there is no doubt in my mind that I should use XHTML-MP. And if I plan to have the iPhone being at the high end, or to add a desktop layer, I use XHTML.

Because XHTML-MP is a modularization of XHTML, many devices—even low-end devices—will support an XHTML document. It just might be a bit more flaky. So ask yourself where your users are most likely to be and go from there.

Document Structure

The following are guidelines, recommendations, and best practices to structure your XHTML-MP documents appropriately. Different classes of browsers treat each of these best practices differently, so use the following list to determine how closely you should adhere to them:

  • Class A browsers: Recommendations, not mandatory

  • Class B browsers: Best practices, should reduce inconsistencies

  • Class C browsers: Strongly recommend, veering from will increase inconsistencies

  • Class D browsers: Required, should adhere closely

  • Class F browsers: Required, but may still produce inconsistencies


Applying the XHTML-MP doctype tells mobile browsers how to render the content. Using the incorrect markup type specified by the doctype can cause content to render erratically or incorrectly. Defining the XHTML-MP doctype will provide the most reliable rendering of the page across the widest mobile devices.

For Class B and lower devices, use the following doctype:

<!DOCTYPE html PUBLIC "-//WAPFORUM//DTD XHTML Mobile 1.0//EN" "">

However, for Class A browsers, use your favorite flavor of XHTML doctype. I like XHTML 1.0 Transitional:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" " TR/xhtml1/DTD/xhtml1-transitional.dtd">

Character encoding

Correct character encoding is essential to making sure that pages render correctly on devices. Different document types require different character encodings. XML documents should always have a UTF-8 character set; documents served as MIME type text/ html should use ISO 8859-1. The following line shows how to set encoding correctly in an XML document:

<? xml version="1.0" encoding="UTF-8" ?>

Specify the correct character encoding for your pages; otherwise, your page may display strange characters. Therefore, the recommendation is to use UTF-8 encoding for maximum compatibility. Pages delivered with the text/html MIME type are assumed, by default, to be encoded with ISO-8859-1. If you are using text/html and delivering UTF-8, set the HTTP Content-Type header to state this. If you develop web pages in a Windows environment, note that the default character encoding is often Windows CP 1252—which is similar but not identical to ISO-8859-1.

MIME types

Servers sending MIME types provide important information to browsers on how to treat a document. Sending incorrect MIME types with a document may cause the browser to incorrectly interpret and fail to render the document. For XHTML-MP, the recommended MIME type is application/vnd.wap.xhtml+xml. Unlike HTML, XHTML-MP shouldn’t serve text/html. Administrators often set up web servers correctly for common document types such as HTML and CSS, but not for XHTML-MP.

Page titles

Page titles surrounded by the <title> element are an important and frequently overlooked page element. Good titles increase the findability and usability of web pages. Add a short descriptive page title for easy identification, but remember that the mobile device may truncate the title. Most devices use the page title as a default label for bookmarks, so a title helps the user identify content.

It is common to use only the site name as the title, but this doesn’t help users as much as other approaches. The title of the document should consist of the primary title, optionally followed with your site name, as shown in the following example:

<title>Description of Page Content | Site Name</title>

Search engines primarily use page titles to identify content. Also, think about how users will search for your content on search engines while naming your pages.

Use of stylesheets

Many mobile browsers prioritize markup before presentation, loading stylesheets and images last. This sometimes causes markup to appear with styles briefly while the external stylesheet loads, known as the “screen flash.” You can avoid this by adding styles to the document head instead of using an external stylesheet. However, in doing so, you lose the ability to centrally manage your styles.

My recommendation is to always use external stylesheets, separating your markup and presentation and decreasing the overall page size.

Objects and scripts

Most mobile devices don’t support embedded objects or scripts, and it’s not possible for users to install plug-ins to provide support. Even where a device does support scripting, avoid using it unless you can’t find another means to express your design. Though many modern browsers support scripting, you may want to skip it altogether so that you limit your power consumption and have fewer rendering inconsistencies to tend with.

If you must rely on either scripting or embedded objects, use them very sparingly and test often.

Auto refresh

Avoid creating periodically autorefreshed pages unless you inform the user and provide a way to stop it, as shown in the following example:

<meta http-equiv="refresh" content="0" />


Using markup to redirect pages increases the load time and cost as a result of downloading and processing another page. If you need to use redirects, con the server to perform redirects using HTTP 3xx codes.


Using cached information sometimes reduces the need to reload resources such as images and stylesheets, thereby lowering download times and costs. By specifying cache information on your mobile pages, you lower the number of times devices download common resources. This especially helps resources like a stylesheet or logo as shown in the following example:

<meta http-equiv="Cache-Control" content="max-age=300"/>

Not all devices support cache control, but caching is important for mobile devices due to the typically high network latencies experienced on mobile networks. Just be sure to wait until you complete development before adding cache information—otherwise, you won’t see development changes, thanks to caching.

Minimal document structure

It is good practice for documents to indicate structure with headings and subheadings. Code in order and in a semantically correct fashion so that the code elements and the order in which they appear makes sense without manipulating the presentation. The following is an example of coding semantically:

<h1>Top Level Heading</h1>

<h2>Second Level Heading</h2>

<p>Paragraph Body</p> <h3>Third Level Heading</h3>

<p>Paragraph Body</p>

<h2>Second Level Heading</h2>

<p>Paragraph Body</p>

<h3>Third Level Heading</h3>

<p>Paragraph Body</p>

<h4>Fourth Level Heading</h4>

<p>Paragraph Body</p>

Using structural markup, rather than formatting effects, makes it easier to modify content when it needs splitting into several pages. Furthermore, structural markup potentially facilitates access to the sections of the document that a user wants. Use headings in accordance with the specification whenever applying them. For example, they should properly nest based on their level, as in the previous example.

Text Elements

If you are familiar with XHTML, then none of the following should be any revelation, but for good measure I want to make sure that each of the common text elements used in a XHTML document are included and how they can differ when rendered on a mobile device.



Headings h1 through h6 are supported in XHTML-MP. Your typical mobile page doesn’t have more than two or three headings on the page, for a few reasons. First, having an overly structured document starts to lose its context with smaller screens; in other words, it can be difficult for the user to be able to understand the header relationship when they can see only a few lines of text at a time. Second, headers are often rendered only a few pixels larger than the default text size. In desktop web browsers, headers are often significantly larger than the default paragraph size, but mobile devices cannot take this liberty.

In traditional mobile web authoring, headings would be omitted entirely, opting for bolded text, followed by a break in order to render more consistently. I heavily discourage you from using this technique and to code your pages semantically. This will give you great flexibility in your progressive enhancement strategy later.



The paragraph is the tag you will probably use the most. Each paragraph of text should be wrapped in the paragraph tag. The paragraph will apply default margin to the top and bottom on the element, which can be modified in the CSS.

Historically, paragraph tags would not be used due to the poor CSS support of devices; break tags would instead be used to create line breaks between paragraphs. Again, I strongly discourage you from employing this technique.



The blockquote is used for quotations or comments, and is often used to as a wrapper tag for one or more paragraph tags. Blockquotes often inherit margin around the entire element to give the appearance of being indented from the primary text, which may not be rendered consistently on all devices. I recommend making sure that you define the margins for blockquotes in your CSS instead of relying on inherited margins, therefore making it easier to debug later.

Phrase elements

em, strong, small, abbr, acronym, cite, dfn, code, kbd, samp, var, del, ins

With the exception of em and strong, I encourage you to not use any phrase elements in your document markup, as they may not be fully supported on Class C or lower devices. Instead consider using <span class=" phrase">…</span> and control your phrase presentation in your CSS.

Unordered lists


Unordered lists are a hallmark in web standards based design, often used for navigation lists and structuring nested content. Unordered lists are also useful in mobile web pages as well. For Class A browsers, unordered lists are just as useful in your designs as for desktop sites. For Class B and lower browsers, advanced styling of unordered lists, like displaying items horizontally, can sometimes create inconsistencies across browsers.

I recommend starting with simple styling and performing incremental tests on your targeted devices to ensure that your desired styling will display appropriately across multiple devices. Otherwise, just keep your styling very simple and restricted to margin, padding, and bullet type.

For Class B and lower browsers, I would avoid creating nested lists. They typically render as they should, but given the limited screen width, having multiple nested lists means that the inherited left margin can create an unreadable display.

Ordered lists


Ordered lists are not used as often as unordered lists in in desktop. For mobile designs, I recommend using ordered lists for all your navigation lists that have fewer than 10 items. This allows you to associate an access key to the appropriate navigation item:

<ol> <li><a href="#item1" accesskey="1">Item 1</a></li> <li><a href="#item2" accesskey="2">Item 2</a></li> <li><a href="#item3" accesskey="3">Item 3</a></li></ol>

Definition lists


A definition list is for lists that contain term and definition pairs, and is useful for creating repetitive lists where you simply need a title and do not wish to use a header; this is often used to denote a section. For Class A browsers, I use definition lists to structure forms, allowing me to place the form label either above or to the left of the form input or control. When targeting Class B and lower browsers, I avoid using definition lists altogether, given their less than trustworthy ability to do any advanced styling.

Structural elements


The div and span elements are just as critical to mobile web development as to desktop web development. The div is used to identify and label any block-level division of text or content; this could be a line of text, or it can be an entire page, whereas the span tag is used to identify a grouping of inline elements and is often used within a block-level element.

The div and span are essential for adopting a progressive enhancement strategy, allowing you to conditionally define what content is seen for what devices. For example, we can show only the content with the class lcd to our lower-end devices:

<div class="lcd">

<p> This text is only seen to lowest common denominator devices<p> </div> <div class="all">

<p>This text is seen by all devices</p> </div>

Or we can use the span element to create hooks for some devices, while hiding it from lower-end browsers. In this example, we create an empty span called “button” to use as an anchor for a complex control, like a button to toggle visibility that would be seen only on our higher-end browsers:

<p><a href="#show">Show all <span class="button"></span></a></p>

Line breaks

<br />, <hr />

Line breaks and horizontal rules work as expected on virtually all mobile devices. However, breaks should used sparingly and not as a replacement for the paragraph tag. I avoid using line breaks altogether, as they are presentation elements that should be omitted from markup, and instead use CSS to style the presentation. I use line breaks only if I know that I will use them consistently across all viewing contexts.

Character Entity References

nonbreaking space, &, <, >, ', ", TM, ©

Common characters not found in the normal alphanumeric character set, such as & or ©, must be specified in XHTML as character references starting with an & and ending with a ;. Entities are often expressed in entity, decimal, or hex syntax; however, for mobile devices, the entity syntax should be used. For example, a nonbreaking space would be coded as &nbsp; and an ampersand is &amp;.

Creating Links

Links are the foundation of how hypertext works. It can take you to new pages or be used as an anchor to content further down the page. With XHTML-MP, links can also initiate a telephone call and perform other device actions in certain phones. However, due to the constrained screen size, there are additional best practices surrounding links.

Number of links

Too many links on a page makes it difficult for the user to navigate and read content. Most mobile browsers stop the vertical scroll when a link appears, meaning that for each press down on the D-pad, the user is taken only as far as the next link. Try to limit links to 10 links per page and add access keys to links whenever possible so that users can navigate with the keypad as well.

Whenever possible, try to prioritize links by popularity so that the most popular links show up at the top. This creates a better experience and ensures that important content appears above the fold. At the end of each page, the user should have someplace to go. This could be the parent category, related content, back home, or the entire navigation list—anything to help the user avoid scrolling to the top of the page for original options.

Access keys

Navigating a mobile site can be difficult and cumbersome, but you can simplify navigation and limit scrolling by providing keyboard shortcuts for common links for devices with number pads (this obviously doesn’t apply to touch-only devices).

Associating an accesskey attribute with each link gives the user an easy way to access the link using the device’s keypad. Access keys come in handy when used consistently across a site, letting users jump quickly to their chosen sections without scrolling to find a link.

You may have more than 10 links per page. Try to create access keys for all navigational links. You can save some access keys, because it isn’t necessary to create access keys to links appearing within content blocks.

Initiating telephone calls

These information devices are, after all, phones, so XHTML-MP includes a means to initiate a telephone call within the <a> element, by prefacing the full phone number, including country code, with tel: within the href attribute. This will prompt the user to initiate a telephone call:

<a href="tel:+15555551212">+1 (555) 555-1212</a>

Because Class A browsers can render XHTML and desktop web pages, they often look for phone numbers within the page and render them as linked phone numbers, allowing you to initiate a call even if the number if not linked at all. This functionality can’t always be assumed, so it is best to always link your phone numbers appropriately.

Images and Objects

The desktop web is rich with a variety of embedded content; however, due to the hardware limitation of many devices, you cannot assume that all devices have the same capabilities.

Image types

Nearly all mobile devices support the JPEG, GIF, and PNG formats. Both the 8-bit PNG and the 24-bit PNG with alpha transparency are supposed to be supported as of WAP 2.0, but some older devices may not support them, due to hardware limitations. Whenever possible, use PNGs, as they are the recommended image format for the mobile web.

Image sizes

Adding images to your content can be tricky. The safe approach is to edit images so that they’re as small as possible in terms of pixel dimensions. With most mobile device screens, about 120 pixels wide, it is recommended that you not use images any wider than that. However, there are several devices with screens much larger.

If you are using a content adaptation system, you can dynamically insert different images based on the requesting device. Conversely, you can load larger images meant for larger devices, and use CSS to reduce the image height and width for smaller devices, but this means that lower-end devices are downloading larger images. Or omit images altogether from your lower-end experience, using empty spans as placeholders, and use image replacement for your higher-end devices.

Although it is a bit more complicated, I recommend the latter approach if you plan to use progressive enhancement techniques. This method allows you to control which images are loaded based on the stylesheet, even though it means defining each image manually. Lower-end devices that can’t support image replacement would see no images, therefore incurring no download costs, whereas higher-end devices would see larger images sized appropriately for their display.

It might not be the perfect solution in all cases, so be creative and find the best solution for your users and their devices. Just keep in mind that every kilobyte of data you push they will likely have to pay for. Any content referenced in your markup will be downloaded, regardless of whether they see it or not. For example, if you load a 100 kb photo in your markup, but then hide it with CSS, that 100 kilobytes will be downloaded to the device, and the user will pay for data charges nonetheless. So consider the size and use of images carefully.

Image dimensions

Not specifying the pixel height and width of an image forces the mobile device to calculate the values, increasing render times and degrading performance in lower-end devices. Bitmap images have an intrinsic pixel size, so telling the browser its size in advance avoids having the browser recreate the page when it receives it. Letting the server resize the image cuts down the amount of data transferred and the amount of time it takes for the client to process and scale the image. If the specified width and height attributes match the intrinsic size, then the client doesn’t resize the image.

This can, of course, be redefined using CSS, though some mobile devices might not override sizes defined in CSS correctly. If you plan to use progressive enhancement techniques, it may be easier to wait to define image sizes until you have tested them on your target devices.

Image maps

Most devices lack a pointing device, making it difficult for users to use image maps. If you know that the device supports touch, you can certainly use image maps, but I recommend avoiding them entirely.

Alt text

Always provide alt text value for all images. Downloading images can take a considerable amount of time to load over a mobile network. Some mobile browsers allow you to disable downloading images, opting for text-only mode in order to increase rendering speeds. Having alt text will ensure that any important images can be seen, regardless of the users’ preferences.

Flash and SVG

Though many devices support vector objects like Adobe Flash, SVG (Scalable Vector Graphics), and SVG-Tiny, we are still a few years out from seeing these formats ubiq-uitously supported, due to hardware constraints. Avoid using any vector graphics unless you specifically know that the targeted devices support it.

Embedded audio and video

All WAP 2.0 devices should support the 3GPP video format and the MP4 audio format, meaning that if you link to one of these resources, it should be able to be played in the device player. However, due to hardware constraints, not all mobile web browsers support the ability to embed this content into web pages.


Before I get to how you should use tables in mobile content, I’m going to let you in on another dirty little secret of the mobile web: the best way to get a consistent layout across multiple mobile browser has been and still is to use copious amounts of nested layout tables. Like in the days before web standard techniques on the desktop, tables provide the best way to ensure that web designs render consistency across multiple browsers.

Though the explicitness of tables means that layouts are more consistent across multiple mobile browsers, the vast array of screen widths means that sites were designed based on screen size, not device class. This approach leaves no room to create a layered, progressive enhancement approach, and limits the use to device it was intended. Creating a single code source that could be rendered on each of the mobile device classes, plus gaming consoles, media centers, and the desktop is virtually impossible.

I don’t encourage you to ever employ this approach, but in the interest of full disclosure I am stating that it is still done, because it still works and in some cases it is still the best means of providing the best possible experience to multiple mobile devices. It would be easy to just adhere to web standards dogma and simply declare that there is a right way and wrong way to code your pages, but it isn’t quite that easy.

Our job is to provide the best possible experience to our users, using whatever reasonable technology is at our disposal. Just because layout tables are looked down upon by the web standards community doesn’t mean we should remove them from our tool chest if this just happens to be the right tool for the job.

Hopefully, you will never need to concern yourself with this legacy approach—just be aware that if you are having problems with layout consistency a table might be the solution you are looking for.

Layout tables

The web design industry considers using tables for layout as bad practice, particularly for mobile devices. Table-based layout combines presentation and markup, which makes development more difficult and essentially eliminates the ability to adapt to other media.

Though tables provide a more consistent mobile web experience, they’re cumbersome and difficult to support. Table-based layouts restrict your ability to adapt for various devices and increase page size.

It’s more efficient to do page layouts with a style-based layout. The resulting layout adapts well to the narrow screens and adds flexibility while cutting page size.

Using data tables

On smaller screens, data tables—or content considered to be tabular data—often doesn’t fit or can appear erratically. Unless you know that a device supports tables, avoid using them. Smaller tables with two or three columns work on most devices, but even then it’s not recommended. Try using a definition list (<dl>) instead of a table to vertically display data.

Nested tables

Nested tables, like layout tables, don’t really belong in mobile design—especially because they have a tendency to render inconsistently and add to the page size. In part because of the conditions mentioned earlier, stay away from nested tables for controlling presentation. Instead, focus on creating well-formed XHTML-MP and control the presentation with stylesheets.


Frames just don’t work in mobile design. In most cases, either devices don’t support them or they cause a variety of usability problems. Instead, try applying server-side includes for loading local content.


Designing and developing great forms can be a challenge in the mobile context. In the Class A browsers, forms can resemble their desktop cousins, but for all other browsers, forms don’t always render like you might expect. However, the larger challenge is actually for the user, as forms are difficult to control and add content to. The rule of thumb is to limit the use of forms in the mobile context.

Free text input controls

Though unavoidable in forms that need information from the user, avoid using text boxes and text areas as much as possible. It’s difficult for the user to enter content into free text input controls such as text boxes and text areas. Instead, rely on radio buttons, select boxes, and even lists of links to reduce the need for text entry.

Default input mode

It’s possible to limit the type of data that entered into an input field by defining the input mask or input mode using Wireless CSS or CSS-MP, thereby making it easier for users to enter information into a free text field.

The input mode (alphanumeric or numeric) of the mobile device’s keypad automatically set according to the input mask value. The following example limits the input to only numeric values:

<input type="text" style=' -wap-input-format: "*N"' />

This example limits the input to alpha characters by capitalizing the first letter:

<input type="text" style=' -wap-input-format: "A*a"' />

Other Recommendations

But wait—there’s more! Here are just a few more best practices specific to mobile devices.

Validate markup

Nonvalidating markup may not display correctly or efficiently on mobile devices. In some cases, especially on older phones, nonvalidating XHTML-MP won’t render at all, leaving users with an error message in their browser. Using the W3C validator can be helpful for finding rendering errors.

To check markup against the W3C mobile web best practices, you can validate your code at or .

Pop-up windows

Most mobile devices don’t support pop-up windows. Even when they do, try not to rely on them, because changing the current view can be disorienting to the user.

External resources

Most mobile browsers download each resource as a separate element, beginning with downloading and rendering markup, followed by stylesheets and images. Depending on network speed, the user may see the basic markup while external resources download. When the download finishes, the browser renders the page again with the included elements. Carefully consider the number of external resources you use, limit them, and keep each resource’s file size as small as possible.

Total page download size

Page sizes (including images and stylesheets) should remain as small as possible, because large pages take longer to load and cost the user money. Try to target your combined page weight between 10–25 kb when ever possible. Avoid exceeding 50 kb per page, as download times and approximate cost become increasingly prohibitive.

CSS: Cascading Style Sheets

When we are talking about inconsistencies across multiple mobile devices, what we are really talking about CSS. In the past, mobile devices had incredibly poor support for CSS, using it as nothing more than a way to style text and apply background colors. Though many of today’s mobile browsers have far better support for both CSS2 and CSS3 than their predecessors, there are still plenty of legacy mobile browsers in the market to contend with.

Designing your CSS to work across multiple mobile browsers isn’t easy and can be a quite painful process. There is no one perfect way to create CSS that renders consistently on more than a handful of devices. I have three techniques I use, depending on the devices I intend to support:

Keep it simple

Keeping your styles very basic, using no complex styling techniques whatsoever, can be the ideal method for simple sites. Though it may not be pretty to look at, it works.

Code and reload

In this approach, you constantly test how your styles render on devices. For each code change, you reload the browser on each device you plan to support. This approach is slow and tedious, but it means fewer issues toward the end of the project.

Progressive enhancement

As I discussed before, this approach requires you to create multiple layers of support, so that your styles gracefully degrades depending on the device. This technique takes some practice to get right, but if you can master it, it can be a powerful approach.

Wireless CSS and CSS-MP

For markup, we have XHTML-MP, a descendent of XHTML; it only makes sense that we have a mobile equivalent for CSS. In fact we have two, Wireless CSS (sometimes referred to as W-CSS or WAP CSS) managed by the Open Mobile Alliance (OMA) and part of WAP 2.0 along with XHTML-MP. And then we have CSS-MP, or CSS Mobile Profile, managed by the W3C. So, in case you are keeping score: the OMA owns XHTML-MP and W-CSS, and the W3C owns XHTML Basic and CSS-MP.

The good news is that both of these standards are working to come together into one standard; they are both based on CSS2.1, and they are both becoming somewhat irrelevant, as mobile browsers gain decent support for CSS2.1, not to mention CSS3.

The primary additions are a handful of properties meant to improve the user experience, including a few input masks and marquee controls. If you can live without these, there is no need to really get too concerned with these mobile-only standards.

Box Model

The box model is one of the key concepts of CSS design, and therefore the first thing that tends to go wrong in mobile devices. The box model is the imaginary box that is around every element in your markup. It consists of five areas: the content, the padding, the border, the margin, and the outer edge, as seen in Figure 11-3.

Many elements have inherited values, meaning that they may have some margin or padding by default. The paragraph tag for example has inherited margin above and below the content area. Due to the space constraints, mobile browser engines sometimes apply different inherited values than you might expect. This can lead to frustrating inconsistency among multiple mobile browsers.

In Table 11-2, you can see how the box model compares with each class of mobile browser.

Table 11-2. Box model comparison

Class A Class B Class C Class D Class F

Box model Great Good Okay Poor Fail


The selector is used to tell which markup elements it should apply rules to—basically, what makes CSS work to control the presentation. There are a number of different types of selectors:

  • Universal

  • Type or element selectors

  • Contextual selectors (descendant, child, and adjacent sibling)

  • Class and ID selectors

  • Pseudoclasses

  • Pseudoelements

Universal selector

The universal selector selects all elements useful for defining the default typeface or font size. body or html can be used as well:


Type selector

The type or element selector targets the element by name. Type selectors are fairly safe to use across all mobile devices:

h1 {color: red;}

Descendent selector

The descendent selector targets elements that are descendants of another element, indicated by a single space separation. Despite being a fairly standard technique for styling desktop sites, the descendent selector is not consistently supported on Class C or lower browsers:

li a {color: black;}

Child selector

The child selector is similar to the descendent selector, but targets only the child of the defined element, not all instances like the descendent selector. Like the descendent selector, Class C browsers and lower can render child selectors inconsistently:

p > em {background-color: yellow;}

Adjacent sibling selector

The adjacent sibling selector targets an element that comes immediately after another element with the same parent. Again, this not a widely supported selector for Class C or lower browsers, but you can find some incompatibility among Class B browsers as well:

h1 + p { margin-bottom: 1em;}

Class selector

The class selector targets any element with the matching class. Class selectors are one of the more common techniques used for cross-platform mobile designs, given their wide support in nearly all mobile browsers:

.error {background-color: red;}

ID selector

The ID selector targets any element with the matching ID (remember that all IDs need to start with at least one letter). ID selectors, like class selectors, are one of the more common techniques used for cross-platform mobile designs, thanks to their wide support in nearly all mobile browsers:

#alert {background-color: yellow;}

Simple attribute selector

A simple attribute selector targets all elements with the matching value. These attribute selectors tend to work only in newer mobile browsers:

p[class] {color: blue}

Advanced attribute selector

Advanced attribute selectors target elements with matching substrings in the value of the attribute. This means that you can target existing attributes or create your own custom attributes. Although not supported on many Class B or lower browsers, advanced attributed selectors can be quite helpful for targeting different device classes, using a custom attribute:

<p device="iphone"> iPhone </p> <p device="android"> Android </p> <p device="lcd"> Lowest Common Denominator </p>

In this example, the caret (^) is used to target the attribute that begins with the value “iphone”:

p[device^="iphone"] {background: green;}

In this example, the dollar sign or string ($) is used to target the attribute that ends with the value “Android” on page 200:

p[device$="android"] {background: blue;}

In this example, the star (*) used to target the attribute that contains at least one instance of “lcd”:

p[device*="lcd"] {background: red;}


You can use pseudoselectors to target elements that might not exist in the markup, like a visited link. Unfortunately, pseudoselectors do not have strong support in Class B or lower devices:

:link, :visited, :hover, :active, :before, :after, :first-child, :last-child

In Table 11-3 , you can see how different CSS selectors fare in each browser class.

Table 11-3. CSS selector compatibility table

Selector type Class A Class B Class C Class D Class F
Universal selector Yes Yes Yes Yes Yes
Type selector Yes Yes Yes Yes Flaky
Descendent selector Yes Yes Flaky Flaky No
Child selector Yes Yes Flaky Flaky No
Adjacent sibling selector Yes Yes Flaky No No
Class selector Yes Yes Yes Yes Flaky
ID selector Yes Yes Yes Yes Flaky
Simple attribute selector Yes Flaky No No No
Advanced attribute selector Yes No No No No
Pseudoselector Yes Flaky No No No

Font and Text Properties

The typography options on mobile devices can be less than stellar, but like most things CSS-related, we are seeing mobile browsers move closer to their desktop cousins in this respect. This section covers the font and text options for mobile devices.

Available fonts

With the desktop web, we have at least 10 different fonts we can use in our designs. In mobile development, we can count on only two options: serif and sans-serif. In low-end devices, we might have only one option—almost always a sans-serif variant:

p {font: sans-serif;}

Traditionally, in mobile devices the only font available was the device font, and there was really no point trying to define a font at all. Over the years, the typography choices have become a bit more diverse, adding the web-safe fonts like Georgia, Times New Roman, Arial, and Helvetica, and a monospace font like Courier New, but we see these options now only in Class B and higher browsers.

Absolute size keywords

It’s not very common in desktop web design, but the typical method to determine the size of text is using one of seven absolute size keywords: xx-small, x-small, small, medium, larger, x-large, and xx-large:

p {font-size: xx-small;}

The bit depth of mobile screens can vary widely, so keywords are useful; they do not correspond to a precise measurement. Instead, they are relative to one another. Therefore, while one mobile browser may have a default text of 11 pixels and another 14 pixels, by using absolute size keywords, the medium keyword would be the default and recommended text size for both devices.

Percentage measurements

Percentage size values will work on Class B and higher browsers, but I wouldn’t recommend them:

p {font-size: 80%;}

Percentage size values rely on inherited parent values, which are not consistent across all browsers. Use absolute size keywords instead.

Length measurements

One of the more common means to style text on the desktop web is by using a specific number of units, for example the pixel, which is relative to the display resolution or ems, or the distance from baseline to baseline:

p {font-size: 10px;} p {font-size: .9em;}

Though possible on Class B and higher mobile browsers, it isn’t recommended. Again, the screen’s pixel depth can vary from device to device, creating inconsistent, unreadable designs.

Additional styling

There are a great number of ways to style text. The majority of them will work across multiple devices, given that if there is one thing a mobile browser should do fairly well, it is display text:

font-weight: bold; font-style: italic; text-transform: capitalize; text-decoration: underline; line-height: 2em; text-align: right; white-space: nowrap;

The general rule of thumb is that if you keep it simple, it will work across the majority of devices, but you can have peace of mind knowing that most basic text styling techniques will work as expected.

Text shadow

Creation of a text shadow, though supported only by Class A browsers, is a useful technique for mobile devices, reducing the need for images to create a desired visual effect:

text-shadow: 2px -1px 2px #ccc;

The syntax is: x-coordinate(2px) y-coordinate(–1px) blur-radius(2px) color(#ccc).

Font replacement

Given the limited typography options available in the desktop web, many designers and developers are starting to use text replacement techniques to replace. There are three techniques used—some that work on Class A mobile browsers only:


The easiest method is to define a font using the CSS3 at-rule @font-face, which references the typeface file to be used. But due to the heavy processing required to render custom fonts, this technique is not yet widely supported.


The technique uses Flash to replace the text with a small vector representation of the desired glyphs. However, this technique requires a browser with the Adobe Flash Lite plugin.


The third technique is to use JavaScript and the canvas element to render text to the device. I’ve found this to be the only reliable way to replace text on mobile devices, but only for browsers that have good JavaScript support and that support the canvas element.

In Table 11-4 , you can see the different font support for each class of browser.

Table 11-4. Font and text compatibility

Class A Class B Class C Class D Class F
Available fonts Web-safe fonts Web-safe fonts Sans-serif and serif Sans-serif and serif Sans-serif and serif
Font size Any Any Keyword Keyword Keyword
Font-weight Yes Yes Yes Yes Limited
Font-style Yes Yes Yes Yes Limited
Text-transform Yes Yes Yes Yes Limited
Text-decoration Yes Yes Yes Yes Flaky
Line-height Yes Yes Yes Yes Flaky
Class A Class B Class C Class D Class F
Text-align Yes Yes Yes Yes Yes
White-space Yes Yes Yes Limited Flaky
Text shadow Yes No No No No
Font replacement Limited No No No No

Basic Box Properties

Being able to style the box area around an element is a crucial part of web standards design. The good news is that the basic CSS level 2 box styling techniques you might use for the desktop web do work on most mobile devices, allowing you to style content with some level of precision. Many of the techniques that are not fully supported, like percentage-based and min-height techniques, are the same ones that many desktop web browsers don’t fully support.

Height and width

Height and width can be specified on the majority of mobile browsers, but issues can occur when trying to define percentage-based height values:

width: 100%; height: 50px;

Minimum and maximum dimensions

Minimum and maximum dimension values are not a reliable means to style an element across multiple mobile browsers. Though it is a very useful technique in the mobile context, it is largely used for Class A browsers only:

min-width: 120px; max-height: 100px;


The margin is the area applied to the outside of the element, including the border area. Luckily, margins render fairly consistently and can be relied on across multiple mobile browsers:

margin: 10px;


Padding is applied to the area within an element, inside of the border area. Like margins, padding works across multiple mobile browsers, however, not as reliably in lower-end browsers that have flawed box models. However, this can be worked around by applying margin to a child element:

padding: 10px;


Simple borders, like this one, will work in many mobile browsers, but can sometimes cause some inconsistencies in low-end browsers that have flawed box models:

border: 1px, solid, black;

Some Class A browsers do support advanced CSS3 border techniques like rounded corners, border images, and box shadow.

Box shadow

Like text shadowing, the box shadow is a useful way to create a desired visual effect without relying on downloading images to the device, though it is supported only by Class A browsers:

box-shadow: 10px 10px 5px black;

The syntax is similar to that of the text shadow: x-coordinate (10px) y-coordinate (10px) blur-radius (5px) color (black).

In Table 11-5, you can see how each of the box properties stack up against each of our browser classes.

Table 11-5. Box properties compatibility

Class A Class B Class C Class D Class F
Height and width Yes Yes Limited Flaky Flaky
Min and max dimensions Yes Flaky No No No
Margins Yes Yes Yes Yes Limited
Padding Yes Yes Yes Flaky Flaky
Borders Advanced Limited Limited Flaky Flaky
Box shadow Yes No No No No

Color and Backgrounds

Styling an element means defining colors and background images. Relying on CSS instead of images to create desired visual effects reduces time to download as well as cost.

Background color

The background color allows you to add a color value to the content area of an element. This technique works fairly reliably across all mobile devices:

background-color: red;

Background image

The background image allows you to link an image to the content area of an element:

background-image: url(background.png) repeat-x;

The background-image property is incredibly useful for creating mobile designs, allowing you to send small images to the device and tile them in a number of ways to create bandwidth-friendly designs.

Multiple background images

Though supported by Class A browsers only, the multiple background support of CSS3 comes in quite handy when creating mobile designs. It is written exactly the same as the background-image property; you can add multiple source values separated by commas, the first background being the foremost and the last being the furthest back:

background-image: url(foreground.png) no-repeat, url(background.png) repeat-x;

Table 11-6 displays how each of the color and background attributes are supported in each class of browser.

Table 11-6. Color and background compatibility

Class A Class B Class C Class D Class F
Background color Yes Yes Yes Yes Yes
Background image Yes Yes Yes Flaky Flaky
Multiple background images Yes No No No No

Positioning and Page Flow

CSS goes beyond just being able add design content within the page; it can also be used to define the design layout of the page. Using positioning and page flow attributes, we can add style to the page and help make it easier to read or interact with on small screens.


The displayproperty allows you to define how an element is to appear in the page flow. display: block;

For example, if the value is display:none, then the element is removed from the page flow and hidden from the user. This technique is often used in the mobile context to hide elements from the page flow that do not apply to the viewing context, for example in the case of hiding extraneous content meant for lower-end browsers.

The toggle display property with JavaScript is one of the principle tests for browser classification, allowing the designer to create dynamic tabs, or lists that the user can interact with to reveal. This technique allows the designer to conserve space on screen and provide clearer direction to the user.


Floats are usually applied to images, and other elements to position them either to the right or left of the page flow, causing nearby elements to wrap around it. Due to the smaller screens of mobile devices, floats are not encouraged for layout use. Instead, try to limit the use of floats to inline elements you wish to display alongside related text:

float: left;


Clearing goes hand in hand with floats, allowing you to prevent how block-level elements wrap in the use of a float. Usually, support for clearing in mobile devices is added to the browser whenever it adds support for floats:

clear: left;


Both relative and absolute positioning might seem to be odd tools for mobile design given the small screen size, but they actually come in handy for creating designs for Class B and higher browsers:

position: absolute; top: 10px; left: 50px;

In this example, absolute positioning removes the element from the page flow and places it at the specific position relative to its container.

Due to the way different mobile browsers treat the viewport, fixed positioning can be somewhat unreliable, even in Class A browsers.


There are several types of overflow: visible, hidden, scroll, and auto. This property is designed to control how content is displayed when it exceeds the defined value of an element:

overflow: hidden;

Both the visible and hidden types are fairly well supported in Class B and higher browsers, allowing you to save space in lists and menus. However, scroll and auto (which defaults to scroll in the case of an overflow) are not treated consistently across many browsers. The reason is that it is difficult to provide the user an established means of scrolling the area on a device.

Stacking order

The z-index element is used to determine the stacking order of positioned elements: z-index: 10;

This property is used when overlaying elements on top of each other to create a specific visual effect. Though used mostly for designs targeting Class A browsers, it does work on other classes as well.

Table 11-7 shows how positioning and page flow attributes are supporting in each of our mobile browser classes.

Table 11-7. Positioning and page flow compatibility

Class A Class B Class C Class D Class F
Display Yes Yes Yes Yes Flaky
Toggle display Yes Yes Limited No No
Floats Yes Yes Limited Limited Flaky
Clearing Yes Yes Limited Limited Flaky
Positioning Yes Yes Limited Flaky No
Overflow Yes Limited Flaky No No
Stacking order Yes Yes Limited Flaky No


Last, but not least, we come to JavaScript: the last pillar of mobile web development. Unfortunately, JavaScript simply hasn’t been a priority in mobile browsers for many years, due to the hardware limitations of devices. I frankly consider myself lucky to be dealing with a device that has decent CSS support, and if I have devices that support a little bit of JavaScript as well, then I’m ecstatic.

The bad news is that unless you are targeting Class A browsers, JavaScript just can’t be assumed in your mobile project. I know this can be a potential barrier to entry for many mobile web projects, but it doesn’t have to be. Just go back to the concepts of progressive enhancement that I talked about at the beginning of this chapter, and start to map out how your experience will degrade to each of the device classes you plan to support.

The good news is that we are starting to see widespread JavaScript support in multiple mobile browsers with Class A browsers and a few Class B browsers. Some devices, like the iPhone, are taking JavaScript to a new art form (which I will discuss more in the next chapter). As devices get more powerful and browser engines more adept at processing JavaScript, I have a feeling that this problem will go away soon.

Table 11-8 shows that JavaScript is available only in a few devices.

Table 11-8. JavaScript compatibility

If you enjoyed this excerpt, buy a copy of Mobile Design and Development.