Previous Message
Next Message

developing for handheld

Sent by Jonny Axelsson on 24 January 2005 17:05

On Fri, 21 Jan 2005 15:21:53 +0300 (MSK), Anton Outkine [EMAIL-REMOVED]>  

> i'm asked to develop a mobile version of a big infosite which gets half a
> million visitors a month
> and while i've spent some time designing CSS-styled pages for mobile
> devices, this is really big so i've a few questions :)

> first, any resources concerning developing XHTML/CSS for PDAs on the web?
> yes i found some articles on A List Apart, and that's, roughly, all about
> it

There are not many articles out there, unfortunately. We plan to make a  
few of our own soon to compensate.

> second, i'm really curious are there any sites out there listing various
> mobile platforms, their XHTML/CSS support charts, screen resolutions  
> etc.?

Opera definitely has the best (X)HTML and CSS support for handheld  
devices. Our products are either Opera 6 or 7 based with the same (or  
marginally better) CSS support. But most other browsers by now have some  
CSS support too, with the phone browsers outpacing the PDA browsers. This  
is partially because phone operators have browser requirements that are  
(fairly) standards based, and partially because there is a much greater  
commercial interest in phones than in PDAs. There are more browsing  
capable phones and this is doubling each year, while the PDA market is  

There is a phone consortium, OMA [1], that maintains browsing standards.  
It is not my favourite web site, and it probably is not going to be yours,  
so to summarize: The OMA browsing standards include XHTML Mobile Profile  
1.0 and 1.1 (between XHTML Basic and XHTML 1.0 in size) and Wireless CSS  
(WCSS), roughly equal to W3C CSS Mobile Profile [2] with a few proprietary  
features including, of all things, marquee support. This isn't enough to  
do the most advanced CSS designs, but should be sufficient to make pages  
look good.

The good thing about OMA compliance is that it gives a baseline standard.  
If your browser doesn't support this, you can expect to lose business. But  
don't have any illusion that the phone browsers are bug free, they have at  
least as many rendering bugs as their desktop cousins.

There is no similar converging force for PDAs and the standards support  
vary widely, but meny vendors here eye the phone market too, so there  
should be a baseline here too. If you want to design for the installed  
base it can be more challenging, some of these browsers are atrociously  

There has been a change in focus in the phone market from XHTML to HTML  
lately. This is simply realism, the XHTML web isn't coming any day soon,  
but you probably will be better off with XHTML anyway. If you use HTML try  
to make valid code, the mobile browsers are not as good in error  
correction as their desktop equivalents.

> while i suppose that designing a page for mobile means 1 narrow column,
> i'm really curious about "how narrow" (100 or 250 pixels? some stats?),
> what input devices are out there (and what are common) etc etc.

Some smaller phones are around 100-128 pixels width. The most common  
smartphone platform today, Symbian Series 60, has 176. Symbian UIQ has  
220. PDAs and some larger phones hover around Quarter VGA (320x240, either  
landscape or portrait). Series 80 and 90 phones have 640, as have PDAs  
with VGA display in landscape mode (480 in portrait). Some will have high  
quality displays with higher resolution/pixel density (i.e. smaller  

You can expect phones in the range 100-320 pixels, smartphones and PDAs in  
the range 320-640 pixels. You generally will have to subtract some pixels  
for UI and scrollbars.

> third, any general suggestions maybe?

Good small code helps. Size matters, especially on phones where you  
usually pay for the amount of data transferred, but also because devices  
are more constrained. It isn't hard to make most phone browsers crash or  
take insanely long time to render. Validate the code.

I believe making sites accessible and work on devices have very much in  
common. If you drop a couple masochistic requirements most accessibility  
requirements make good sense, like having *useful* alt-texts and no  
timeouts (phone lines are slow, writing on a phone or PDA is very slow).

Don't worry too much about simple presentational markup (yes, 'b' and 'i'  
is fine, but as you know if they span entire paragraphs, you're better off  
with CSS), worry about complex  markup (tables, object, the like). Stay  
away from bad markup (frames and pop-ups).

Don't expect dynamic menus to work, whether made by JavaScript or CSS, and  
remember the size of the screen.

Don't expect a CSS or HTML feature to be supported, some browsers don't  
support CSS at all, others just the simplest stuff. Don't expect them not  
to be supported either. I have seen the proposal to have an @media  
handheld style sheet to have no styles, since we all know that handheld  
browsers are incapable of displaying styles. That would make sites that  
otherwise would display beautifully on better browsers to display as the  
worst ones instead.

Get rid of the crud. As Nielsen and others have pointed out the screen  
estate is often dominated by everything but the payload the user wants to  
see. This is forgiveable on a big screen, but not on a small. You want to  
turn multi-column layouts into a single column.

@media handheld is going to be the way out. Unfortunately only Opera  
supports @media handheld correctly, there are a few others that support it  
partially, a couple that support it brokenly, and many that don't support  
it at all. This situation is likely to improve as the media type is a part  
of the mobile profiles.

Handling broken support means hacks. I haven't yet formed an opinion of  
what is the best way to handle this and not punish the ones with good  
support. I am inclined towards browser sniffing, but this must be updated  
when those browsers fix their support.

If you use @media handheld, don't go overboard with display:none. If a  
user wants to see something on a PC, chances are that he will want to see  
it on a PDA or phone. Only remove the fluff, resize or reorganize the  
rest. A badly designed handheld style sheet could end up with worse  
usability than no style sheet at all (especially with Opera as this would  
irrevokably turn off Small-screen rendering on many devices).

Don't ever use two stylesheets, one with 'screen' and one with 'print'  
(and none with 'all'), to make the print version. This removes styles from  
devices using 'handheld', 'tv', or 'projection' media (this doesn't matter  
as much for 'speech', I am not aware of any device using 'tty', 'braille',  
or 'embossed' media).

Testing is important, but hard to do as the devices are expensive and  
often unavailable. Testing in Opera 7 or 8 with Small Screen turned on  
gives a fair idea of what to expect, but other browsers will display  
differently, especially if they have poor CSS support. Remember to have an  
@media handheld rule, otherwise all you would test were our Small-screen  
rendering, which would be useless for other browsers. There are services  
that can make screenshots of how it would display on some devices. If you  
can't/won't do any of these, at least test in a small window and turn  
on/off images, styles, and scripts.

Longer term CSS3 Columns and especially Media Queries will make life a lot  
easier. But don't expect general support for this any time soon.

> i'd be grateful for any suggestions and links

Others have already linked to most of the articles out there. Here are  
some additional links.

[1] Open Mobile Alliance <>
[2] W3C CSS Mobile Profile (CR) <>

Old, incomplete, but still useful PDA CSS comparison:

Making Small Devices Look Great <>
- Netmeeting <>
- Opera CSS support (includes a WCSS column)  

For some background reading (but not helping with web design) W3C had a  
"Mobile Web Initiative" workshop a few months ago  

Jonny Axelsson,
Web Standards,
Opera Software ASA
css-discuss [EMAIL-REMOVED]]
List wiki/FAQ --
Supported by --
Previous Message
Next Message

Message thread:

Possibly related: