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

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

From: Sean Owen <srowen@google.com>
Date: Wed, 14 Mar 2007 11:17:46 -0400
Message-ID: <e920a71c0703140817w622b0cfcvf0d49f6f586efc61@mail.gmail.com>
To: "Bert Bos" <bert@w3.org>
Cc: public-bpwg-comments@w3.org

Thanks Bert, I added your comments to our list of comments to process
for the last call draft. Yes you are right about the typo for sure.

Sean

On 3/14/07, Bert Bos <bert@w3.org> wrote:
>
> Here are the comments from the CSS WG on
> http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests-20070130/
>
> [The deadline was yesterday, but I forgot to send them before going
> home. Sorry.]
>
>
> section 2.3.4:
>     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?
>
>
> section 3.4:
>     "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.
>
> [2]
> http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410/dtd_module_defs.html#a_module_Style_Sheet
>
>
> For the CSS WG,
> Bert
> --
>   Bert Bos                                ( W 3 C ) http://www.w3.org/
>   http://www.w3.org/people/bos                               W3C/ERCIM
>   bert@w3.org                             2004 Rt des Lucioles / BP 93
>   +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France
>
>
Received on Wednesday, 14 March 2007 15:17:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 15 June 2012 12:13:30 GMT