Re: IDs *not* in selectors

On Fri,  9 Jul 1999 14:06:09 +0200 (MET DST), Bert Bos wrote:

>...re: 
> > When HTML has a normative definition for ID and name tokens (1), why
> > would CSS deliberately introduce this conflict with that definition? I'd
> > also posit that UAs decision(s) on whether to 'allow' this might well be
> > divergent, ...

>CSS sometimes allows things that cannot occur in HTML or XML, E.g.,
>"#\20" (an ID selector consisting of a space) is legal in CSS, but
>cannot match anything in HTML or XML. The reason CSS does this is
>because you never know what HTML or XML or their successors may allow
>in the future.

With respect, the utility of CSS in situations where the SGML/XML
formalism is not in force has not been established, either in theory or
in practice. Ergo, only SGML/XML considerations are relevant. SGML/XML
has definitive rules for admissible IDs. There is no evidence that
established and common usage will change.

CSS minimizes the scope for errors and incompatibility by adhering to
the same rules.

Particularly:

Initial digits for identifiers would be a relaxation of the current
constraints. At the point where this would be needed, the change from
the existing SGML/XML requirements would retain backwards compatibility.
Since the *need* for initial digits in IDs has not been demonstrated,
there is no cause to allow something that in the current regime is only
an encouragement/inducement to (validation) error.

Therefore, I propose that the flex-rule:

'#' {name}	{return HASH;}

be modified to read

'#' {ident}	{return HASH}

-- 
Sue Sims
[with appreciation to DQ for the SGML crash course]
-- 
Sue Sims <sue@css.nu>
CSS Pointers Group
<URI:http://css.nu/>

Received on Friday, 9 July 1999 22:19:49 UTC