Public document·Annotated Last Call document·View Last Call comments·
Mobile Web Best Practices Working Group Mobile Web Best Practices Working Group's Issue tracker
The mobileOK Basic Tests 1.0 document was published as a Candidate Recommendation on 30 November 2007. Issues raised during the implementation phase triggered significant changes and required the publication of a fourth Last Call on 10 June 2008. This document details the disposition of comments received during these two periods.
In the tables below, red is in the WG decision column indicates that the Working Group didn't agree with the comment, green indicates that a it agreed with it, and yellow reflects an in-between situation.
All of the issues were raised by participants of the Working Group while implementing the specification to develop the W3C mobileOK Checker.
Commentor | Comment | Working Group comments | Resolution |
---|---|---|---|
ISSUE-230 Sean Owen and Dominique Hazaël-Massieux (archived comment) |
OBJECTS_AND_SCRIPTS needs to address <object> with multiple children Dom notes that the spec assumes that <object> contains at most one child, when that is not true. This is legal: I (Sean) suggested the following rewrite to the test: .... and then the test is merely, for each <object> (that's not a child of an <object>), FAIL if it is not "usable" |
The Working Group agrees.
The Object processing rule was wrong. The test was fixed (and was further amended following discussions on ISSUE-234 below). The algorithm is defined in the OBJECTS_OR_SCRIPT test published in the Last Call that followed. |
Resolved on 17 Apr 2008:
Adopt algorithm above as Resolution to ISSUE-230 |
ISSUE-231 Sean Owen (archived comment) |
MINIMIZE should take into account whitespace in CSS Somehow this didn't make it in, for reasons lost in time. MINIMIZE should account for whitespace in CSS. The checker already counts this, just doesn't test it. |
The Working Group acknowledges the missing feature, but addressing redundant spaces in CSS opens up a series of questions that make it more difficult to resolve on a specific algorithm in a limited timeframe, e.g:
The Working Group thus resolves to leave the point for a possible future version of mobileOK. |
Resolved on 17 Apr 2008:
Leave mobileOK as is and look at CSS redundant whitespace in a new version of mobileOK |
ISSUE-234 Jo Rabin (archived comment) |
PAGE_SIZE_LIMIT Should Objects Tasted count towards the overall page weight I am concerned that while we add the size of redirections to the total page weights we ignore the size of nested objects. Dom says that it's only a HEAD that is done to taste the content. I am guessing wildly that this is not in practice so. I think we need better justification for excluding what might be enormous content transferred to the browser, merely to be discarded. i.e. I think we need empirical evidence that browsers actually do taste Objects in the "Dom" way. |
Tests show that Mobile Web browsers react differently in presence of an object element defined with a type attribute set to an incompatible MIME type. The Working Group acknowledges the difference of behavior and adapted the Object processing rule consequently.
The changes, coupled with the ones triggered by the above ISSUE-230 above, are substantive, affect the definition of the tests EXTERNAL_RESOURCES, OBJECTS_OR_SCRIPT, PAGE_SIZE_LIMIT and the definition of what an included resource is. The changes trigger the publication of another Last Call. |
Resolved on 17 Apr 2008:
Add the size of objects referenced without a type attribute indicating what type they are |
ISSUE-240 Dominique Hazaël-Massieux (archived comment) |
Remove requirement of validity to self-declared DTD validity to self-declared DTD is problematic for implementations: We could: |
The Working Group realizes that validation against the declared DOCTYPE is hard to achieve for implementers, is difficult to present to users (there would be one validation against the declared DOCTYPE and one validation against the XHTML Basic 1.1 / XHTML MP 1.2 DTD) and does not bring any strong added value as far as Mobile Web Best Practices are concerned.
The Working Group thus resolves to drop validation against the declared DOCTYPE, except when the declared DOCTYPE is an older version of XHTML Basic or XHTML MP (i.e. XHTML Basic 1.0, XHTML MP 1.0, and XHTML MP 1.1). See the CONTENT_FORMAT_SUPPORT test definition in the Last Call. |
Resolved on 17 Apr 2008:
Drop validation against declared DOCTYPE as it does not represent sufficient added value compared with the complications it introduces |
Three Last Call comments were received. They triggered a series of minor changes in the specification for clarification purposes.
In the "Commentor reply" column below, red indicates the commenter objected to the WG resolution, green indicates approval, and yellow means the commenter didn't respond to the request for feedback.
Commentor | Comment | Working Group decision | Commentor reply |
---|---|---|---|
LC-1978 Dominique Hazael-Massieux (archived comment) |
|
We agree that the "myimage.png" should not trigger a CONTENT_FORMAT_SUPPORT error, and should not be taken into account in PAGE_SIZE_LIMIT and EXTERNAL_RESOURCES. This is triggered by the note in 2.4.6 Included Resources: "object elements that are accessed in order to test their Content-Type HTTP header, but do not form part of the ultimate representation of the resource under test (see 3.15 OBJECTS_OR_SCRIPT ), are not considered to be included resources". We agree that the notion of "ultimate representation of the resource" deserves to be clarified though and the note extended to resources retrieved by section 3.15.1 Object Element Processing Rule. On the light of the discussion that followed your other comment (LC-1980) on the use of the HTTP Content-Type value to taste object element, we updated the note to specify that only resources retrieved under the 3.15.1 Object Element Processing Rule whose Content-Type is image/gif or image/jpeg are considered to be Included Resources: http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Basic-1.0-Tests/080707r#included_resources |
yes |
LC-1979 Dominique Hazael-Massieux (archived comment) |
|
We agree that the example should not raise a FAIL in CONTENT_FORMAT_SUPPORT, because "myimage.png" does not form part of the ultimate representation of the resource under test, as noted in 2.4.6 Included Resources. We clarified the note in 2.4.6 Included Resources as noted in our reply to your previous comment (LC-1978) on the need to clarify which objects and images are Included Resources, and which are not. |
yes |
LC-1980 Dominique Hazael-Massieux (archived comment) |
|
We understand that point, but note that there is not a real consistency in the way such objects are handled by mobile browsers in practice. Some browsers download all the objects and use the HTTP Content-Type header irrespective of the presence of the type attribute, while other browsers follow the type attribute and only download objects that match values of the HTTP Accept header. We think Content Providers should "benefit" (or rather should not be "punished") for this lack of consistency in mobile browsers, and decided, in the interest of returning fewer FAIL messages: 1/ to stick to the HTTP Content-Type header to determine whether an object is rendered or the fallback mechanism has to be used. 2/ to stick to our decision not to count objects that define a type attribute not set to image/gif or image/jpeg in PAGE_SIZE_LIMIT and EXTERNAL_RESOURCES. However, since we recognize that the corresponding behavior among mobile browsers is not consistent, that it is a bad practice to have a type attribute that does not match the Content-Type of the underlying resource and that it is a good practice to define the type attribute, we also introduced two additional warning messages: "If there is no type attribute, warn" "If the Internet media type of the retrieved resource, as indicated by its Content-Type HTTP header does not match that stated in the type attribute, warn" We note that our decision introduces a slight inconsistency in the way objects are treated by the specification: on the one hand, section 3.15.1 Object Element Processing Rule says that the Object must be retrieved so that the HTTP Content-Type header may be parsed, on the other hand, section 3.16 PAGE_SIZE_LIMIT (resp. 3.6 EXTERNAL_RESOURCES) says that an object defined with a type attribute set to image/png does not count as a retrieved resource (provided its actual Content-Type is not image/gif or image/jpeg). We think that it is needed though for the above mentioned reasons. |
yes |
LC-1981 Dominique Hazael-Massieux (archived comment) |
|
Yes, we agree that the text here deserved to be clarified. We updated the text consequently: - Section 3.16 PAGE_SIZE_LIMIT was clarified with regards to the treatment of HTTP response bodies that are required to retrieve a resource: http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Basic-1.0-Tests/080707r#PAGE_SIZE_LIMIT - Section 2.4.3 HTTP Response was also amended to have the reader refer to 3.16 PAGE_SIZE_LIMIT (resp. 3.6 EXTERNAL_RESOURCES) for details of the total size (resp. count) the HTTP redirect response body should be added to: http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Basic-1.0-Tests/080707r#http_response |
yes |
LC-1991 Francois Daoust (archived comment) |
|
On your first point, we think that the tests should be carried on the response body because, as specified in the HTTP (RFC 2616) section 10.4.2 401 Unauthorized, the body of the HTTP Status 401 response should be presented to the user if the authentication fails: "If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity might include relevant diagnostic information" On your second point, we think that the text deserved to be clarified and updated the relevant part to state: "If authentication information was supplied in the HTTP request (i.e. authentication failed) or if no authentication information is available, FAIL" See: http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Basic-1.0-Tests/080707r#http_response |
yes |
LC-1992 Francois Daoust (archived comment) |
|
Links in a Web page intended for mobile consumption are an important constituent of the user experience. The user should be able to "trust" that clicking on a link does not yield an error message. For that reason, we think that returning FAILs in the LINK_TARGET_FORMAT is indeed needed. However, it occurred to us that HTTP Status 406 responses could well be returned for resources tasted by section 3.15.1 Object Element Processing Rule, and that this should obviously not trigger a FAIL, so we relaxed that last condition in that case as you suggested: http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Basic-1.0-Tests/080707r#http_response |
yes |
LC-2159 Thomas Roessler on behalf of Web Security Context Working Group (archived comment) |
|
We added a section on HTTPS that refines the algorithm of determining an invalid https certificate. | yes |