W3C mobileOK hurts interoperability

Twitter Updates


San Francisco PechaKucha Night
San Francisco IxDA


I guess this is what happens when I stop involving myself in the development of Web standards. Am I the only one on the planet that understands content negotiation and how important it is to the W3C’s admirable vision of “One Web”?

In advance of attending the Web 2.0 Expo, I thought I should catch up on recent happenings and make a quick little post on the important issue of a single URL working for both desktop and mobile browsers.

I was pleasantly surprised to find the latest efforts by the BPWG—the Mobile Web Best Practices 1.0 – Basic Guidelines and the W3C mobileOK Basic Tests 1.0.

When I first skimmed the documents, I thought they were exactly on track. But looking at two key details, I see an omission and an error that dooms us to needing separate URLs (or domains) for mobile content for some time to come. The error is simple; the test case mandates an HTTP accept string that says the browser equally prefers plain HTML and WAP 2.0. Since plain HTML should have a higher quality setting on the server than WAP 2.0, the content negotiation rules mandate a browser that sends this string be send plain HTML. !!!!

Include an Accept header indicating that Internet media types understood by the Default Delivery Context are accepted by sending exactly this header:

Accept: application/xhtml+xml,text/html;q=0.1,application/vnd.wap.xhtml+xml;q=0.1,text/css,image/jpeg,image/gif

A simple change to the above string, such as specifying the WAP 2.0 (XHTML Mobile Profile) MIME type as q=0.2 would have avoided this problem.

Even more fundamental to that problem, is the selection of XHTML Basic 1.1 as the standard document type for mobile browsers. Because this was selected instead of XHTML Mobile Profile, there is no way to activate the decade-old documented method of content negotiation based on MIME types; at least not if I want to send XHTML 1.1 to desktop browsers and XHTML Basic 1.1 to mobile phones (which is indeed what I want to do).

Here is the problem. Content negotiation relies on the mime type being different for each variant you want to serve, but look at this:
XHTML 1.1 MIME type:application/xhtml+xml
XHTML Basic 1.1 MIME type:application/xhtml+xml

OK, so there is a way to differentiate these two MIME types, but it’s not pretty:

I don’t really have a good solution for a fix at this point. One possible solution is to better specify content negotiation in an RFC so that pre-defined strings can be used in the profile to specify different types of XHTML. Another would be to use the level attribute instead of profile, and map integers to XHTML types (shudder, but it would work). Or maybe the W3C can just register application/basic.xhtml+xml as the MIME type for XHTML Basic? That, I think, is the simplest solution.

Don’t even get me started on the .mobi top-level domain!

Author: Peter Sheerin

Peter Sheerin is best known for the decade he spent as the Technical Editor of CADENCE magazine, where he was the acknowledged expert in Computer-Aided Design hardware and software. He has a long-standing passion for improving usability of software, hardware, and everyday objects that is always interwoven in his articles. Peter is available for freelance technical writing and product reviews, and is exploring career opportunities in interaction design. His pet personal project is exploring the best ways to harmonize visual, tactile, and audible symbols for improving the effectiveness of alerting systems.

Leave a Reply