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

Summary of comment on Mobile OK Basic draft

From: Carlos Iglesias <carlos.iglesias@fundacionctic.org>
Date: Thu, 15 Feb 2007 18:30:24 +0100
Message-ID: <09700B613C4DD84FA9F2FEA52188281901D62FD0@ayalga.fundacionctic.org>
To: <public-wai-ert@w3.org>

Hi everybody,

In response to the action item recorded at [1],the following is a summary of the comments made on the Mobile OK Basic draft  an discussion by the group members so far [2], with the aim to facilitate further discussion:

1.2 Applicability

"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."

What does "under the right circumstances" exactly mean?

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, but there's some doubt about whether POST requests are forbidden for mobile web content (2.3.2 "Use the HTTP GET method when making requests")

2.2 Testing outcomes

The MWBP group made clear that warnings are _no_ test outcomes, it was also said that they 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.

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"

When not reaching the server it should be a not tested instead a fail (e.g 5xx server errors).
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)

2.3.4 CSS Style

"Style elements whose type attribute is not text/css"

Why the _not_?

2.3.5 Included resources

"Images included by background-image properties in the CSS Style"

What about images referenced by the list-style-image property, .ico cursors (CSS cursor property) or any other CSS-referenceable resources?

2.3.6 Included Stylesheet Resources

Do the restrictions (not alternate, charset, type, media) also apply to xml-stylesheet PIs?


"If the response specifies an Internet media type that is not "text/css", "image/jpeg" or "image/gif", FAIL"

Why are image/png or application/svg+xml not included in DDC (default definition context)?


"If the Internet media type is "text/css" and the content is not well-formed CSS (contains mismatching brackets or illegal characters), FAIL"

'contains mismatching brackets or illegal characters' is not a good example for or a definition of well-formedness in CSS. Grammar conformance (e.g. CSS1, CSS2 or CSS2.1) should be the requirement.


"If image height and width are both less than 2 pixels, warn"

As 2x2 images are allowed ('at most 2x2' in the prose), it should be: "If image height and width are both less than or equal to 2 pixels, warn"

Should also non-transparent graphics for spacing be considered?


"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 may be other properties where px values may be allowed as the background-position or the outline-width.


The definition of whitespace characteres should be clarified, does it include CR (carriage return)?
CSS should also be considered in the minimization.


"If the value of the href attribute begins with the "javascript:" scheme, FAIL"

At least, href attributes with "#" value should also fail.
A wider definition which discourages not valid href values in general would be desirable.


Should be at least a max_size warn here?


"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..."

The wording of this test is complex and confusing.
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
"checked" and "selected" are boolean attributes which only valid value is "checked" and "selected" respectively in XHTML or nothing in HTML

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


In addition, 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?


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?

[1] - [http://www.w3.org/2007/02/14-er-minutes.html#action02]

[2] - [http://lists.w3.org/Archives/Public/public-wai-ert/2007Feb/0008.html]


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 Thursday, 15 February 2007 17:31:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:55 UTC