Re: Re: please reivew mobileOK Basic Tests 1.0

 Dear Simon Pieters ,

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/op.ttrt3deq7a8kvn@hp-a0a83fcd39d2
 2. http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests-20070525/


=====

Your comment on the document as a whole:
> 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).


Working Group Resolution:
Most mobile browsers do not support everything HTML defines. Our
experience is that XHTML Basic delivered with application/xhtml+xml is
more likely to result in a functional user experience than other
combinations.

----

Your comment on the document as a whole:
> 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.


Working Group Resolution:
We don't doubt that implementations and feature sets are improving, costs
coming down and so on. However, that has far from universally happened,
and even if it did, we believe that the context of the mobile user will
often make it desirable to present an interface that is sympathetic to
that context. In particular it is possible to pass mobileOK Basic while
using <script>; it merely generates a warn. More generally, we're not
saying you can't use <script>, just that you need to be able to deliver an
experience to baseline devices that works without script. You may do
whatever you like to other devices.

----

Your comment on 3.14 NON-TEXT_ALTERNATIVES (partial):
> 3.14 NON-TEXT_ALTERNATIVES (partial) says:
> 
>     For each img element:
> 
>        If an alt attribute is not present or consists only of white
> space,
>        FAIL
> 
>     PASS
> 
> 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]


Working Group Resolution:
No, an empty ALT tag does not cause a fail for the reasons you cite. We
will add a clarifying note.

----

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