W3C home > Mailing lists > Public > www-style@w3.org > July 2005

[CSS21] Chapter 4: Syntax - comments

From: Christian Roth <roth@visualclick.de>
Date: Wed, 13 Jul 2005 23:29:05 +0200
To: "www-style Mailing List" <www-style@w3.org>
Message-Id: <20050713212905.652@mail.visualclick.de>

Follow my comments on CSS 2.1 Last Call, Chapter 4: Syntax.

Generally a nice and welcome improvement over the preceding version of
this chapter.


Use of terms: "version" vs. "level" vs. "revision"

For me, the use of terms "version" and "level" is confusing, especially
since "version" is not defined in the specification. Is "version" to mean

Missing: List of special CSS characters

The specification refers to "special CSS characters" that e.g. need
escaping. I haven't found a list of these special characters. Have these
to be inferred from parsing context and the core grammar?
<http://www.w3.org/TR/CSS21/syndata.html#q6> (third bullet)

Missing: Resolving escapes

Though probably not absolutely required, it would be helpful to have it
explained that character escapes in tokens must be resolved before
performing any (mostly: comparison-) operation, so that i.e. an
identifier written as "te\st" is considered the same as if it had been
written as "test". This would complement the already existing note that
pre-processors must not resolve quotes.
<http://www.w3.org/TR/CSS21/syndata.html#q6> (third bullet)

Use of terms: "ISO 10646" vs. "Unicode"

In most places in chapter 4, ISO 10646 is referenced for character set.
However, in two places the term "Unicode" is used (4.3.7 and 4.4.1). For
consistency reasons, ISO 10646 should be used in those two places instead.

Inconsistent spelling

Throughout chapter 4, spelling of the following terms is changes randomly:

       style sheet  <-->  stylesheet
            CSS2.1  <-->  CSS 2.1
 declaration block  <--> declaration-block

I suggest picking one and sticking with it.

Concern: starting identifiers with hyphens

I have voiced my concerns and objection to allowing identifiers to start
with an unquoted hyphen vehemently in the past and will leave it
therefore at it.


All levels of CSS -- level 1, level 2, and any future levels -- use the
same core syntax. This allows UAs to parse (though not completely
understand) style sheets written in levels of CSS that didn't exist at
the time the UAs were created.
The list of tokens for CSS 2.1 is as follows.
]]] - <http://www.w3.org/TR/CSS21/syndata.html#tokenization>

If all levels of CSS use this *same* core syntax, then why is it only the
list of tokens for *CSS 2.1* and not all versions of CSS? Remove the
reference to CSS 2.1 in the second sentence.

Appendix G describes a more restrictive grammar that is closer to the CSS
level 2 language.
]]] - <http://www.w3.org/TR/CSS21/syndata.html#tokenization>

I have three issues with the wording of this sentence:

(1) The reader is aware that he is reading the description for the core
syntax. This reference has potential making him wonder whether what he
reads is something normative or is not "the real" grammar he has to observe.

(2) When Appendix G describes a more restrictive grammar that is closer
to CSS level 2 language (or isn't it CSS 2.1 ?), but still not CSS level
2, then why bother to specify it at all? Just describe the constructs in
detail and unambigously in the description of the various parts (sections
4.1.2 ff.) - which you have done already - and don't bother to give a
grammar at all. Why? Giving this grammar may lead implementors into
believing they can use that grammar as-is for their implementation, when
in fact they can't due to the many restrictions and error handling
requirements which are not implementable by throwing the grammar at a
scanner/parser generator. They might waste their time in doing this, just
to find out some time later that a generated parser using the
normative(!) grammar will not be easily forced into being a conforming
parser, and that they would have been way better off in implementing the
spec as described verbally (they'd have probably written a recursive
descent parser manually right from the beginning, thereby having saved
several hours of work.)

(3) <nit-picking> Finally, when you want to give a grammar that is
"closer to the CSS level 2 language", just how close is it? As far as it
gets? As far as you managed? Why didn't you specify some more grammars
that are "reasonably close", "a little closer" and "way close" as well?

Suggestion: Remove this reference to Appendix G completely.

The meaning of input that cannot be tokenized or parsed is undefined in
CSS 2.1.
]]] - <http://www.w3.org/TR/CSS21/syndata.html#tokenization>

I suggest removing the reference to CSS 2.1 here. This is the section on
core grammar valid for all levels of CSS: there should not be a reference
to the current level. When you need to apply restrictions to the core
grammar, make it a specific section, "CSS 2.1 Grammar restrictions". This
way, when there are several levels of CSS available to be implemented,
readers of the spec have a chance to easily compare restrictions between
levels they need to implement without having to browse through the
otherwise identical descriptions of the core grammar, which - due to its
nature - should never change in the future.

Suggestion of sectioning:
- 4.1 CSS Core grammar: consists essentially of current 4.1.1 with
references to CSS 2.1 removed.
- 4.2 Grammar of CSS 2.1: consists of 4.2.1 with restrictions to the core
grammar now in 4.1.1, and continues with 4.1.2, ... relabelled to 4.2.2, ...

Of course, it would even be better to separate general constructs'
descriptions which will not change (e.g. "Statement", "At-rule", ...)
into the core grammar description, and then add restrictions for CSS 2.1
in the CSS 2.1 grammar's section. It makes it much easier for
implementors to decide on factorings and identifying features to be put
into the parser core and which should go into configurable CSS profile

Keywords have the form of identifiers.
]]] - <http://www.w3.org/TR/CSS21/syndata.html#keywords>

The term "identifiers" is nowhere clearly visibly defined in the
specification, though a link later in the document suggests that this
should be the second item in the list in 4.1.3. Please add a link here
since it is a forward reference to the definition.

Keywords and property names,...
]]] - <http://www.w3.org/TR/CSS21/syndata.html#q4>

The term "property names" is a *forward* reference to its definition in
4.1.8 (although there, only *property* is actually defined, but not
*property name*). Suggesting to make it link to that section.

In CSS2.1, identifiers may begin with '-' (dash) or '_' (underscore).
]]] - <http://www.w3.org/TR/CSS21/syndata.html#q4>

According to the core grammar, identifiers (assuming this being IDENT
tokens) may start with these characters in *all* versions and levels of
CSS, not just CSS 2.1 . I guess you mean to say that it is in the
*keywords* and *property names* that CSS 2.1 allows them for use as
vendor-specific extensions designators, but nowhere else. 

An initial dash or underscore is guaranteed never to be used in a
property or keyword...
]]] - <http://www.w3.org/TR/CSS21/syndata.html#q4>

Is "property" a synonym for "property name", or are these two different
things? If it is the same (and it seems to be when reading 4.1.8), why is
there the term "property name" used earlier in Looks like it
should be "property" only.

...consists of a list of statements (see the grammar above).
]]] - <http://www.w3.org/TR/CSS21/syndata.html#q7>

Suggestion: Remove "(see the grammar above)" and link "statements" to the
respective line in the core grammar.

In this specification, the expressions "immediately before" or
"immediately after" mean with no intervening whitespace or comments.
]]] - <http://www.w3.org/TR/CSS21/syndata.html#q7>

This definition is rather buried, especially since it is not at 4.1-
level, but can be construed to be part of 4.1.4-level. Move this up to
4.1, Syntax, introduction.

...after any valid rule other than an @charset or an @import rule.
]]] - <http://www.w3.org/TR/CSS21/syndata.html#at-rules>

Inconsistent usage of the term "rule" (first occurrence in sentence
above): Later in 4.1.7, "rule" is defined to be a synonym for "rule set".
Neither @charset nor @import are a rule set, however; they're at-rules.
So the first occurrence of "rule" in the above should be changed to

...to achieve the effect of only importing a style sheet for 'print' media,
use the @import with media syntax...
]]] - <http://www.w3.org/TR/CSS21/syndata.html#at-rules>

Should probably be: "...use the @import rule with media syntax..." ("rule" added).

In between there may be any characters...
]]] - <http://www.w3.org/TR/CSS21/syndata.html#block>

Shouldn't this better read: "In between there may be any tokens..."? If
not, what's the rationale behind using "characters"? Changing to "tokens"
in the above would also mean you could drop "Single (') and double quotes
(")  must also occur in matching pairs, and characters between them are
parsed as a string. See Tokenization above for the definition of a
string." completely. Honestly, I do not understand why this description
is falling back onto character level when there is a generally valid
tokenization definition given already that is also universally valid for
every style sheet.

...followed by a declaration block. A declaration-block...
]]] - <http://www.w3.org/TR/CSS21/syndata.html#q10>

Use consistent hyphenation for declaration block (i.e., none).

...also called a {}-block in the following text...
]]] - <http://www.w3.org/TR/CSS21/syndata.html#q10>

I think it's unfortunate to use that abbreviation. When reading aloud,
one always must remember how to pronounce "{}-block": Is it "braces-
block"...? Or what was it again...? Well, it's a "declaration block", so
why not keep using that as written? Same goes with the rule set
abbreviation: Why introduce it? It makes communication more fragile
between different people when there is a synonym to remember for each
basic concept.

Because of the way selectors work, multiple declarations for the same
selector may be organized into semicolon (;) separated groups.
]]] - <http://www.w3.org/TR/CSS21/syndata.html#declaration>

I think when turning around the above sentence, it is more precise:

"A semicolon (;) separated list of declarations in the declaration block
for a specific selector may be used as a shorthand for multiple single-
declaration rule sets with the same selector in the same order.

Thus, the following rule

h1 {
  font-weight: bold;
  font-size: 12px;
  line-height: 14px;
  font-family: Helvetica;
  font-variant: normal;
  font-style: normal

is equivalent to

h1 { font-weight: bold }
h1 { font-size: 12px }
h1 { line-height: 14px }
h1 { font-family: Helvetica }
h1 { font-variant: normal }
h1 { font-style: normal }"

A property is an identifier. Any character may occur in the value. ...
]]] - <http://www.w3.org/TR/CSS21/syndata.html#declaration>

For better readability and clear separation of descriptions' subjects,
make this into two paragraphs as follows:

"A property is an identifier.

Any character may occur in a property's value. ..."

Again, I do not understand why you fall back onto character level
description here when a universal tokenization is available (see above).

...but in any case, values are built from identifiers, strings, numbers,
lengths, percentages, URIs, and colors.
]]] - <http://www.w3.org/TR/CSS21/syndata.html#declaration>

This is incorrect as it is written. Even the preceding paragraph says
that "any character may occur in the value".

An example: The value

  counters(item, ".")

additionally contains the comma (',', a DELIM) and parentheses.
Suggestion is to drop the above part of the sentence completely, as it
does not convey any essential information at that point.

A user agent must ignore a declaration with an invalid property name..."
  and later
The CSS 2.1 parser will ignore these declarations...
]]] - <http://www.w3.org/TR/CSS21/syndata.html#declaration>

It's unclear whether the *parser* must ignore the declarations or the
*user agent* must ignore it. This becomes important when using SAC:
Should the property be reported or not? Again, due to the structuring of
this chapter 4, it is extremely hard to separate the required behaviour
of a general CSS parser from the required behaviour of a CSS parser that
has been configured to use the CSS 2.1 profile.

A user agent must ignore a declaration with an invalid property name...
]]] - <http://www.w3.org/TR/CSS21/syndata.html#declaration>

What's the definition of "invalid name" here? Invalid per the CSS 2.1
profile? In this case, it should probably better read "illegal property
name in CSS 2.1", as "illegal" is a well-defined term in the specification.

Or is it meant to be invalid per the definition for the "identifier" type
(e.g. as in { 123: 12pt })?

Also, how does the term "invalid" here relate to the term "unknown" in
4.2, "Unknown properties"?

"Illegal values.", third example:
img { background: "red" } /* keywords cannot be quoted */
]]] - <http://www.w3.org/TR/CSS21/syndata.html#parsing-errors>

The correct explanation for why this is an *illegal value* is: 
"/* property does not accept a string value */"

Example: Unexpected end of style sheet
@media screen {
    p:before { content: 'Hello'; }
]]] - <http://www.w3.org/TR/CSS21/syndata.html#parsing-errors>

Though the example is correct in its result, it is confusing: It looks
like the user agent (btw.: why not the *parser*?) is supposed to add a
semicolon and an empty declaration after closing the open string. I
suggest changing the reference style sheet to

@media screen {
    p:before { content: 'Hello'}}

to better hint at what the parser should virtually append at the end of
the style sheet.

...in a conformant UA.
]]] - <http://www.w3.org/TR/CSS21/syndata.html#parsing-errors>

As far as I know, there is no such english word "conformant" (but then,
I'm German...); use "conforming" instead. Note that you use "conforming"
already in 4.3.6.

Unexpected end of style sheet." and "Unexpected end of string.
]]] - <http://www.w3.org/TR/CSS21/syndata.html#parsing-errors>

Is there anywhere a rationale given for these two amendments in CSS 2.1?
At first sight, it looks like it might encourage sloppy style sheet authoring.

Some characters appearing in an unquoted URI, such as parentheses,
commas, whitespace characters, single quotes (') and double quotes ("),
must be escaped with a backslash: '\(', '\)', '\,'.
]]] - <http://www.w3.org/TR/CSS21/syndata.html#uri>

Is this meant to be the comprehensive list of characters that need
quoting? Then it should be made clear.

If it is not a comprehensive list, there should be a hint as to where to
deduct the characters needing quoting from, i.e. the token definition for
URI. Suggested wording:

"All characters appearing in an unquoted URI must be quoted so that the
resulting URI value matches an URI token."

I also do not see the requirement for restricting quoting to using the
backslash - it will just complicate parser implementations to enforce
this requirement, which is not even necessary according to the core grammar.

In CSS2, the values of counters can only be referred to from the
'content' property.
]]] - <http://www.w3.org/TR/CSS21/syndata.html#counter>

What about CSS *2.1*, the specification at hand? Does it hold the same

To refer to the value of a counter, the notation 'counter(<identifier>)'
or 'counter(<identifier>, <list-style-type>)' is used.
]]] - <http://www.w3.org/TR/CSS21/syndata.html#counter>

In contrast to the wording in 4.3.4 or 4.3.6, there is no indication that
any optional whitespace is allowed in the counter(...)/counters(...) syntax.
Is it intended that exactly one space character must follow each comma,
and no further whitespace is allowed within the parentheses? If this is
not the case, please add appropriate text.

The list of keyword color names is:...
]]] - <http://www.w3.org/TR/CSS21/syndata.html#color-units>

Maybe change to: "The list of color name keywords is: ..." or even just
"The list of color keywords is: ...". Especially, since the next paragraph
starts calling them "color keywords", anyway.

Conforming user agents...
]]] - <http://www.w3.org/TR/CSS21/syndata.html#color-units>

This text is not a link to the conformance section, whereas the later one
in 4.4.1 is. Either link both places or link only the first occurrence in
document order (i.e. this one).

Regards, Christian.
Received on Wednesday, 13 July 2005 21:29:23 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:19 UTC