- From: Chris Lilley <chris@w3.org>
- Date: Wed, 10 Feb 2010 00:26:42 +0100
- To: www-style@w3.org
Hello www-style, These comments relate to CSS Styling Attributes Level 1, W3C Working Draft 21 January 2010 from the perspective of SVG. 1) Thank you for citing SVG 1.1 as one of the specifications which allows inline style attributes. 2) In section 3. Syntax and Parsing, the text "Note that following the CSS2.1 convention, comment tokens are not shown in the rule above." is given as an informative note, but appears to be normative. It states, in effect, that the normative grammar given is incomplete. Pleas emake this statement normative. 3) In section 3. Syntax and Parsing, the actual grammar for a style attribute, following CSS2.1 chapter 4, appears to be declaration-list : C* S* C* declaration? C* [ ';' C* S* C* declaration? C*]* C* ; where C is the comment production. Is that correct? (Specifically, are leading and trailing comments allowed, as well as ones between tokens?) 4) However, in In section 3. Syntax and Parsing, "The value of the styling attribute must match the syntax of the contents of a CSS declaration block" appears at first sight to contradict CSS 2.1 4.1.7 Rule sets, declaration blocks, and selectors, which states "A declaration block starts with a left curly brace ({) and ends with the matching right curly brace (}). In between there must be a list of zero or more semicolon-separated (;) declarations. " The contents could be argued to include the curly braces, therefore. This might be made clearer either by adding wording to css-style-attr as follows: "The value of the styling attribute must match the syntax of the contents of a CSS declaration block, i.e excluding the leading and trailing '{' and '}' tokens" or by adding wording to CSS 2.1 to define the term 'declaration block contents' as follows "A declaration block starts with a left curly brace ({) and ends with the matching right curly brace (}). In between are the declaration block contents, which must be a list of zero or more semicolon-separated (;) declarations. " 5) In section 3. Syntax and Parsing, once the fix in comment 4 is allpied, its good for clarity that the specification clearly disallows the '{' and '}' tokens. It does man that scoped style attributes (with a selector before the '{') are disallowed. We assume that this is intentional. 6) In section 3. Syntax and Parsing, the text "The interpreter must parse the styling attribute's value using the same forward-compatible parsing rules that apply to parsing declaration block contents in a normal CSS style sheet. See chapter 4 of the CSS2.1 specification for details. [CSS21]" defers to CSS 2.1. CSS 2.1 in turn defines, in section 4.1.8 only the CSS 2.1 properties (naturally, for itself; but an issue, when referenced by other specifications): "A user agent must ignore a declaration with an invalid property name or an invalid value. Every CSS 2.1 property has its own syntactic and semantic restrictions on the values it accepts. " As a consequence, this specification appears to exclude CSS3 properties, for example, from appearing in style attributes; if they occur they must be ignored. Please confirm that this exclusion is intentional. If it is not intentional, please explain how CSS3 properties and property values may appear in a style attribute and what governs their syntax. This problem might be avoided by altering CSS2.1 to say "A user agent must ignore a declaration with an invalid property name or an invalid value. Every CSS property has its own syntactic and semantic restrictions on the values it accepts. " 7) Following the same argument as point 6, this specification appears to exclude SVG properties from appearing in style attributes. If intentional, this is unacceptable to the SVG WG and appears to contradict the mention of SVG 1.1 in the Abstract. If unintentional, please explain how SVG properties and property values may appear in a style attribute and what governs their syntax. 8) Assuming that comments 6 and 7 are resolved such that CSS3 and SVG properties and property values are allowed in style attributes and are not required to be ignored, then the relevant productions would appear to be declaration : property ':' S* expr prio? ; property : IDENT S* ; prio : IMPORTANT_SYM S* ; expr : term [ operator? term ]* ; term : unary_operator? [ NUMBER S* | PERCENTAGE S* | LENGTH S* | EMS S* | EXS S* | ANGLE S* | TIME S* | FREQ S* ] | STRING S* | IDENT S* | URI S* | hexcolor | function ; function : FUNCTION S* expr ')' S* ; /* * There is a constraint on the color that it must * have either 3 or 6 hex-digits (i.e., [0-9a-fA-F]) * after the "#"; e.g., "#000" is OK, but "#abcd" is not. */ hexcolor : HASH S* ; This appears to allow unitless values ('number'), for those properties defined to accept them, and scientific notation, for those properties defined to accept it. However, that depends on the exact syntax of the NUMBER token, which is apparently defined in a printed book. [FLEX] "Flex: The Lexical Scanner Generator", Version 2.3.7, ISBN 1882114213. The flex sourceforge page appears to suggest how NUMBER is interpreted - C99 decimal constant | C99 hexadecimal constant | C99 octal constant | C99 floating point constant http://flex.sourceforge.net/manual/Numbers.html#Numbers Please confirm that this is the case. 9) In section 4. Cascading and Interpretation Good clear section. We agree that multiple CSS styling attributes on a single element would be a poor idea. -- Chris Lilley mailto:chris@w3.org Technical Director, Interaction Domain W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG
Received on Tuesday, 9 February 2010 23:26:50 UTC