2nd draft RE: mOK response proposal

Hi Johannes, everybody.

An updated proposal draft at the bottom and some inline responses to JK's feedback.

> apart from the GET vs. POST typo issue, Jon mentioned:
> 
> > Well, theoretically since GET is idempotent you can safely try, for
> > example, simply submitting the form with its default values.
> 
> I may have missed it, but does the mobileOK draft describe how to handle
> GET forms? Only use default values?

Agree, but I think this is a different issue and we should address it in our new comments (working on a draft).

 
> Carlos Iglesias schrieb:
> 
> > I have also no response on comment #12 [5] as I'm not sure why the issue
> with external CSS has not been addressed. IMO external CSS are implicity
> excluded by omission in the document, and I think this is the group
> intention as they explicity say they're not addressing style regions at
> this stage.
> 
> That was my assumption, too. However, ...
> 
> > Do you mean they should be explicity excluded in the document? Please
> somebody elaborate.
> 
> ... I think it could be helpful to make sure that extraneous white space
> in external CSS must not be counted, if this is the intention.

It's OK for me, I've updated the draft with this question.

Any other comments?

Regards,
 CI.

--------------------------------------

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



############  2ND DRAFT  ############

Dear MWBP group,

The ERT WG [1] has looked again at your work on "mobileOK Basic Tests 1.0" (Draft 25 May 2007) [2], and we think some of the comments from our review on the previous draft [3] has not been completely addressed, so we would like further clarification on the following issues:


#1 ORIGINAL COMMENT:
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.

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

It's not clear what you mean with "linking back to appropriate reference material", what will be the appropriate reference material? Is the intention just to link back to the mOK or BP documents as is? We think the point here is not to provide the text of a warning, but to ensure that it is clear what the potential problem associated with a warning is.


#2 ORIGINAL COMMENT:
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)

YOUR RESOLUTION:
See http://lists.w3.org/Archives/Member/member-bpwg/2007Feb/0070.html

For 300 Multiple Choices [4] a page could be displayed, apparently depending on client's capabilities [5]. It's worth reviewing DDC capabilities to see if may be also necessary carry out checks on 300 response codes.


#3 ORIGINAL COMMENT:
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.

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

Apparently there is some dependence of this test on the wording of the related BP, anyway we think this is an important issue that need to be addressed in any way before the Recommendation status because, as currently defined, this test could produce a fail outcome where it should be a pass. 


#4 ORIGINAL COMMENT:
Section "3.12 MINIMIZE"
The definition of whitespace characters should be clarified, does it include CR (carriage return) for example?
Additionally, it would make sense to consider also CSS in the minimization.

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

Apparently, external CSS are implicitly excluded by omission in the document, and it seems to be the group intention as you explicitly say they're not been addressed at this stage, however it could be helpful to make sure (explicitly) that extraneous white space in external CSS must not be counted, if this is the intention.


#5 ORIGINAL COMMENT:
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 '#') 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.

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

Although being a valid URI, the behaviour of href="#" is not defined. Several user agents have the behaviour describe above, but we think this shouldn't be considered a good practice and the linking to the top of a page should be done using a real (not empty) anchor (fragment identifier). Having said that, we still think that at least href attributes with '#' (or any number of '#') should also fail.


[1] - [http://www.w3.org/WAI/ER/]
[2] - [http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests-20070525/]
[3] - [http://lists.w3.org/Archives/Public/public-bpwg-comments/2007JanMar/0003.html]
[4] - [http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.1]
[5] - [http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html#sec12.2]


Regards,

Received on Friday, 22 June 2007 14:41:21 UTC