- From: Chris Eppstein <chris@eppsteins.net>
- Date: Tue, 22 May 2012 22:04:24 +0100
- To: "Kang-Hao (Kenny) Lu" <kennyluck@csail.mit.edu>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Bjoern Hoehrmann <derhoermi@gmx.net>, WWW Style <www-style@w3.org>
- Message-ID: <CANyEp6Wq2KnKh9majNE3GeK9G+5xLPp_OUquAuzGQjtaDzkYng@mail.gmail.com>
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