CSS for Mobile Browsers : CSS Techniques

In this section we are going to talk about some well-known CSS techniques (reset CSS files, text formatting, and the box model) and see how the different browsers react to these features.

1. Reset CSS Files

It is very common in desktop web design to create a CSS hack to reset all the default margins and padding for common HTML elements. We can use this technique when developing for the mobile web, with some considerations: we should only reset the elements we are going to use, we should avoid the usage of the global selector (*) for performance purposes, and if we are using an external reset CSS file we should consider merging it with our local CSS file.

Some browsers always create a margin around the whole document that cannot be deleted. And in the browsers that do allow you to delete the margin, remember that a zero margin may not be a good design decision.

Nokia offers three markup and CSS templates for mobile web design for free through its developer site at http://www.mobilexweb.com/go/nokiatemplates. Every template has a reset CSS file. The following code is extracted from the mid-range device template, and we can adapt it to our needs:

html, body, div, span, object, blockquote, pre,
abbr, acronym, address, big, cite, code,
del, dfn, em, font, img, ins, kbd, q, s, samp,
small, strike, strong, sub, sup, tt, var,
b, u, i, center, dl, dt, dd, fieldset, form, label, legend,
caption, tr, th, td {
    margin: 0;
    padding: 0;
    border: 0;
    font-size: 100%;
    font-weight: normal;
    vertical-align: baseline;
    background: transparent;
}

p {
    border: 0;
    font-size: 100%;
    font-weight: normal;
    vertical-align: baseline;
    background: transparent;
}
a {
    margin: 0;
    padding: 0;
    font-weight: normal;
}

h1, h2, h3, h4, h5, h6 {
    margin: 0;
    padding: 0;
    border: 0;
    vertical-align: baseline;
    background: transparent;
}

body {
    line-height: inherit;
}

body table {
    margin: 0;
    padding: 0;
    font-size: 100%;
    font-weight: normal;
    vertical-align: baseline;
    background: transparent;
}

/* remember to highlight insertions somehow! */
ins {
    text-decoration: none;
}
del {
    text-decoration: line-through;
}

/* tables still need 'cellspacing="0"' in the markup */
body table {
    border-collapse: collapse;
    border-spacing: 0;
}

					    


Note: The Nokia Mobile Web Templates are a set of templates (including XHTML and CSS files) for low-, mid-, and high-end devices that generate similar experiences across different devices, including hacks that solve some bugs, like the 100% width bug. They have been optimized for the Series 40 browser, S60 browser, Maemo browser, and Opera Mini. You can download them for free at http://www.mobilexweb.com/go/nokiatemplates.

2. Box Model

The box model, shown in Figure 1, is how the browser represents every context box. Every block element (paragraph, image, title) has a content size, padding, borders, and outer margins. The sum of all of these defines the final size of the whole box. Fortunately, most mobile browsers have good compatibility with all of these features.


Warning: BlackBerry devices (up to Device Software 4.5) support only borders and padding from the box model; any other properties are ignored.

 

Figure 1. The CSS box model is the same for mobile and classic web. Understanding this model will save us some headaches.

 

 

I don’t recommend using common desktop techniques such as negative margins for fully compatible mobile websites. These hacks can be used only in modern browsers, and after testing.


Note: CSS 2.1 adds the outline property, which provides a border with the same color and size for each side that doesn’t take up space in the flow of the document. It is not supported in low- and mid-end devices.

3. Text Format

Showing text is the most common situation in a mobile website, and styling it in a way that maximizes compatibility can be a little tricky. Bold (font-weight: bold) and italics (font-style: italic) are reliably compatible, but support for other text-formatting features varies.

3.1. Font family

This will be our first problem in styling text for mobile browsers. There are no standards in terms of fonts for mobile operating systems, and most platforms have only one system font (generally a sans-serif one).


Note: NTT DoCoMo markup (for the Japanese market) still uses the old font tag for defining font properties like face, color, and size. Newer devices also support CSS. Other WebKit-based mobile browsers also support the font tag, but its use is not recommended. Use CSS instead.

We can provide specific font names (like Arial, Verdana, or Times New Roman) or generic font types (like serif, sans-serif, monospace, cursive, or fantasy).


Note: Opera Mini has two modes: desktop and mobile. The default mode since version 4 is desktop, although the user (or carrier) can change this default. In mobile mode, some CSS from your website will be ignored and styling will be handled by the browser’s own styling engine.

For the best compatibility, you should use the default font and apply other attributes (color, size, etc.). If you want to define a font name, you should consider providing a list of alternatives. If the first font isn’t available, the browser will try the second, then the third, and so on; if none of the listed fonts is available, it will use the default one.

Table 1 shows only the browsers with font support and lists the available choices for each.

Table 1. Font support list for compatible browsers
Browser/platform Specific fonts available
Safari American Typewriter

American Typewriter Condensed

Arial

Arial Rounded MT Bold

Courier New

Georgia

Helvetica

Marker Felt

Times New Roman

Trebuchet MS

Verdana

Zapfino

Android browser Droid
Symbian/S60 S60 Sans
webOS Arial

Coconut

Verdana


3.1.1. Custom fonts

If you thought defining a system font was a headache, using custom fonts is even worse. No browsers support the CSS @font-face rule (with the exception of Safari for iOS, which has very limited support for SVG fonts).

If you want to use your own font for text, you should think again. If it’s a matter of life or death, you can consider using an image (again, not recommended) or a different approach on compatible browsers: sIFR on Flash-enabled devices, or Cufón for HTML 5 devices. Compatibility is limited, though, and even if these solutions work, they can be slow.

sIFR (Scalable Inman Flash Replacement) is a nonintrusive JavaScript and Flash technique that replaces normal HTML text with a Flash movie with the same text and an embedded vector font. It can be downloaded from http://wiki.novemberborn.net/sifr.


Note: Unobtrusive code does not change the way we create the document. We just add a JavaScript line and, if the browser is compatible, it will activate. If not, the normal HTML document will be used.

Cufón intends to be the more standard replacement for sIFR: it is a free service that allows us to upload a font to the website (http://cufon.shoqolate.com) and download a “FontForge” script containing the embedded font in two formats: VML for Internet Explorer and HTML 5 canvas for the other browsers.


Warning: If delivering a custom font, you need authorization to distribute it. The font may be copyrighted, and you should make sure you have the right to distribute it as a custom font for your website.

Table 2 lists browser compatibility for sIFR and Cufón.

Table 2. Custom font techniques compatibility table
Browser/platform sIFR Cufón
Safari No Yes
Android browser No Yes
Symbian/S60 Yes No
Nokia Series 40 No No
webOS No No
BlackBerry No No
NetFront Depends on the browser version No
Openwave (Myriad) No No
Internet Explorer No No
Motorola Internet Browser No No
Opera Mobile No No
Opera Mini No No

3.2. Font size

Which elements need a defined font size? For most cases, we should only define font sizes for headers and for element selectors (h1, h2, p, div). If you are defining a font size for a specific paragraph, it may be more appropriate to use a header tag.

We can use any measure for the font size, and almost every browser will understand it. However, it may be not rendered any differently. Only smartphone browsers with smart zoom support allow any font size to be rendered (like 13.5px in Safari on iOS).

For most of the mobile browsers, the best font size technique is to use relative constants (xx-small, x-small, smaller, small, medium, large, larger, x-large, xx-large).

Operating systems have different font support. Some of them have only three possible sizes for text, and if we use the typical pixel definitions, two different sizes (for example, 12px and 14px) may be rendered identically. If we use relative constants (e.g., large), we have more probability of that text being rendered in a larger font. Another compatible way of specifying font sizes is to use em values. Using em values is perfect for supporting different screen sizes and DPIs because this unit is relative and scalable to the standard font in the device.

The default (medium) font size is generally the perfect size in the operating system for normal paragraph text, and for normal text we should leave it that way.

3.3. Text alignment

We can align the text using text-align over a block element (like a p or h1) with a value of right, left, center, or justify. As shown in Table 3, the justify value is the least widely compatible for mobile devices; if not supported, it will render as left.

Table 3. Text alignment compatibility table
Browser/platform Center Justify
Safari Yes Yes
Android browser Yes Yes
Symbian/S60 Yes Yes
Nokia Series 40 Yes No
webOS Yes Yes
BlackBerry Yes No before 4.5Yes from 4.5
NetFront Yes No
Openwave (Myriad) Yes No
Internet Explorer Yes No
Motorola Internet Browser Yes No
Opera Mobile Yes Yes
Opera Mini Yes Yes

3.4. Other standard text styles

Styles like text-decoration, text-transform, font-variant, letter-spacing, and word-spacing should be used with care. It is best to assume that they will not work and to create the standard functionality without them. If some browsers do render them, great; however, don’t rely on them.

There are also some CSS3 and WebKit extensions for text styles that will be covered later.


Note: A good source to find more detail about mobile CSS compatibility is the website http://www.quirksmode.org/m/css.html. It has many tests and results for CSS selectors and properties on a range of devices.

3.5. Text shadows

Another non-mobile CSS 2.1 feature is text-shadow. It allows us to define the color, x-offset, y-offset, and blur radius of a shadow to be applied to a text selector. For example, we can produce a shadowed headline like that shown in Figure 2 with code like this:

h1 {
   text-shadow: 0.1em 0.1em #AAA
}

 

Figure 2. Text Shadow should be used with care and only for titles or short texts

 

 

If you’re thinking about using this feature, remember that in the mobile world, the clearer the text is the better for usability. Use text shadows with extreme care. Only a few browsers support this feature anyway, as listed in Table 4.

Table 4. Text shadow compatibility table
Browser/platform Text shadow compatibility
Safari Yes
Android browser No
Symbian/S60 No
Nokia Series 40 No
webOS No
BlackBerry No
NetFront No
Openwave (Myriad) No
Internet Explorer No
Motorola Internet Browser No
Opera Mobile Yes
Opera Mini Yes from 5.0

3.6. Text overflow

CSS3 adds a very useful feature for mobile web designs: text overflow. This property, available in some mobile browsers, allows us to specify that an ellipsis should appear at the end of a piece of text if it doesn’t fit in its container in a single line, depending on the font and space available. This is great for reducing the amount of space taken up by links, and for previews or summaries that will be shown completely in a details page after the user clicks on them.

For example, we can show a title, and a description with text-overflow set to ellipsis. When the user clicks on the title, via JavaScript, we remove the text-overflow property and the whole text is shown. This maximizes the amount of content we can display on a page. This feature also works well on devices that support both landscape and portrait orientations: with text overflow we can assure the usage of only one line in both modes.

To use this feature, the paragraph (or other element containing the text) must have overflow: hidden to avoid the continuing of the overflow text on the next line, white-space: nowrap to avoid wrapping, and some value for text-overflow.

In mobile browsers, the possible values for text-overflow are clip and ellipsis. The ellipsis value causes an ellipsis to appear after the last character that fits in the box (as shown in Figures Figure 3 and Figure 4). clip is the default value, which truncates the text without showing the ellipsis.

 

Figure 3. text-overflow: ellipsis is a great feature for displaying summaries in mobile designs.

 


 

Figure 4. Gmail for smartphones is an excellent example of text overflow usage. Here is the same view in portrait and landscape modes. Note that the amount of text displayed is larger in the landscape orientation.

 

 

Here is a sample that produces the result shown in Figure 3:

<!DOCTYPE html PUBLIC "-//WAPFORUM//DTD XHTML Mobile 1.0//EN"
    "http://www.wapforum.org/DTD/xhtml-mobile10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Documento sin título</title>
<style type="text/css">

ul p {
    text-overflow: ellipsis;
    overflow: hidden;
    white-space: nowrap;
}

</style>
</head>
<body>

<h1>Latest news</h1>

<ul id="news">
    <li>
        <a href="#">Teletransporter discovered</a>
        <p>Beam me up, Scotty! Finally scientists from London have discovered
            teletransportation</p>
    </li>
    <li>
        <a href="#">Teletransporter discovered</a>
        <p>Beam me up, Scotty! Finally scientists from London have discovered
            teletransportation</p>
    </li>
</ul>

</body>
</html>

					    
 

Table 5 lists browser compatibility for the text-overflow property.

Table 5. Text overflow compatibility table
Browser/platform Text overflow with ellipsis support
Safari Yes
Android browser Yes
Symbian/S60 No
Nokia Series 40 No
webOS Yes
BlackBerry No
NetFront No
Openwave (Myriad) No
Internet Explorer Yes
Motorola Internet Browser No
Opera Mobile No
Opera Mini No
 

There are more advanced styles under discussion for the next version of the standard, but they are not yet compatible with mobile devices.

3.7. iPhone text adjustment

Safari on iOS supports a CSS style especially for controlling the size of text prepared for the zooming action: -webkit-text-size-adjust. This style accepts values of auto (the default), none, and a percentage (e.g., 200%). By default, iOS overwrites the site’s font sizes to allow the text to be read without any problems when the user zooms over a paragraph. We can override this behavior with this style, turning it off (none) or defining a percentage zoom level to be applied on the default font defined for the desktop website.

If we want to enhance a desktop website for iPhone browsing, we should leave this style set to auto. However, if we are creating a mobile-only website, we will typically want to define our own font sizes, so we should turn this feature off:

body {
    -webkit-text-size-adjust: none
}
 

As we can see in Figure 5, if a paragraph is prepared to be read in a desktop browser with a large viewport width, we can change this behavior using the -webkit-text-size-adjust attribute to enhance the iPhone reading experience without changing the desktop appearance.

 

Figure 5. This is the same text paragraph with text adjustment off and with 400% as the value. This feature is useful only in non-mobile web designs.