Re: Re: please reivew mobileOK Basic Tests 1.0

 Dear Laurens Holst ,

The Mobile Web Best Practices Working Group has reviewed the comments you
sent [1] on the Last Call Working Draft [2] of the W3C mobileOK Basic
Tests 1.0 (2nd Last Call) published on 25 May 2007. Thank you for having
taken the time to review the document and to send us comments!

The Working Group's response to your comment is included below, and has
been implemented in the new version of the document available at:
http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests-20070928/.

Please review it carefully and let us know if you agree with it or not
before 19 October 2007. In case of disagreement, you are requested to
provide a specific solution for or a path to a consensus with the Working
Group. If such a consensus cannot be achieved, you will be given the
opportunity to raise a formal objection which will then be reviewed by the
Director during the transition of this document to the next stage in the
W3C Recommendation Track.

Thanks,

For the Mobile Web Best Practices Working Group,
Michael(tm) Smith
W3C Staff Contact

 1. http://www.w3.org/mid/4668801F.2090006@students.cs.uu.nl
 2. http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests-20070525/


=====

Your comment on 2.3.2 HTTP Request:
> 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.


Working Group Resolution:
The basis on which the spec is written is that a checker emulates a 
hypothetical device  - the DDC - which has exactly the capabilities
specified. The tests ensure that a Web site is capable of responding to
the needs of such a device. We encourage content providers to support more
than the needs of the basic device and take advantage of greater functions
and capabilities where they can.

----

Your comment on 2.3.2 HTTP Request:
> 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.


Working Group Resolution:
We do not think it is wrong to specify the headers in the way we do,
however we accept that we do not properly check that the right sort of
content has come back in response to the request. In other words, if the
request is made because of an img tag then the response should be an
image. We did not test for that in the draft you reviewed and we will
amend accordingly. In particular, in 3.4, <img> tags that retrieve valid
CSS delivered as text/css should for example FAIL too.

----

Your comment on 2.3.2 HTTP Request:
> 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.


Working Group Resolution:
We will insert a reference in 2.3.2 referring to 2.3.8 to make it clearer
that POST is definitely allowed as a form action in mobileOK content but
that it is simply not tested, for fear of the tester causing unwanted side
effects.

----

Your comment on 2.3.4 Meta http-equiv Elements:
> 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.


Working Group Resolution:
We allow users to specifiy for the requested document which encoding
should be used to nonetheless attempt conformance to mobileOK. In the
specific cases that are noted - character set, caching the detail of the
test itself makes sure that this is the least preferred option and that a
warn in issued if it is the only means by which the authors intentions are
indicated.

----

Your comment on 3.4 CONTENT_FORMAT_SUPPORT and VALID_MARKUP:
> 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.


Working Group Resolution:
We will add that if the resource is expected to be a stylesheet, it must
be text/css (and be valid CSS), and likewise for images and FAIL if it is
not - also that Objects need to be images in this case.

----

Your comment on 3.10 LINK_TARGET_FORMAT:
> 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.


Working Group Resolution:
This test covers external resources, which are
possibly outside the author's control. Some members of the group felt
strongly that one shouldn't FAIL on account of an external
resource. Whether the resource displays usefully is a difficult question
for a machine test to answer, and it may be that checking this aspect
becomes a mobileOK Pro test.


----

Your comment on 3.18 POP_UPS:
> 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.


Working Group Resolution:
There are a couple of use cases which are admittedly marginal where this
makes sense. It does not seem acceptable to exclude those use cases, no
matter how marginal, since they are valid and out of scope for a test on
pop-ups.

----

Received on Wednesday, 3 October 2007 03:13:16 UTC