- From: Chris Lilley <chris@w3.org>
- Date: Tue, 24 Aug 2010 08:41:45 +0200
- To: fantasai <fantasai.lists@inkedblade.net>
- CC: www-style@w3.org, Bert Bos <bert@w3.org>
On Tuesday, February 23, 2010, 4:29:20 AM, fantasai wrote:
f> On 02/09/2010 03:26 PM, Chris Lilley wrote:
>> 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.
f> It's a note because the sentence above says "is given below in terms of
f> the CSS core grammar". I've clarified that to "terms and conventions".
f> Please let me know if this addresses your comment.
Thank you, the new wording addresses that 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?)
f> I'll leave this question to Bert, who's our resident grammar expert.
I haven't found any response from Bert on this.
>> 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. "
f> Given that it's rather odd to say that the contents of a block delimited
f> by curly braces includes the curly braces *and* given that the statement
f> is qualified by the application of a formal grammar rule that does not
f> include the curly braces, I don't think this clarification is necessary.
This is suboptimal, given that the prose in general overrides the grammars and that the prose uses an undefined term. It is particularly unfortunate, given that there have been discussions in the past as to whether curly braces were allowed (and proposals to extend the syntax, taking advantage of the curly braces).
f> Please let me know if you consider this a problem.
We would prefer that the clarification, which is a minor wording change which improves the clarity, still be added.
>> 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. "
f> This is now filed as CSS2.1 Issue 150, considered editorial.
I see that the edits for issue 150 have been made, and it now says
"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 addresses the comment.
>> 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.
f> IIRC, that paragraph in CSS2.1 was carefully worded so as not to require
f> excluding properties defined by specs beyond CSS2.1. It has two separate
f> sentences:
f> 1. A user agent must ignore a declaration with an invalid property
f> name or an invalid value.
f> 2. Every CSS2.1 property has its own syntactic and semantic restrictions
f> on the values it accepts.
f> The second statement doesn't say anything about non-CSS2.1 properties, it
f> only says something about CSS2.1 properties.
The issue 150 edit now makes a statement about all CSS properties, which is satisfactory.
f> The first statement is not specific to CSS2.1 properties, it is a general
f> statement about property declarations.
f> Let me know if you still consider there to be a problem here in either
f> the Styling Attribute or CSS2.1 specs.
f> I believe it is not the intention
f> of the spec to exclude SVG-defined properties from CSS style sheets, but
f> I don't really see anything for us to do here. Though if anything needs
f> clarification, it would probably be the CSS2.1 spec, not this one.
The style attr module is fine now the above edit to CSS 2.1 has been made. This answers our comment.
>> 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 ...
f> The spec refers to the core grammar in CSS2.1 section 4.1.1, not the
f> grammar in Appendix G.
f> 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.
f> As Zack pointed out, the NUMBER token is defined by the tokenizer rules
f> in the CSS2.1 spec (except he got the section number wrong--since this
f> is the core syntax it is 4.1.1).
I see the production
num [0-9]+|[0-9]*\.[0-9]+
So, unitless values (number) ARE allowed for those properties which allow them. Great. This is needed, given that several SVG-defined properties allow unitless values.
Scientific notation is NOT allowed.
I have been asked by the SVG WG to ask the CSS WG, once again, to allow scientific notation for those properties which allow it. In SVG, currently those properties allow scientific notation in presentation attributes but dissallow it in style sheets (style attributes, style elements, external style sheets). This disparity causes user confusion.
Apologies for the lateness of this reply.
--
Chris Lilley Technical Director, Interaction Domain
W3C Graphics Activity Lead, Fonts Activity Lead
Co-Chair, W3C Hypertext CG
Member, CSS, WebFonts, SVG Working Groups
Received on Tuesday, 24 August 2010 06:40:42 UTC