- From: Bert Bos <bert@w3.org>
- Date: Wed, 14 Mar 2007 15:53:46 +0100
- To: public-bpwg-comments@w3.org
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 14:54:42 UTC