> It is not a test for browsers, user agents or mobile devices,
> and is not intended to imply anything about the way these should
> behave.

In practice, the draft is implying expectations about UA behavior.

> Content passing the tests demonstrates that the content provider
> has
> taken basic steps to provide a functional experience for mobile
> users.

I don't like the implication that pointy-haired managers are likely
to take statements like this and bother their teams about hunting a
badge of approval instead of testing that their sites work with
browsers that run on mobile devices and are capable of browsing the
real World Wide Web.

> The draft is premised on a vision about mobile browsing that assumes
> special mobile content. Instead of implying a separate Mobile Web, I
> think the W3C should push for one World Wide Web with mobile browsers
> that can access general Web content.
> [...]
> The premise of mobileOK seems to be that you take the non-Web-ready thin
> browser and expect origin servers out there take special steps to
> accommodate it.

This is a fundamental criticism I have of the mobileOK guidelines. Mobile
phone networks here in the UK have been promoting their "access the whole
Web on your phone" capabilities for years. They can even do scripting [1].

Because so much web content is text/html, surely it is more useful to work
on improving support for that in UAs? Mainstream mobile UAs already have
better support for HTML than XHTML, many having no support at all for XHTML
[2]. I can browse the text/html Web fine on my mobile phone in the
here-and-now.

PDF and Word documents are also more common than XML formats on the web, in
my experience. Improving support for them would surely be the next logical
priority after HTML?

Advising against W3C technologies such as HTML and PNG seems like a strange
move for a W3C Working Group to take. Especially since these technologies
are already implemented widely.

> I do think it's feasible to write once for the desktop and some kind
> of portable device, but such a device is substantially different from
> what people have in their average phone / browser.

Perhaps the Default Delivery Context (DDC) is out of date? It seems to be
based on mobile phones produced in the mid-1990's. They have become
radically more capable in the decade since then. My experience is mainstream
mobiles getting closer to desktop browsers each year (Opera [1] and Webkit
[2] being industry leaders in this regard).

The mobile industry's aims are clear from their actions: make the whole web
available [3][4]. Surely W3C's MWI should be centered on making that happen
faster and more effectively? The current work seems to be on degrading
current content to accomodate a DDC akin to decade-old phones which, AFAIK,
no longer exist.

Vodafone [5], T-Mobile [3] and Three [6] already have a flat rate for web
access in the UK (as Simon Pieters speculated on). So for one thing, the
financial cost of page downloads is being solved by market factors...just
like it did for desktop PCs. :-)

> If "HTML Basic" existed I think there would be a good argument to
> specify it instead.

Since text/html work has started again at W3C in the form of the HTMLWG,
perhaps an "HTML Basic" spec would now be feasible? Then again, the 1998
attempt at this [7] didn't take off, so reduced HTML was not the solution
even with devices *that* limited. And since current mobiles handle full HTML
websites, degrading content at the origin server seems ever more unnecessary
(the network can do this on-the-fly if it needs to be done).

Sincere thanks for taking the feedback from the new HTMLWG seriously. I too
hope HTMLWG will add more practical value to the W3C's Mobile Web Initiative
(MWI) [8].

As I understand it, the tests suggest that authors use a separate version
for desktop and for mobiles. I can understand that doing so can be
desireable today for the following reasons:

1. Users have to pay per byte for browsing on the mobile.
2. The connection speed on mobiles is slow.
3. Many mobile browsers have bad support for CSS.

On the longer term, (1) should be addressed by providers offering monthly
fees; (2) should be addressed by improving mobile networks, and (3) by
improving the implementations. (2) and (3) are already happening, and I
wouldn't be surprised if (1) happened soon. When these have been
addressed, there is little reason for authors to provide separate versions
for mobiles and for desktop, as opposed to using one version that works
for both.

The tests warn for things that are not supported on some mobile devices,
such as scripting, even though it is possible to provide fallback content
for UAs without scripting and including scripts doesn't harm UAs that
don't support it. I would suggest not warning for things that don't harm
mobile browsers and could benefit other UAs, in the interest of not
putting unnecessary strain on authors.

> mobileOK Basic is a scheme for assessing whether Web resources (Web
> content) can be delivered in a manner that is conformant with
> Mobile
> Web Best Practices [BestPractices] to a simple and largely
> hypothetical mobile user agent, the Default Delivery Context.

The draft is premised on a vision about mobile browsing that assumes
special mobile content. Instead of implying a separate Mobile Web, I
think the W3C should push for one World Wide Web with mobile browsers
that can access general Web content.

Mobile access to general Web content can be accomplished in at least
two ways:
1) Putting a World Wide Web-ready browser engine on the mobile device
(e.g. Minimo, the new S60 Browser, Opera for Mobile)
2) Using a distributed UA that puts a thin front end on the mobile
and keeps the main engine on an intermediate server (e.g. Opera Mini)

The premise of mobileOK seems to be that you take the non-Web-ready
thin browser and expect origin servers out there take special steps
to accommodate it.

> 1.3 Claiming mobileOK conformance
>
> A standard mechanism will be defined that allows content
> providers to
> claim that a URI or group of URIs, such as a Web site, conforms to
> mobileOK Basic or mobileOK Pro. It will be possible to make
> claims in
> a machine-processable form. It will also be possible to notify end
> users of the presence of the claim by means of a human-readable
> mark.

I think testing content along the lines of mobileOK should be part of
the internal quality assurance process of content providers. I think
it should not be part of the external marketing process.

When people are just hunting the badge for marketing purposes, they
may make silly workarounds to please the testing software while
actually making the user experience worse.

On another point, Content-Type of the response for both image and style
sheet requests is simply ignored. The image type is determined through
sniffing and in case of a linked style sheet it is simply parsed as CSS.
This is more or less required for user agents if they want to support web
pages out there.

Second, in that same section, I think saying that UAs must send
â€˜exactlyâ€™ this header is not desirable. That would prevent UAs from
handling additional media types, such as image/png or image/svg, and
limit innovation. After all, the UA would not be able to claim a
mobileOK label anymore. The spec should say that UAs must send exactly
this or a superset of this header.

COMMENT B.7:
- comment nature: [typo]
- location: 2.3.8
- current wording: Note that forms with method _get_ are permissible in
documents under test, but must not be checked in case posting caused
unwanted side effects such as the addition of unwanted records to a
database.
- suggested revision: Note that forms with method _POST_ are permissible
in documents under test, but must not be checked in case posting caused
unwanted side effects such as the addition of unwanted records to a
database.
*rationale: We think it's a typo as currently POST is the method that
it's not been checked

| 2.3.8 Visible Linked Resources
| ...
| Note that forms with method get are permissible in documents under
| test, but must not be checked in case posting caused unwanted side
| effects such as the addition of unwanted records to a database.

I think that's probably meant to say 'forms with method *post*'.
Either way, it doesn't make sense in context as-is.