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

Re: ERT WG comments on mobileOK Basic Tests 1.0 LCWD of 25 May, 2007

From: <mike@w3.org>
Date: Sat, 29 Sep 2007 15:51:26 +0000
To: Shadi Abou-Zahra <shadi@w3.org>
Cc: public-bpwg-comments@w3.org
Message-Id: <E1IbebG-0007Nk-MP@wiggum.w3.org>


 Dear Shadi Abou-Zahra ,

The Mobile Web Best Practices Working Group has reviewed the comments you
sent [1] on the Last Call Working Draft [2] of the W3C mobileOK Basic
Tests 1.0 (2nd Last Call) published on 25 May 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-20070928/.

Please review it carefully and let us know if you agree with it or not
before 19 October 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 Practices Working Group,
Michael(tm) Smith
W3C Staff Contact

 1. http://www.w3.org/mid/467D1CEE.5050201@w3.org
 2. http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests-20070525/


=====

Your comment on the document as a whole:
> COMMENT B.1:
> - comment nature: [substantial]
> - location: All the tests
> - current wording: It looks like PASSES and FAILS are defined as "final
> 
> states" that interrupt the algorithm (otherwise all the algorithms will
> 
> always produce a PASS, as it's always the last instruction)
> - suggested revision: Tests algorithms should be describe in a way that
> 
> provide messages for every fail or warning
> - rationale: If they not do so, then the algorithm would be useless for
> 
> tracking reasons, you can use them to know if something PASS or FAIL, 
> but not to know the details.


Working Group Resolution:
We agree that the wording of 2.3.1 could be improved to clarify that PASS
means stop. FAIL means FAIL the whole test but try to continue in order to
generate as much info as possible. If a FAIL has been encountered,
encountering a subsequent PASS does not reverse that state. 

In addition, we have provided a unique ID for each warn and FAIL as noted
in response to another of your comments.

----

Your comment on 2.2 Testing Outcomes:
> COMMENT A.1: - ERT WG 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. - BPWG 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. - ERT WG RESPONSE: It's not clear what you mean
> with "linking back to appropriate reference material". What will the
> appropriate reference material be? 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.


Working Group Resolution:
We intend to identify each FAIL and warn with a specific identifier and
the messages produced by the checker will refer to these references in
mobileOK - the relevant section in mobileOK refers to the section in the
BP document from which it derives.


----

Your comment on 2.3.2 HTTP Request:
> COMMENT B.3:
> - comment nature: [clarification]
> - location: 2.3.2 HTTP Request
> - current wording: Use the HTTP GET method when making requests.
> - suggested revision: Clarify how to proceed while testing GET
> requests. 
> E.g. use only default values
> - rationale: It's quite clear now (see related #7 comment) what are the
> 
> reasons to leave POST requests out, nevertheless there's no clear 
> indication on how to proceed while testing GET requests.


Working Group Resolution:
We agree that submission of forms needs clarification, and will adjust the
text of 2.3.8 visible linked resources to reflect this.

----

Your comment on 2.3.2 HTTP Request:
> COMMENT B.4:
> - comment nature: [clarification]
> - location: 2.3.2 HTTP Request
> - current wording: Use Implementations must support URIs with both http
> 
> and https  scheme components.
> - suggested revision: Clarify how to proceed with different URI
> schemes.
> - rationale: It's not clear what should be done when you find a 
> different URI scheme. Ignore it?


Working Group Resolution:
Add text - URIs specified with other schemes MUST be ignored.

----

Your comment on 2.3.2 HTTP Request:
> COMMENT B.8:
> - comment nature: [editorial]
> - location: 2.3.8
> - current wording: Note that forms with method POST are permissible in
> 
> documents under test, but must not be checked in case posting caused 
> unwanted side effects such as the addition of unwanted records to a 
> database.
> - suggested revision: Add a similar note before 2.3.2 HTTP Request
> *rationale: We think this clarification should also be done before as 
> it's also quite relevant to correctly understand why at 2.3.2 the use
> of 
> GET method is required.


Working Group Resolution:
Add a note under 2.3.3 - at the point where GET is specified - saying See
also 2.3.8 on submission of forms.

----

Your comment on 2.3.3 HTTP Response:
> COMMENT A.2:
> - ERT WG 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)
> - BPWG RESOLUTION:
> See http://lists.w3.org/Archives/Member/member-bpwg/2007Feb/0070.html
> - ERT WG RESPONSE:
> For 300 Multiple Choices [1] a page could be displayed. Apparently this
> 
> depends on client capabilities [2]. It's important to clarify how to 
> handle 300 response codes where the page is displayed.
>   -[1]
> <http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.1>
>   -[2] <http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html#sec12.2>


Working Group Resolution:
We will add a note clarifying that when a 3xx response is received the
value of the Location header should be used to redirect. If no Location
header is present, FAIL.

----

Your comment on 2.3.3 HTTP Response:
> #5 COMMENT
> - comment nature: [clarification]
> - location: 2.3.3 HTTP Response
> - current wording: If the HTTP status indicates redirection (status
> code 
> 3xx):
>    Do not carry out tests on the response
> - suggested revision: It's not clear what to do with invalid location 
> header values (URIs that are not absolute.
> absoluteURI   = scheme ":" ( hier_part | opaque_part )
> - rationale: Quite a lot of servers create
>     Location: /foo.bar
>    instead of
>     Location: http://www.example.org/foo.bar


Working Group Resolution:
Add the text "if the URI identified by the Location header is not an
absolute URI, warn, and create an absolute URI by combining the Location
header value with the absolute URI of the request.

----

Your comment on 2.3.5 CSS Style:
> COMMENT B.5:
> - comment nature: [editorial]
> - location: 2.3.5 CSS Style
> - current wording: resources linked by xml-stylesheet  processing 
> instructions
> - suggested revision: resources linked by xml-stylesheet  processing 
> instructions, as defined in 2.3.7 Included Style Sheet Resources"
> - rationale: It make sense to reference the normative definition


Working Group Resolution:
Add clarification along the lines suggested.

----

Your comment on 2.3.5 CSS Style:
> COMMENT B.6:
> - comment nature: [clarification]
> - location: 2.3.5, 2.3.6, 2.3.7
> - current wording: At 2.3.5 is said that the CSS style must be assemble
> 
> using @import rules among others, and at 2.3.6 this rules are also 
> included in the definition of included resources, but at 2.3.7 there in
> 
> no mention to @import while defining included style sheets that are 
> taken into account when calculating the page size.
> - suggested revision: Include @import rules into the page size
> calculation
> - rationale: If CSS provided by @import rules is going to be analysed 
> then it should also be taken into account while calculating the page
> size.


Working Group Resolution:
Add clarification along the lines suggested in fact 2.3.7 is done away
with as a separate section.

----

Your comment on 2.3.6 Included Resources:
> COMMENT B.7:
> - comment nature: [typo]
> - location: 2.3.8
> - current wording: Note that forms with method _get_ are permissible in
> 
> documents under test, but must not be checked in case posting caused 
> unwanted side effects such as the addition of unwanted records to a 
> database.
> - suggested revision: Note that forms with method _POST_ are
> permissible 
> in documents under test, but must not be checked in case posting caused
> 
> unwanted side effects such as the addition of unwanted records to a 
> database.
> *rationale: We think it's a typo as currently POST is the method that 
> it's not been checked


Working Group Resolution:
Change GET to POST in this section as indicated

----

Your comment on 2.3.9 Validity:
> COMMENT B.9:
> - comment nature: [clarification]
> - location: 2.3.9 Validity
> - current wording: "CSS > A resource is considered a valid CSS resource
> 
> if it conforms to the grammar defined in [CSS], Appendix B."
> - suggested revision: Include all the properties that are allowed in
> the 
> definition of Valid CSS
> - rationale: It's not clear what CSS properties are allowed as, apart 
> from those in the CSS1 Recommendation, there are mentions at least to 
> @media (3.21) and position (3.20).


Working Group Resolution:
Add test to 2.3.9 stating that the @media rule is also allowed. Also add a
note saying that properties that are not defined in CSS Level 1 do not
cause a validity failure. Change text in 3.21 STYLE_SHEET_USE to remove
the reference to Validity and 'valid CSS Level 1' and replace with text
stating that properties and values that are not defined in CSS Level 1
cause the warn

----

Your comment on 3.2 CACHING:
> COMMENT B.11:
> - comment nature: [clarification]
> - location: 3.2 CACHING
> - current wording: In the following, note that HTTP headers should be 
> used rather than meta elements with http-equiv attributes, which are 
> commonly not taken into account by proxies. Where both a meta element 
> and the corresponding header are found the value of the header must be
> used.
> - suggested revision: Clarify what to do in the absence of HTTP
> headers, 
> should meta elements be used?
> - rationale:


Working Group Resolution:
This has been reworded and a reference inserted to the discussion of meta
in section 2 which makes it clear that only in three cases are meta
http-equiv elements taken into account

----

Your comment on 3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE:
> COMMENT B.12:
> - comment nature: [typo]
> - location: 3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE
> - current wording: application/xhtml+xml; charset=UTF-8"
> - suggested revision: Remove '"'
> - rationale:


Working Group Resolution:
Thanks that was indeed a typo

----

Your comment on 3.4 CONTENT_FORMAT_SUPPORT and VALID_MARKUP:
> COMMENT B.14:
> - comment nature: [clarification]
> - location: 3.4 CONTENT_FORMAT_SUPPORT  and VALID_MARKUP
> - current wording: If the document is an HTML document
> - suggested revision: What is "an HTML document" here? Which 
> characteristics are to be checked?
> - rationale: Is not clear if there's any algorithm to check whether 
> something is an HTML document or not as it's not clear what you should
> 
> look for in absence of an HTML document definition.


Working Group Resolution:
We mean html as the root element and will add a clarification to that
effect.

----

Your comment on 3.6 EXTERNAL_RESOURCES:
> COMMENT B.15:
> - comment nature: [editorial]
> - location: 3.6 EXTERNAL_RESOURCES
> - current wording: "Note that if an HTTP request is unsuccessful while
> 
> conducting this test, the result is FAIL"
> - suggested revision: Include this condition in the general algorithm
> - rationale: It's the only condition that affects to the result and
> it's 
> out of the general algorithm, this way it could be easily leave out


Working Group Resolution:
It's reworded to refer to the genenral algorithm which contains the FAIL
already.

----

Your comment on 3.6 EXTERNAL_RESOURCES:
> COMMENT B.16:
> - comment nature: [clarification]
> - location: 3.6 EXTERNAL_RESOURCES
> - current wording: "Note that if an HTTP request is unsuccessful while
> 
> conducting this test"
> - suggested revision: Clarify what means unsuccessful here
> - rationale:


Working Group Resolution:
The clarification suggested under LC-1756 covers this point too.

----

Your comment on 3.6 EXTERNAL_RESOURCES:
> COMMENT B.17:
> - comment nature: [typo]
> - location: 3.6 EXTERNAL_RESOURCES
> - current wording: Count the total number of unique included resources,
> 
> as defined in 2.3.6 Included Resources
> - suggested revision: Add '.'
> - rationale:


Working Group Resolution:
Thanks, yes.

----

Your comment on 3.11 MEASURES:
> COMMENT B.19:
> - comment nature: [clarification]
> - location: 3.11 MEASURES
> - current wording: "For each property in the CSS Style whose value is a
> 
> numeric measure of length stated together with a unit
> If the value is non-zero and the unit is not "em" or "ex"..."
> - suggested revision: The current wording could give the impression
> that 
> numeric measures without units are allowed, which in general is not a 
> good idea with some exceptions.
> - rationale: Although this issue could be already covered by CSS 
> validation, redundancy could be helpfull for the shake of
> completeness in this test as "mobileOK tests are intentionally
> expressed 
> in an independent way"


Working Group Resolution:
Add to STYLE_SHEET_USE:
If the CSS Style contains a property with a value that is inappropriate to
it, FAIL
If the CSS Style contains a property with a value that requires a unit or
a percentage:
  If the unit (or percentage) is not present, FAIL
  If the unit (or percentage) is inappropriate to the value, FAIL

----

Your comment on 3.11 MEASURES:
> COMMENT A.3:
> - ERT WG 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.
> - BPWG RESOLUTION:
> We agree with the basic point but we will address it in the next phase
> 
> of the Best Practices document instead.
> - ERT WG RESPONSE:
> We acknowledge the dependency of this test on the wording of the
> related 
> BP. However, we think this is an important issue that needs to be 
> addressed in this document before it reaches Recommendation status. As
> 
> currently defined, this test could produce a fail outcome where it 
> should be a pass. This could also lead to ambiguity amongst different 
> checker tools.


Working Group Resolution:
RESOLUTION: Modify measures to state that px measures are tested only CSS
level 1 properties.

CSS Properties that take a <length> are: font-size, background-position, 
word-spacing, letter-spacing, text-indent, line-height, width and height
(as well as margin, borders and padding). The BPWG did not consider that
these other properties justified an exclusion from this test.

----

Your comment on 3.11 MEASURES:
> COMMENT B.18:
> - comment nature: [clarification]
> - location: 3.11 MEASURES
> - current wording: "For each property in the CSS Style whose value is a
> 
> numeric measure of length stated together with a unit
> If the value is non-zero and the unit is not "em" or "ex"..."
> - suggested revision: Why has been % left out? is it not considered an
> unit?
> - rationale: As currently expressed it's not clear what to do with 
> percentages


Working Group Resolution:
We removed % in an earlier draft as it is not a unit. Clarify by
rephrasing as If the value is non-zero has a unit and the unit is not "em"
or "ex" (and the value is not a percentage)

----

Your comment on 3.12 MINIMIZE:
> COMMENT A.4:
> - ERT WG 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.
> - BPWG 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.
> - ERT WG RESPONSE:
> While we think that handling extraneous white space in external CSS 
> would be useful at this stage, we recommend to at least add a clear
> note 
> about how it is (not) handled in the current document.


Working Group Resolution:
 RESOLUTION: The clarification of meaning of white space has been handled
under LC-1703 and we don't think that we should look at CSS white space in
this iteration of the document anhd will add a note clarifying that it is
not handled

----

Your comment on 3.12 MINIMIZE:
> COMMENT B.20:
> - comment nature: [editorial]
> - location: 3.12 MINIMIZE 3.15 OBJECTS_OR_SCRIPT 3.17 PAGE_TITLE
> - current wording: "white space"
> - suggested revision: Link to the "normative" definition of white space
> 
> at 2.3.10 White Space
> - rationale: Once you have a "normative" definition it make sense to 
> link to it as it's been done with "Validity"


Working Group Resolution:
Add a reference to white space definition in 3.12 3.15 and 3.17

----

Your comment on 3.13 NO_FRAMES:
> COMMENT B.21:
> - comment nature: [typo]
> - location: 3.13 NO_FRAMES
> - current wording: "If the document contains a frame, frameset or
> iframe 
> element or object element..."
> - suggested revision: "If the document contains a frame, frameset or 
> iframe element or _an_ object element..."
> - rationale: Apparently there is a missing "an"


Working Group Resolution:
Change GET to POST in this section as indicated

----

Your comment on 3.15 OBJECTS_OR_SCRIPT (partial):
> COMMENT A.5: - ERT WG 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. -
> BPWG RESOLUTION: We think that there are valid uses for allowing # as
> the href, such as a link to the top of the page. - ERT WG RESPONSE:
> 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 ID).


Working Group Resolution:
RESOLUTION: Under LINK_TARGET_FORMAT check for invalid document internal
references and # and warn if present / invalid 

----

Your comment on 3.16 PAGE_SIZE_LIMIT:
> COMMENT B.22:
> - comment nature: [clarification]
> - location: 3.16 PAGE_SIZE_LIMIT
> - current wording: If the size of the document's markup exceeds 10
> kilobytes
> - suggested revision: Does "size of the document's markup" mean "the 
> markup document's length"?
> - rationale: Although this is the most sensible, it could also mean 
> "count only tags" or other things


Working Group Resolution:
Clarify as suggested

----

Your comment on 3.19 PROVIDE_DEFAULTS (partial):
> COMMENT B.24:
> - comment nature: [editorial]
> - location: 3.19 PROVIDE_DEFAULTS
> - current wording: "If there is no nested option element whose selected
> 
> attribute is set to some value, warn"
> - suggested revision: "If there is no nested option element whose 
> selected attribute is set to _"selected"_, warn"
> - rationale: This is the only valid value for this attribute and it's 
> been already included in the next condition of the algorithm


Working Group Resolution:
THanks, that change has been made.

----

Your comment on 3.21 STYLE_SHEETS_USE:
> COMMENT B.25:
> - comment nature: [substantial]
> - location: 3.21 STYLE_SHEETS_USE and 2.3.9 Validity
> - current wording: If the CSS Style contains at-rules (other than the 
> @media at-rule), properties, or values that are not recognized as being
> 
> valid CSS Level 1 (2.3.9 Validity), warn
> ...
> CSS
>      A resource is considered a valid CSS resource if it conforms to
> the 
> grammar defined in [CSS], Appendix B
> - suggested revision: The definition of CSS validity should include in
> 
> some way allowed at-rules, properties and values.
> - rationale: Test 3.4 fails for content that is not valid CSS with 
> validity being defined as conforming to the CSS 1 grammar (syntax).
> Test 3.21 seems to use the phrase "valid CSS 1" in a sense that is not
> 
> just grammar conformance.
> So right now, CSS 2 that conforms to the CSS 1 grammar passes 3.4, but
> 
> you'll get a lot of warnings, because the grammar does not define 
> properties and values (3.21)
> Additionally,
>     @import "foo.css" handheld;
> would fail 3.4 because of the media type, which is not part of the CSS
> 1 
> grammar, while the rule should be considered when collecting the 
> "Included Resources" (2.3.6).


Working Group Resolution:
It's intended that the warnings be generated for non-level 1 . We take
your point on @import and will add text to 2.3.6 and to 3.21 and will
change the wording in 3.21 to avoid the use of "valid" and will also
adjust CSS Validity to take account of the media type on import.

----

Your comment on 3.21 STYLE_SHEETS_USE:
> COMMENT B.26:
> - comment nature: [editorial]
> - location: 3.21 STYLE_SHEETS_USE
> - current wording: If the CSS Style contains at-rules (other than the 
> @media at-rule), properties, or values that are not recognized as being
> 
> valid CSS Level 1 2.3.9 Validity, warn
> - suggested revision: Add () around the link "2.3.9 Validity".
> - rationale:


Working Group Resolution:
THanks that bit has been re-written and removed

----
Received on Monday, 1 October 2007 09:44:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:29 GMT