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

For what it's worth, in Sass variables are $ + IDENT, so $2 is not a valid
variable.

Chris

On Tue, May 22, 2012 at 6:03 AM, Kang-Hao (Kenny) Lu <
kennyluck@csail.mit.edu> wrote:

> (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 21:05:16 UTC