W3C home > Mailing lists > Public > public-bpwg-comments@w3.org > January to March 2007

Re: Comments on W3C mobileOK Basic Tests 1.0

From: Sean Owen <srowen@google.com>
Date: Tue, 6 Mar 2007 14:16:06 +0900
Message-ID: <e920a71c0703052116n8d2e7c8k57d44f3de0ffc03e@mail.gmail.com>
To: "Carlos Iglesias" <carlos.iglesias@fundacionctic.org>
Cc: public-bpwg-comments@w3.org, public-wai-ert@w3.org
Thank you, this is fantastic and comprehensive feedback. I will make
sure each item is added to the list of comments that the group is
beginning to review now.

Sean

On 3/6/07, Carlos Iglesias <carlos.iglesias@fundacionctic.org> wrote:
>
>
> Dear MWBP group,
>
> The ERT WG [1] has looked at your work on "mobileOK Basic Tests 1.0" (Draft 30 January 2007) [2], the following feedback for your consideration resulted from our discussion, we hope it will be of help to you in progressing this work:
>
> #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?
>
> #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?
>
> #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.
>
> #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)
>
> #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?
>
> #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)?
>
> #7: Section "2.3.6 Included Stylesheet Resources"
>
> Do the restrictions (not alternate, charset, type, media) also apply to xml-stylesheet PIs?
>
> #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]?
>
> #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.
>
> #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?
>
> #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.
>
> #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.
>
> #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.
>
> #14: Section "3.17 PAGE_TITLE"
>
> A max_size warn may also make sense here.
>
> #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?
>
> #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?
>
>
> Regards,
>   Carlos Iglesias for ERT WG
>
> [1] - [http://www.w3.org/WAI/ER/]
> [2] - [http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests-20070130/]
> [3] - [http://www.w3.org/TR/HTTP-in-RDF/]
> [4] - [http://www.w3.org/TR/WCAG20/conformance.html#baseline]
> [5] - [http://www.google.com/codesearch?hl=en&lr=&q=href%3D%22%23%23%23%22&btnG=Search]
>
> -----
> Carlos Iglesias
>
> CTIC Foundation
> Science and Technology Park of Gijón
> 33203 - Gijón, Asturias, Spain
>
> phone: +34 984291212
> fax: +34 984390612
> email: carlos.iglesias@fundacionctic.org
> URL: http://www.fundacionctic.org
>
>
Received on Tuesday, 6 March 2007 05:16:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 15 June 2012 12:13:30 GMT