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 2.2 Testing Outcomes:
> #3: Section "2.2 Testing outcomes"
> 
> The MWBP group have know made clear that warnings are _no_ test
> outcomes but it was also said that the group do not want to specify
> _which_ warning may be generated. In order for the tool developer to
> create a reasonable warning, it would help him to know at least the
> specific purpose why a warning has to be generated.


Working Group Resolution:
The checker will provide a reference implementation of what the
warning/error text should be for each warning or error, also linking back
to appropriate reference material.

----

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 3.4 CONTENT_FORMAT_SUPPORT:
> #9: Section "3.4 CONTENT_FORMAT_SUPPORT" reads: "If the Internet media
> type is "text/css" and the content is not well-formed CSS (contains
> mismatching brackets or illegal characters), FAIL"
> 
> We think "contains mismatching brackets or illegal characters" is not a
> good example for nor a definition of well-formedness in CSS. Grammar
> conformance (e.g. CSS1, CSS2...) is apparently the suitable
> requirement.


Working Group Resolution:
We will clarify the wording to make it clearer and reference the
appropriate specifications.

----

Your comment on 3.4 CONTENT_FORMAT_SUPPORT:
> #8: Section "2.4 CONTENT_FORMAT_SUPPORT" reads: "If the response
> specifies an Internet media type that is not "text/css", "image/jpeg"
> or "image/gif", FAIL"
> 
> As currently defined, if you use content formats like "image/png" or
> "application/svg+xml" that are not included in the DDC (default
> delivery context) you can't get the mobileOK label. This could be a
> limitation for the evolution of content formats in the mobile web, and
> for the label itself as it only promotes basic content formats and
> other formats will be always excluded. Is there any plan to support a
> more flexible mechanism similar to the WCAG 2.0 "baseline concept" [4]?


Working Group Resolution:
Narrowly speaking, you can use such formats in the object element. However
those formats were intentionally excluded from the DDC.

We anticipate updating the definition of the DDC from time to time.

We do not plan, at present, to support a WCAG 2.0 style Baseline Concept.
We are investigating this idea for a subsequent version.

----

Your comment on 3.8 IMAGE_MAPS:
> #16: 3.8 IMAGE_MAPS, 3.14 NON-TEXT_ALTERNATIVES, 3.22 SYTLE_SHEETS_USE
> and 3.25 TABLES_NESTED
> 
> All of them are designed so that there's certain "overlap" between test
> cases because all their conditions are also XHTML Basic 1.1 validation
> conditions. Once XHTML Basic 1.1 validation is required at 3.4
> CONTENT_FORMAT_SUPPORT, if test 3.4 pass all the previously mentioned
> (3.8, 3.14, 3.22 and 3.25) are also going to pass so, are they
> necessary?


Working Group Resolution:
mobileOK tests are intentionally expressed in an independent way. Section
2.3.1 (Order of tests) says that "mobileOK Basic does not prescribe the
order in which tests are to be carried out as they may be executed
independently". In order to keep the independence of test, each test
description is seen as a unit. Of course, it is obvious that
implementations will benefit from tests previously executed on a URI so
subsequent tests applied to that same URI can be done taking as few time
and computer resources as possible.

----

Your comment on 3.11 MEASURES:
> #11: Section "3.10 MEASURES" reads: "If the value is non-zero and the
> unit is not "em", "ex" or "%", and the property is not a margin, border
> or padding box property (see also 3.20 SCROLLING (partial) ), FAIL"
> 
> There are other CSS properties where px values may be allowed as the
> background-position or the outline-width.


Working Group Resolution:
We agree with the basic point but we will address it in the next phase of
the Best Practices document instead.

----

Your comment on 3.15 OBJECTS_OR_SCRIPT (partial):
> #13: Section "3.15 OBJECTS_OR_SCRIPT"
> 
> "If the value of the href attribute begins with the "javascript:"
> scheme, FAIL"
> 
> At least, href attributes with "#" (or any number of '#' [5]) value
> should also fail as it's a widely used value. A wider definition which
> discourages any misuse of href values in general would be desirable.


Working Group Resolution:
We think that there are valid uses for allowing # as the href, such as a
link to the top of the page.

----

Your comment on 3.17 PAGE_TITLE (partial):
> #14: Section "3.17 PAGE_TITLE"
> 
> A max_size warn may also make sense here.


Working Group Resolution:
The group cannot determine a valid value for such a limit.

----

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 Thursday, 7 June 2007 16:12:06 UTC