W3C Mobile Web Best Practices Working Group's Blog

A few months ago, the Mobile Web Best Practices Working Group and the WAI Education and Outreach Working Group published a First Public Working Draft of a document that explored the overlaps and differences between the Mobile Web Best Practices (MWBP) and the Web Content Accessibility Guidelines (WCAG).

A new draft was published a few days ago: Relationship Between Mobile Web Best Practices 1.0 and Web Content Accessibility Guidelines.

The document was re-engineered and simplified with a view to making it easier to read and apply. In particular, the sections that explained why following a given Mobile Web Best Practice may help users with disabilities were removed for the sake of simplicity. Could the document be further improved?

The pages that detail how to address one specification when you've already done the other were completed. The page WCAG 2.0 and MWBP Together is still mostly empty, though. The thing is it is hard to present a simple mechanism that would make it easy to follow both specifications at once. The current proposal is:

1. Decide on the WCAG level required for the project, and follow the WCAG 2.0 specification
2. Using the page From WCAG 2.0 to MWBP, identify and follow the MWBP that still need to be addressed

Whilst it appears to be rejecting the question, it may well be the easiest answer. Could you think of any better idea?

The Mobile Web Best Practices Working Group published yesterday a fourth Last Call Working Draft of its mobileOK Basic.

The document was previously published as a Candidate Recommendation. In terms of W3C Process, this means we moved backwards on the Recommendation track. The reason for this if that the changes introduced in the latest version, that reflect a few bugs/imprecisions encountered during the implementation phase of mobileOK Basic, are considered substantive, because some Web pages that previously were mobileOK Basic may not be mobileOK Basic anymore.

What were the changes and why were they needed?

1. The validation against the declared DOCTYPE is now restricted to known XHTML versions, namely XHTML Basic (1.0 and 1.1) and XHTML-MP (1.0, 1.1 and 1.2)
   In previous versions of the document, a Web page was checked twice: against its declared DOCTYPE, and against the XHTML Basic 1.1 or the XHTML-MP 1.2 DTD. The first validation - although clearly a good practice - introduces a lot of complexity when one is to implement a mobileOK Basic checker (typically, validation to HTML 4.01 cannot be done with an XML parser). Besides, what really matters as far as mobileOK Basic is concerned is whether the page validates against the XHTML Basic 1.1 or the XHTML-MP 1.2 DTD.
   
   The reason why the page is still validated against the declared DTD when it's one of the older versions of the XHTML Basic or the XHTML-MP DTD is because a page may validate against the XHTML Basic 1.1 DTD for instance but not against the XHTML Basic 1.0 DTD (e.g the target attribute of the a element was not supported in XHTML Basic 1.0) and it would be wrong to mark such a page as mobileOK.
   
   
2. The object elements are now correctly handled in the following tests: 3.6 EXTERNAL_RESOURCES, 3.15 OBJECTS_OR_SCRIPT and 3.16 PAGE_SIZE_LIMIT
   Objects may in particular be declared without type attribute. In that case, the user agent has to fetch the resource simply to determine if its type is supported or not. These kind of objects were not counted when computing the size of the page, which meant that a page that declared a 20Mb object that had to be downloaded by the user agent could be mobileOK Basic!
   
   
3. The definition of the mobileOK User-Agent string was relaxed to allow checkers implementations to complete the string with additional tokens and comments.
   The previous document stated that the User-Agent string had to be exactly:
   
   User-Agent: W3C-mobileOK/DDC-1.0 (see http://www.w3.org/2006/07/mobileok-ddc)
   
   A possible implementation of a mobileOK checker could be a mobileOK crawler. Although that's not a mandatory requirement, crawlers typically use the User-Agent to advertise their name and usually include a comment with a link to a "more info" page, so that servers that receive such a request can easily tell why they received it. There was no reason to prevent that, and the rule was thus relaxed to state that the User-Agent string has to start with the above string.
   

Comments on the Working Draft should be submitted to the public-bpwg-comments@w3.org public mailing-list (publicly archived)

The end of the review period is 30 June 2008, at which time, provided no further substantive changes are required, the Working Group expects to move the document forward to Proposed Recommendation as it believes the entrance criteria for that phase will be met (see the implementation report)

The Mobile Web Best Practices Working Group has published the first public working draft of the Content Transformation Guidelines document.

As stated in the abstract of the document:

The document provides means for content providers and content transformation proxies as to how inter-work when delivering Web Content.

In other words, the guidelines are mechanisms:

1. for content providers to be able to provide media-specific versions of their site based on the end-user's device, no matter if the request and response go through one or more content transformation proxies
2. for content transformation proxies to let former point happen while still be given the possibility to adapt legacy web sites that would reject the user's request as it stands because it originates from an "unusual" device.

Guidelines in the published document do not differ from the ones I mentioned in my previous post on content transformation. Among them:

• Content Transformation proxies must leave the HTTP request (resp. response) untouched if the HTTP request (resp. response) contains a Cache-Control: no-transform directive (see §4.1.1 and §4.4). To be more precise, it must behave as a transparent proxy in that case.
• Content Transformation proxies should not alter the HTTP headers unless the unaltered user's request would end up being rejected by the content provider (see §4.1.2)
• If if has altered HTTP headers, the proxy must include copies of the unaltered ones (see §4.1.4)

The document is intended to be clear and concise (although some more work may be needed on that regard in a few sections). Editorial notes in the document mark parts that are not settled yet.

The working group is looking forward for comments on these guidelines. If you think something is wrong, missing, unclear, feel free to send an email to public-bpwg-comments@w3.org.

There were a few posts [*] over the last few weeks about content transformation, and it's been some time since we launched the Content Transformation Task Force within the Mobile Web Best Practices Working Group and published a working draft of the Content Transformation Landscape document. Time for an update!

The Task Force has been working ever since on a Content Transformation Guidelines document. It's still a draft, but we should publish it as First Public Working Draft in a couple of weeks. What does the document contain so far?

HTTP headers spoofing: in an ideal world, there would be no need to change the User-Agent header whatsoever. But many legacy web sites actually return an HTTP 200 response with a: "Sorry, I don't know who you are" message when requested with a User-Agent they don't know anything about. Such sites are typically good candidates for content adaptation, and there's no other way for the transcoding proxy to get a meaningful response than to behave as a "desktop" browser...

The guidelines currently recommend a two-step approach:

• Send the original HTTP request to the server.
• If the response from the server is a "Sorry, I don't know who you are" response, then try again with a modified HTTP request, possibly changing the User-Agent in particular to whatever is needed to get a response.

With that approach, the content provider receives the original request, and the transcoding proxy still is able to handle the "Sorry, I don't know who you are" case.

Control by the content provider: use a "Cache-Control: no-transform" directive to tell the transcoding proxy not to perform any transformation. Use a "Vary" HTTP header to tell the transcoding proxy that they vary their presentation based on the User-Agent for instance.

Transcoding proxy's decision to transform: the "link" element, labeling using POWDER would be the best way to say "I'm mobile". There's no easy answer in the generic case. Page size, URI patterns, content type are examples of criteria to consider.

Feel free to subscribe/take a look at/send comments to the Content Transformation Task Force mailing-list, it's public!

[*] A few recent posts on content transformation:

• Dennis' Sprint OpenWeb Update
• Luca Passani's Rules for Responsible Reformatting
• Dennis' How Web to Mobile Transcoding Should Work
• Tom Hume's Mobile transcoding guidelines

http://dev.w3.org/2007/mobileok-ref/mobileOK-Basic-RI-1.0-deploy.jar

We'd like to announce a new "beta" release of mobileOK Basic Tests 1.0's reference implementation "checker", downloadable as an executable .jar file above.

Since the initial "alpha" release late last year, we and the developer community have identified approximately 30 issues with the implementation and fixed them, while completing several enhancements to performance. While not yet perfect, we believe the project has moved forward significantly from its initial release and has graduated to "beta" status. We know of no major issues and do not anticipate major changes before the final 1.0 release.

Developers and end users may begin to use this version with confidence, and are encouraged to contribute suggestions and bug reports to the public-mobileok-checker@w3.org mailing list.

Thanks to the several members of the MWI Best Practices Working Group who have come together to produce this remarkably useful and flexible bit of software.

Sean