- 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