Re: please reivew mobileOK Basic Tests 1.0

Hi MobileOK working group.

I’ve looked at your specification, and have a couple of remarks.

First, section 2.3.2 HTTP Request states:

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

I think this is incorrect, text/css should NOT be included in the Accept 
header, and image/jpeg and image/gif ONLY if the UA is expected to 
support showing these images independantly of a document (the mobileOK 
tests should explicitly check whether this is supported). The client 
after all does not know how to handle a text/css file independently of 
XML markup.

Instead, it should send an "Accept: text/css" header when the CSS files 
that are linked using <link rel="stylesheet">, <?xml-stylesheet?> or 
@include. Similarly, images referenced from <img> should send an 
"Accept: image/jpeg,image/gif" header. Aside from checking the Accept 
header for the main page, the mobileOK tests should also check that 
Accept headers send these values for stylesheet and image requests.

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.

Third, in that same section, there is a requirement that only HTTP GET 
methods can only be used. What about form submissions with POST? Forcing 
forms to be sent with the GET method seems undesirable and impairs the 
HTTP functionality. It seems a silly limitation too, because if a 
mobileOK Basic application must support HTTP and HTTPS, and Basic and 
Digest HTTP authentication, then surely support for POST would be 
trivial. The mobileOK tests should provide tests for checking proper 
cache clearing after a POST request has been done on a URL.

Fourth, section 2.3.4 Meta http-equiv Elements: why are these supported 
at all, especially Content-Type and Cache-Control? In section 3.3, a 
<meta> element is listed as an option to indicate character encoding, 
given that there is an XML declaration and this <meta> only complicates 
character set detection, I do not see a reason for allowing this.

Fifth, in 3.4 CONTENT_FORMAT_SUPPORT  and VALID_MARKUP it does not 
distinguish included resources by type, that is, if it’s a stylesheet 
include, only the text/css media type should be accepted (otherwise 
FAIL), and if it’s an image include, only image/gif or image/jpeg is 
accepted and not text/css. If it’s an object include, unless the UA is 
expected to support CSS there by showing it somehow, text/css should 
also not be accepted.

Sixth, in 3.10 LINK_TARGET_FORMAT, it states:

> If the |Content-Type| header value of the HTTP response is not 
> consistent (determined in the same way as specified in *3.3 
> CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE* 
> <http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests-20070525/#test_character_encoding_support>) 
> with the |Accept-Charset| header in *2.3.2 HTTP Request* 
> <http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests-20070525/#http_request>, 
> *warn*

This should be a FAIL condition. Character set mismatches are very 
undesirable (especially from an i18n perspective) and will create 
significant hindrances for most non-English users, whose languages have 
accents or even do not use our alphabet at all.

If you want to support ISO-8859-1 in some way to make it easier for 
existing sites to server with the mobileOK label, ISO-8859-1 should 
simply be processed appropriately and added to the Accept-Charset header.

Seventh, in section 3.18 POP_UPS, target attributes on links with values 
"_self", "_parent", or "_top" are accepted. All of these should FAIL, 
however, since their presence does not make sense (and is a waste of 
bandwidth) considering the requirements put forth in 3.13 NO_FRAMES.

That is it, I hope these comments were useful, and you will modify the 
specification where necessary.

I am not subscribed to the public-bpwg-comments list, so please CC me in 
responses.


~Grauw

Dan Connolly schreef:
> I recently realized that this spec has various things
> to say about how people should use HTML, so this working
> group should be looking at it:
>
>   W3C mobileOK Basic Tests 1.0
>   http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests-20070525/
>   W3C Working Draft 25 May 2007
>   comments due to public-bpwg-comments@w3.org by 22 June 2007
>
> That's a 2nd last call; earlier releases pre-date the launch
> of this WG, so they didn't hit my radar.
>
> Everyone is welcome to take a look and send any comments
> you have directly to public-bpwg-comments@w3.org .
>
> If you have any comments that you think should be endorsed
> by this Working Group, also send them here. If there's a critical
> mass of support, I'm interested to make a formal decision
> an notify the Mobile Web Initiative Best Practices Working Group.
>
> Note that if we don't say anything, some will assume our
> endorsement.
>
>   


-- 
Ushiko-san! Kimi wa doushite, Ushiko-san nan da!!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Laurens Holst, student, university of Utrecht, the Netherlands.
Website: www.grauw.nl. Backbase employee; www.backbase.com.