Re: [css-style-attr] SVG WG comments on CSS Styling Attributes Level 1

On 02/09/2010 03:26 PM, Chris Lilley wrote:
> 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.

I'm glad the SVG WG approves of being cited. :)

> 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. Please make
> this statement normative.

It's a note because the sentence above says "is given below in terms of
the CSS core grammar". I've clarified that to "terms and conventions".
Please let me know if this addresses your comment.

> 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?)

I'll leave this question to Bert, who's our resident grammar expert.

> 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. "

Given that it's rather odd to say that the contents of a block delimited
by curly braces includes the curly braces *and* given that the statement
is qualified by the application of a formal grammar rule that does not
include the curly braces, I don't think this clarification is necessary.

Please let me know if you consider this a problem.

> 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.

Yes. The intention of this draft is only to codify existing features,
not to define new ones.

> 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. "

This is now filed as CSS2.1 Issue 150, considered editorial.

> 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.

IIRC, that paragraph in CSS2.1 was carefully worded so as not to require
excluding properties defined by specs beyond CSS2.1. It has two separate
sentences:
   1. A user agent must ignore a declaration with an invalid property
      name or an invalid value.
   2. Every CSS2.1 property has its own syntactic and semantic restrictions
      on the values it accepts.

The second statement doesn't say anything about non-CSS2.1 properties, it
only says something about CSS2.1 properties.
The first statement is not specific to CSS2.1 properties, it is a general
statement about property declarations.

[Personally, I consider SVGWG-defined properties to be part of CSS. If
this were not the case, they wouldn't be able to share the same style
sheet and we wouldn't be looking at the kind of overlap in applicability
that we're seeing with SVG and CSS properties applied to SVG and non-SVG
content. Historically, there hasn't been much collaboration between the
SVG and CSS WGs wrt the properties they are both emitting into the
property space, but I think the existence or lack of collaboration is
a separate issue from whether the properties both occupy the same space.
Can't speak for the WG, but that's my perspective on this.]

Let me know if you still consider there to be a problem here in either
the Styling Attribute or CSS2.1 specs. I believe it is not the intention
of the spec to exclude SVG-defined properties from CSS style sheets, but
I don't really see anything for us to do here. Though if anything needs
clarification, it would probably be the CSS2.1 spec, not this one.

> 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 ...

The spec refers to the core grammar in CSS2.1 section 4.1.1, not the
grammar in Appendix G.
   http://www.w3.org/TR/CSS21/syndata.html#tokenization

> 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.
> ...
> Please confirm that this is the case.

As Zack pointed out, the NUMBER token is defined by the tokenizer rules
in the CSS2.1 spec (except he got the section number wrong--since this
is the core syntax it is 4.1.1).

> 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.

I'm glad you agree. :)

~fantasai

Received on Tuesday, 23 February 2010 02:30:03 UTC