Re: Comments on WD-mobileOK-basic10-tests-20070130

 Dear Kai Hendry ,

The Mobile Web Best Practice Working Group has reviewed the comments you
sent [1] on the Last Call Working Draft [2] of the W3C mobileOK Basic
Tests 1.0 published on 30 Jan 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-20070525/

Please review it carefully and let us know if you agree with it or not
before 22 June 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 Practice Working Group,
Michael(tm) Smith
W3C Staff Contact

 1. http://www.w3.org/mid/20070306131142.GH6799@iki.fi
 2. http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests-20070130/


=====

Your comment on the document as a whole:
> Anyway it would be good if some mobile developing hints were just
> implemented by a normal W3C HTML validator like
> http://validator.w3.org/
> or Unicorn. Anyone working on that? Banging out this bureaucratic
> document "W3C mobileOK Basic Tests 1.0" seems a waste of time and
> resources.
> 
> You need to evolve faster.


Working Group Resolution:
Thank you for your comment.  We feel this is out of scope for this group
as we focus on mobile specifically, and mobile is different enough from
the web to warrant separate attention and tools right now. However, the
reference implementation for mobileOK checker (based on mobileOK Basic
Tests) may be become part of a future general HTML validation scheme if
appropriate, and will hopefully replace the implementation behind
validator.w3.org/mobile

----

Your comment on 2.3.2 HTTP Request:
> First off, why the application/xhtml+xml? Do you have any idea about
> the
> problems with this? When will you see the light with HTML?
> http://simon.html5.org/articles/mobile-results
> 
> I would love to know of a single mobile phone sporting a conforming
> XML
> processor. :)


Working Group Resolution:
We recognize that there are not many conforming XML processors, but
recommend the use of application/xhtml+xml because that is what is
recommended by device manufacturers. In addition we permit the use of
text/html and application/vnd.wap.xhtml+xml

----

Your comment on 3.4 CONTENT_FORMAT_SUPPORT:
> Why not support text/plain in CONTENT_FORMAT_SUPPORT? :)


Working Group Resolution:
The point of mobileOK is to demonstrate that the content provider has
taken basic steps to provide a functional user experience. We don't
consider text/plain to qualify as taking basic steps as retrieval of a
text/plain document may leave the mobile user in a difficult navigational
position.

----

Your comment on 3.16 PAGE_SIZE_LIMIT:
> PAGE_SIZE_LIMIT size is slowly becoming a less of an issue, it's more
> latency with mobiles. Can't you see you're writing a document doomed
> to
> be become obsolete?


Working Group Resolution:
Page size limit refers both to the physical capacity of devices and to the
ergonomics of user access to larger pages. The WARN at 10K reflects this.
The FAIL at 20K will over time need to be updated as devices become more
capable.

----

Your comment on 3.20 SCROLLING (partial):
> Many issues here (SCROLLING, POP_UPS etc.) could be handled by a smart
> UA (and proxy esp for imgs). Telling authors they can't have tables
> more
> that 2x2 seems a little daft. You will risk content developers
> creating
> separate mobile device targeted Web pages.  Is that what you want to
> see
> happen?
> 
> So many of these failures could be warnings IMO, in order not to scare
> content creators.


Working Group Resolution:
Yes we believe that in most cases a single page can't serve both mobile
and web users adequately, and this requires specialized treatment of
mobile devices. Whether you author a separate resource without tables, or
use an adaptation engine to remove tables is an implementation decision
left to the author. This group's output by definition assumes that one
needs to think about mobile separately, but is only concerned with what is
delivered to mobile devices and not how it is authored.

----

Received on Thursday, 7 June 2007 16:11:59 UTC