Re: Comments on W3C mobileOK Basic Tests 1.0

 Dear Carlos Iglesias ,

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/09700B613C4DD84FA9F2FEA52188281901E232B7@ayalga.fundacionctic.org
 2. http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests-20070130/


=====

Your comment on 1.2 Applicability:
> 
> #1: Section "1.2 Applicability" reads: "The tests apply to a URI.
> Passing the tests means that _under the right circumstances_, resolving
> a URI will retrieve conformant content that is deliverd in a conformant
> manner."
> 
> It's not clear what "under the right circumstances" is intended to
> mean. What's the formal definition of "right circumstances"? Or, What
> are the wrong circumstances?


Working Group Resolution:
Reword as " ... Passing the tests means that *when accessed as described
in [2.3.2 HTTP Request]*, resolving a URI will retrieve conformant content
that is delivered in a conformant manner."

----

Your comment on 1.3 Claiming mobileOK conformance:
> #2: Section "1.3 Claiming mobileOK conformance"
> 
> There is an issue with POST parameters, which are not part of a URI.
> This is a general issue with content labelling, that could be solved
> with HTTP-in-RDF [3], but there's some doubt about whether POST
> requests are forbidden for mobile web content due to the requirement at
> section 2.3.2 "Use the HTTP GET method when making requests". Are POST
> requests forbidden for mobile web content?


Working Group Resolution:
No, POST requests are not forbidden but we don't test them as they are not
assumed to be "idempotent". We have clarified the document.

----

Your comment on 2.3.3 HTTP Response:
> #4: Section "2.3.3 HTTP Response"
> 
> "If an HTTP request fails for any reason during a test (network-level
> error, DNS resolution error, non-HTTP response, or server returns an
> HTTP 4xx or 5xx status), the test outcome should be considered FAIL"
> 
> You can (and should) evaluate any content received from the server,
> error messages included as they're also content. When the server
> returns 4xx or 5xx the result of the test should not fail, because
> otherwise the website as a hole could never be Mobile OK compliant
> (e.g. you can always make a request that will produce an 404 and thus a
> fail)


Working Group Resolution:
See http://lists.w3.org/Archives/Member/member-bpwg/2007Feb/0070.html

----

Your comment on 2.3.4 CSS Style:
> #5: Section "2.3.4 CSS Style" reads: "Style elements whose type
> attribute _is not_ text/css"
> 
> Souldn't be "Style elements whose type attribute _is_ text/css?


Working Group Resolution:
Yes, thanks, this is a typo.

----

Your comment on 2.3.5 Included Resources:
> #6: Section "2.3.5 Included resources" reads: "Images included by
> background-image properties in the CSS Style"
> 
> Is there any reason to exclude other CSS-referenceable resources like
> images referenced by the list-style-image property or .ico cursors (CSS
> cursor property)?


Working Group Resolution:
The list-style-image property should have been included. The cursor
property is not referenced as it is not CSS Level 1.

Checked for references in CSS level 1 for URL() and there is nothing
besides background-image (background etc) and list-style-image (list-style
etc)

----

Your comment on 2.3.6 Included Stylesheet Resources:
> #7: Section "2.3.6 Included Stylesheet Resources"
> 
> Do the restrictions (not alternate, charset, type, media) also apply to
> xml-stylesheet PIs?


Working Group Resolution:
the xml stylesheet processing instruction takes broadly the same
attributes as the link element and we will update the document to reflect
the same restrictions, so yes.

----

Your comment on 3.7 GRAPHICS_FOR_SPACING:
> #10: Section "3.7 GRAPHICS_FOR_SPACING" reads: "If image height and
> width are both less than 2 pixels, warn"
> 
> As 2x2 images are allowed ("at most 2x2" in the prose), the test should
> be: "If image height and width are both less than _or equal to_ 2
> pixels, warn" to be in agreement with the prose.
> 
> Moreover, shouldn't also non-transparent graphics for spacing be
> considered?


Working Group Resolution:
Thanks, we agree.

----

Your comment on 3.12 MINIMIZE:
> #12: Section "3.12 MINIMIZE"
> 
> The definition of whitespace characteres should be clarified, does it
> include CR (carriage return) for example?
> Additionally, it would make sense to consider also CSS in the
> minimization.


Working Group Resolution:
We accept the clarification and point to XML definition for white space:
http://www.w3.org/TR/REC-xml/#sec-common-syn

However, we exclude style regions for the current document but revisit for
the next Best Practices document.

----

Your comment on 3.19 PROVIDE_DEFAULTS (partial):
> #15: Section "3.19 PROVIDE_DEFAULTS" reads: "If the document contains no
> input element whose name attribute's value matches that of this radio
> input and whose checked attribute is set to some value..."
> 
> We find the wording of this test complex and confusing in general.
> The current test generates multiple warnings for each radio button in a
> group and the algorithm doesn't check that the rest of input elements
> are also radio buttons, in addition "checked" and "selected" are
> boolean attributes which only valid value is "checked" and "selected"
> respectively in XHTML or nothing in HTML (not "some value")
> 
> Proposed new wording:
> 
> For each radio button group (input elements with type="radio" that
> share the same name attribute value):
>   If not exactly one input element within this group is checked
>    (checked="checked"), warn
> 
> For each select element:
>   If there is no nested option element that is selected
>    (selected="selected"), warn
> 
> PASS
> 
> Furthermore, what happens if there is more than one nested option
> element whose selected attribute is set to some value but the
> "multiple" attribute is not set? Currently is a PASS, should it be this
> way?


Working Group Resolution:
We'll make edits to first stanza, yes, with a little editorial rewording.

----

Received on Monday, 4 June 2007 14:17:54 UTC