Re: please reivew mobileOK Basic Tests 1.0

On 6/11/07, Simon Pieters <zcorpan@gmail.com> wrote:
>   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.

My personal opinion is that the difference between a desktop and
mobile phone-friendly page is not bridge-able with just some CSS and
media selectors. The phone (and here we are talking about low-end
phones, not big PDAs) has a drastically smaller screen, no keyboard,
no pointer, and may not even be able to load the single document
that's also written for the desktop into memory.

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.

For this reason I think the mobile (= phone) context needs to be
considered separately. It's "different enough", in the same way that I
don't think anyone seriously expects a desktop web page can be
"rendered" comparably by an audio text reader. One might reasonably
argue the web just doesn't belong on mobile then. I think there is
enough motivation for getting some kind of web access onto phones that
the BPWG should exist, and don't think its activities harm the One Web
cause. That's my speech.


> 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.

The tests check how well content works on an abstract device profile
called the Default Delivery Context, which isn't assumed to support
scripting. The relevant Best Practice here says "don't use script
unless you know the page works fine without it." A machine test can't
determine whether script is essential to the page or not, though more
likely than not it is. Given that the target device doesn't support
script, it's at least a waste of bytes. Well, that's the rationale
behind the warn, and it is not a failure for the reason you give
exactly. That is, you don't have to remove <script> to pass the
mobileOK Basic tests.


> The tests require XHTML. What is the rationale for this? My research[1]
> shows that all tested mobile browsers support HTML, and also that many
> treat application/xhtml+xml as if it were text/html (i.e., they don't use
> XML parsers). Therefore, for compatibility with existing mobile browsers,
> the guideline for authors should be to use HTML, or if they use XHTML to
> follow appendix C of XHTML 1.0 (even when using application/xhtml+xml).

If "HTML Basic" existed I think there would be a good argument to
specify it instead. XHTML Basic is useful insofar as it codifies a
mobile-friendly subset of XHTML. That is, we care about the "Basic"
part. As you say, it's already treated by many browsers as "HTML
Basic" in practice anyway.


> Does this imply that the empty string is also a FAIL? If so, I think this
> test should be removed; there are a number of cases where the empty string
> is the appropriate alt text (e.g., when an image is illustrative or merely
> repeating the previous paragraph). [2]

Let us get back to you in a proper last call comment reply with a more
authoritative answer. I believe it is intentional for the reason you
give.

Sean

Received on Wednesday, 13 June 2007 17:33:54 UTC