[css21][css3-syntax] $foo in the core grammar (was: [css-variables] Using $foo as the syntax for variables)

(12/05/22 9:14), Tab Atkins Jr. wrote:
> [snip some theory about whether or not we should change the core grammar]
> 
> We should reject changes that would break non-trivial amounts of
> existing content.  That's the only reasonable restriction that we can
> operate under; anything else would mean that we're promoting
> theoretical purity over improving the language for everyone else.

While I more of less agree with the theory that changing for the better
is a good thing, in this particular case, I disagree with the idea that
putting $foo in the core grammar is actually "improving the language".

In general, the effect of putting a prefixed identifier in the core
grammar is that every time a character is tokenized, the tokenizer has
to check to see if it is one of the prefixes and whether what follows is
an identifier. This would mean that for fallback tokens like DELIM (i.e.
':', '{', '}', ';'), a redundant check to see if it is a '$' is needed.
IMHO, redundant checks are bad because, well, it's the user's computer
that runs this redundant check.

Going back to language consistency.

== prefixed things that *can* have comments in the middle ==
!important
.class
:pseudo

== prefixed things that *can't* have comments in the middle ==
ATKEYWORD
HASH
NUMBER/DIMENSION/PERCENTAGE ('+'/'-')

I wouldn't say the consistency is in favor of one or another, and in
reality, no author but people who play with the specs would try to put
comments in the middle. And, as I said, for performance reasons I would
prefer putting ATKEYWORD and HASH to the former category, if we really
can change this for the better.

(12/05/22 5:30), Tab Atkins Jr. wrote:
> Some further details - to handle $foo in the syntax, we'll either need
> to add a VAR token to the grammar (defined identically to HASH but
> with the $ character instead of #)

Why identical to HASH but not ATKEYWORD? HASH needs {nmchar}+ becuase
<color> needs it. Otherwise, nowhere in CSS allows an identifier to
start with a number, including the ID selector:

  # A CSS ID selector contains a "#" immediately followed by the ID
  # value, which must be an identifier.

(though I think this prose is quite crappy again in that it sounds like
authoring conformance not UA conformance.)

> or accept that variables show up in the tokenizer as a $ DELIM
> followed by an IDENT.  The latter is suboptimal, though - it allows
> comments between the $ and the foo, which sucks,

Can you elaborate on why that sucks? Would anyone ever be confused by
this? It seems like a theoretical concern to me.

> and it means we have to deal with the "first character of
> an IDENT" detail, despite there being no ambiguity (HASH gets to avoid
> all that and just use "nmchar+").

Can you elaborate? What is the "first character of IDENT" detail? What's
wrong by simply saying that $foo is "DELIM followed by an IDENT" (and
add a "without intermediate whitespace" to avoid confusion).

I think HASH is a notorious example. Even if, for example, "#1st" is a
HASH, you still can't use it as a ID selector (tested with WebKit and
Firefox, not sure about others).

(So, please consider this an errata item:

In Appendix G,

change

  # simple_selector
  #  : element_name [ HASH | class | attrib | pseudo ]*
  #  | [ HASH | class | attrib | pseudo ]+
  #  ;

to

  |  /*
  | * There is a constraint on the ID selector that the part after
  | * "#" should match an IDENT; e.g., "#abc" is OK, but "#1st" is not.
  | */
  | simple_selector
  |  : element_name [ HASH | class | attrib | pseudo ]*
  |  | [ HASH | class | attrib | pseudo ]+
  |  ;

like the comment above hexcolor. This should go into selector3 or 4 too.)


Cheers,
Kenny

Received on Tuesday, 22 May 2012 05:04:40 UTC