Re: IDs *not* in selectors

Sue Sims wrote:

> Perhaps someone could explain what I am missing in trying to reconcile
> this statement from Bert Bos, earlier in this thread:
>
> >Since CSS1 allowed digits, I think we should change the text in 4.1.3
> >to match the grammar (i.e., digits are allowed), rather than
> >vice-versa.
>
> with this comment from the CSS1 grammar (1):
>
> /* There is a constraint on the id and solitary_id that the
>    ** part after the "#" must be a valid HTML ID value;
>    ** e.g., "#x77" is OK, but "#77" is not.  */

You are correct, CSS1 didn't intend to allow digits at the beginning of IDs.

However, that constraint didn't survive into CSS2.

>
>
> Just as I think I almost get close to sort of understanding that,
> initially at least, the intent of CSS1 was _not_ to allow initial
> digits, an apparently conflicting assertion is made by the author of the
> recommendation. It seems to me that the comment above reinforces the
> text (2):
>
> "in CSS1, selectors (element names, classes and IDs) can contain only
> the characters A-Z, 0-9, and Unicode characters 161-255, plus dash (-);
> they cannot start with a dash or a digit;..."
>
> In short: I cannot find the specific part of the CSS1 recommendation
> which allows digits as the initial character in class names/IDs . Please
> give the reference for the statement, preferably with a direct quote
> from the text of the CSS1 recommednation rather than a reference to the
> CSS1 grammar.
>
> As to Peter's comment:
>
> "Amusingly enough, that would break parsing of colors, eg:
> { color: #123456; }"
>
> It seems to me that this comment, from the CSS2 grammar (3):
>
> "/*
>        * 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.
>        */"
>
> is intended to address that concern, analogously to the way the first
> comment I quoted from CSS1 is meant to address this 'digit as initial
> character' concern.

My point is that you proposed changing the tokenization rules. With your
change in place, my color example would contain an invalid token and would
be rejected before it could be evaluated as a possible valid color.
If hash tokens are used anywhere with leading digits, then they must be
allowed in the tokenization. It is perfectly reasonable to have higher level
rules that reject certain values of tokens in certain contexts (as color
does). The rule which filtered out invalid IDs appears to have been dropped
in CSS2.

Also, back to the big picture, allowing CSS to consider an ID selector
beginning with a digit as legal grammar does not require it to *match* the
selector. It merely states that the rule should not be rejected as invalid.

Consider:
H1, H2#1id { color: blue; }

In CSS1, the entire rule would be rejected due to the invalid ID selector.
H1s would not become blue.
In CSS2, the rule is valid and would then apply to all H1s. It would not be
expected to apply to an H2 with the ID="1id" if the document didn't also
consider "1id" to be a legal ID value.

This simply takes the decision about what constitutes a legal ID value out
of the hands of CSS and puts it squarely in the hands of the document's
specification. Which is where it belongs.

>
>
> Though I'm always glad to provide amusement, that is not the purpose of
> any of the posts I've made on this topic.

My amusement was not directed at you, but at some of the inherent conflicts
within CSS. When in doubt, please do me the courtesy of presuming that what
I say is meant in a courteous, professional manner. If I ever feel the need
for a personal attack, you can rely on me to be both more blatant and more
private.

>
>
> (1) http://www.w3.org/TR/REC-CSS1#appendix-b
> (2) http://www.w3.org/TR/REC-CSS1#forward-compatible-parsing
> (3) http://www.w3.org/TR/REC-CSS2/grammar.html#q1

Received on Monday, 12 July 1999 13:49:35 UTC