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

Re: [mobileOK-basic10-tests] CSS WG comments

From: <mike@w3.org>
Date: Mon, 04 Jun 2007 14:14:03 +0000
To: Bert Bos <bert@w3.org>
Cc: public-bpwg-comments@w3.org
Message-Id: <E1HvDJr-0006Ll-HP@wiggum.w3.org>


 Dear Bert Bos ,

The Mobile Web Best Practice Working Group has reviewed the comments you
sent [1] on the Last Call Working Draft [2] of the W3C mobileOK Basic
Tests 1.0 published on 30 Jan 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-20070525/

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

 1. http://www.w3.org/mid/200703141553.47013.bert@w3.org
 2. http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests-20070130/


=====

Your comment on 2.3.4 CSS Style:
> The "not" in "style elements whose type attribute is not
>     "text/css"" is erroneous since the type attribute on the style
>     element is REQUIRED as per [2]. Maybe just a typo?


Working Group Resolution:
Thanks this was a typo

----

Your comment on 3.4 CONTENT_FORMAT_SUPPORT:
> "If the Internet media type is "text/css" and the content is not
>     well-formed CSS (contains mismatching brackets or illegal
>     characters), FAIL" should probably be rewritten, because CSS
> doesn't
>     define the term "well-formed."
> 
>     But it is not immediately clear what it should be rewritten as.
> The
>     CSS spec is written to (1) allow future extensions and (2) to make
>     the meaning well-defined for as large a set of inputs as possible.
> A
>     visual UA will ignore the (legal) 'cue' property the same way it
>     ignores the (misspelled) 'magrin' property. There is no need for
> CSS
>     to say that one is legal and the other an error.
> 
>     Illegal characters and unparsable input are explicitly undefined
> in
>     CSS, so there is no doubt that those must not be "mobileOK." On
> the
>     other hand, the handling of unbalanced parentheses *is*
>     well-defined. Informally, the wording suggests that unbalanced
>     parentheses are worse errors than unknown properties, but in the
>     spec they are handled the same way, viz., with rules to throw away
>     parsed tokens.
> 
>     Maybe: "If [...] content triggers at least one CSS parsing error
> as
>     defined in the CSS specification, FAIL."
> 
>     CSS 2.1 has a section 4.2 called "parsing errors," but there are
>     errors defined in other sections, too. CSS 2.1 section 4.2 has
> this:
> 
>       - Unknown properties
>       - Illegal values
>       - Malformed declarations
>       - Invalid at-keywords (*)
>       - Unexpected end of style sheet
>       - Unexpected end of string
>       - (by reference to 4.1.7:) Invalid selector
> 
>     (* already separated out in MobileOK section 3.22)
> 
>     Other errors are defined in section 4.1:
> 
>       - Input that cannot be tokenized or parsed (section 4.1.1)
>       - Vendor-specific extensions (4.1.2.1)
>       - U+0 character (4.1.3)
>       - Non-Unicode characters (4.1.3)
> 
>     For example, a style sheet that consists of just this
> 
>         ;;;
> 
>     cannot be parsed.


Working Group Resolution:
Yes, and adopt text: "If the Internet media type is "text/css" and the
content is not  CSS that conforms to the grammar specified in Appendix B
(http://www.w3.org/TR/REC-CSS1#appendix-b) of CSS Level 1 FAIL" - note
also that we intend to clarify what we mean by Valid in general

----
Received on Monday, 4 June 2007 14:14:05 UTC

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