Latest Tweets

 

Smartphone support for CSS: handheld

A rant (contains some immoderate language)

Software companies large enough to have responsibilities of stewardship over common aspects of the Web often make inferior technical decisions for no reason than their short-term gain at the expense of long-term benefit to everyone. Usually I let this wash past, I’m acutely aware it’s happening, but I don’t let it derail my thinking or my work. But sometimes — I just can’t help it — something will just piss me right off. Invariably it’s something modest, something that would simplify my life as a software developer, or open a small pocket of creative possibilities; invariably something that’s put to death as part of the collateral damage of a corporate business plan somewhere.

This time it’s the handheld media type for CSS. This harmlessly enumerated value promised to give developers a way to tailor websites for display on handheld devices. It was introduced in the CSS2 specification 13 years ago, with the following straightforward description:

Intended for handheld devices (typically small screen, monochrome, limited bandwidth).

Technology moves quickly and this was subsequently amended to:

Intended for handheld devices (typically small screen, limited bandwidth).

Any rationally minded individual would, I think, agree that any iPhone is by definition a handheld device. One that, whether it’s typical or not, has a small screen and limited bandwidth compared say a desktop or laptop computer, two other device classes that are frequently used to browse the Web.

So why does the Apple iPhone not classify itself as a handheld device? Here’s Apple’s justification:

CSS3 recognizes several media types, including print, handheld, and screen. iOS ignores print and handheld media queries because these types do not supply high-end web content. Therefore, use the screen media type query for iOS.

This is dross: superficially intelligible, but still drivel. It’s the sort of thing we pay our politicians to say because no other people of equal intelligence can bear to, except this is embedded in a technical document describing how to develop webpages for the iPhone.

CSS rules control the presentation of content, they have nothing to do with its “supply”. The most you could say is that CSS rules might be used hide “high-end web content” though I really struggle to see how this could ever be a real problem because a developer would never want to serve “high-end web content” to a device that doesn’t have the bandwidth to usefully download it or the screen to usefully display it only to finally hide it from the user when it had; and a strategy based on the assumption that content which is never visible is never downloaded is very risky.

This appears to be a manufactured justification. Apple is full of smart people, the only rationalization I can find which makes sense is that Apple didn’t want customers opening their stylish cardboard boxes and turning-on their expensive new gadgetry and launching their petite new browser to see monochrome pages filled with undersized text, if even from a handful of websites. Fair enough. It may have increased their bottom-line, but it’s paid for by every web developer who wants to reliably style their web pages for mobile phones, and it’s really biting us in the backside now that the screen resolutions of high-end phones overlap with those of low-end computers. It was a problem for Apple, but they side-stepped it, and exported it as a problem for (potentially) every web developer in the world.

That Android followed the iPhone down this dead-end just increases my frustration because it means that support for the handheld media type will never improve. Grrr…

I’ve made some minor edits for accuracy

An dr oi d

I’m diving back in now, but I’ve been too busy in the past 6 months to engage in any serious Android development; I’ve only been able to admire all of the exciting new developments - new apps, new handsets, new services and, of course, new platform releases.

Reading Dan Morrill’s post on android compatibility prompts me to share my personal irritability at the constant reports one can read about android ‘fragmentation’. This exercised me quite a bit during the build-up to the iPad SDK release.

Firstly, most of the comparisons that writers make between Android and J2ME are lazy and bogus: J2ME is a specification and Android is a ‘codebase’. As a consequence, the scope for incompatibilities between Android devices is significantly smaller.

Secondly, the comparisons between Android ‘the platform’ and iPhone ‘the product’ often dwelt heavily on the fragmentation bogeyman. When a new device, the iPad, arrived and had hardware specifications at variance with those of the iPhone many developers expressed concern that they would need to modify their applications to take advantage of the new device.

I suspect that many of these developers, those who might once have regarded the iPhone’s defacto consistency as an advantage - a simplification and timesaver - now find themselves with more work than is necessary to support two devices than if they’d developed their application for a platform that supported them in the task. Say, like Android!

And now to the crux of my annoyance. I’m addressing developers here when I ask: Are you really serious providing LOTS of users with a rewarding experience of your application?

Because if you are, then you have to be ready to accommodate them, and they’re pretty a variable bunch. I don’t want to get preachy, but not everyone speaks or reads English. Some people can’t read at all. Many people have weak eyesight and some are completely blind or deaf for that matter. I could go on, but my actual point is this:

Not every possible user’s needs can be met by the same mobile phone. The user variability that application developers attempt to handle via good UI design, accessibility, and internationalization, extends outside of the software domain and into the hardware.

Most of the concerns that developers flag-up as being aspects of fragmentation are simply the realities of addressing the needs of these users, large numbers of them. Some users will be poorer than others; they can’t all afford the newest/best handsets. Some need larger screens for their bad eyesight. Perhaps their motor skills are poor and they prefer a real keyboard. etc.

Android is a single platform that is designed, within reason, to accommodate as many mobile phone users as possible, and it supports us developers by providing helpful libraries, tools and APIs that can make a single application binary accessible to them all.

If you’re serious about making a mobile phone application available to the greatest number of users possible, I think you should develop for android and embrace the tools it provides for coping with the diversity of its users, not exhibit every hardware variation it exposes as evidence for its present/eventual fragmentation.