W3C home > Mailing lists > Public > public-wai-ert@w3.org > June 2007

RE: MobileOK comments

From: Jo Rabin <jrabin@mtld.mobi>
Date: Wed, 13 Jun 2007 21:27:31 +0000
Message-ID: <C8FFD98530207F40BD8D2CAD608B50B43BBEA4@mtldsvr01.DotMobi.local>
To: "Jon Ribbens" <ertwg@sitemorse.com>, <public-bpwg-comments@w3.org>
Cc: <public-wai-ert@w3.org>




Thanks very much, we'll send formal responses once the last call period
is over, but meanwhile some responses in-line below.

Jo

> -----Original Message-----
> From: public-bpwg-comments-request@w3.org
[mailto:public-bpwg-comments-
> request@w3.org] On Behalf Of Jon Ribbens
> Sent: 13 June 2007 19:30
> To: public-bpwg-comments@w3.org
> Cc: public-wai-ert@w3.org
> Subject: MobileOK comments
> 
> 
> Things I noticed:
> 
> | 2.3.8 Visible Linked Resources
> | ...
> | Note that forms with method get are permissible in documents under
> | test, but must not be checked in case posting caused unwanted side
> | effects such as the addition of unwanted records to a database.
> 
> I think that's probably meant to say 'forms with method *post*'.
> Either way, it doesn't make sense in context as-is.

Oops - thanks for that.

> 
> | 3.1 AUTO_REFRESH (partial) and REDIRECTION
> 
> This section does not say what to do if no URL is specified in the
> meta content. In fact, the "Mobile Web Best Practices" document itself
> seems confused as to how the 'refresh' header works. The header
> contains a time-delay in seconds, and an optional URL. The "Mobile"
> documents seem to think it just contains a URL.

It wasn't our intention to suggest that it is the only value specified,
just that it is specified. If that is confusing then it may be worth
changing.

> 
> | 3,2 CACHING
> | ...
> | If no meta http-equiv  element is present, referring to those
> |        headers, FAIL
> | warn, and continue the test using the value from the meta content
> |        attribute.
> 
> The last line above is missing something, probably an "Else," at the
> beginning.
> 

Thanks, that would at least add to clarity and consistency. 

> I am not sure that the fact that this section is mandating warnings
> whenever content is specified as uncacheable is a good idea. Even if
> it is, it should be made explicitly clear that that is the intent
> - especially for example on the "Pragma" header, where people might
> think that it is the Pragma header itself which is being warned about.

Thanks we'll consider this. We intend to remind people that specifying
nocache routinely on mobile content is entirely counter productive - if
it is present on things like static home pages, which it often is.
> 
> | 3.3  CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE
> | ...
> | HTTP Content-Type headre
> |   application/xhtml+xml; charset=UTF-8"
> 
> Extraneous " at the end of the line.
> 
Ooops - thought we'd nailed that one prior to publication, thanks for
pointing it out.

Jo
Received on Sunday, 17 June 2007 16:28:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:28 GMT