Re: [css-variables] Putting it all toegether (syntax)

(12/06/05 17:45), François REMY wrote:
> | The Core Grammar is not frozen.  We can change it in ways that are
> | compatible with legacy content, just like we can do with every other
> | feature of the entire web platform.
> 
> We can change the grammar if we really need it, sure. Changing it for
> the sake of change isn't however an option.
> 
> Until now, what people wanting to have $foo for setting the property did
> is pointing the workarounds that make that possible. We can break tools,
> we can break old browsers, we can work around them by not doing that.
> What I really want to hear is: why is that so much important to use $
> for setting the variable? what does it bring to the equation? Or,
> alternatively, what's so wrong with a prefixing approach like the one I
> propose that it can't become the voted solution.

I think Tab's point here is that some parts of the Core Grammar should
never be cited as a point against a syntax proposal. In particular, the
substructure of the "declaration" production is irrelevant to the
promise of forwards-compatibility: browsers only find the end of a
declaration by finding ";" or "}". The fact the the Core Grammar
requires the left hand side of ":" to be an IDENT is just a mystery to me.

In other words, this $foo syntax won't break browsers (except the IE6, 7
situation, but that' irrelevant to the Core Grammar) and there's no need
for any workaround. On the other hand, some tools do implement this Core
Grammar, like tinycss[1] (which throws when the input can't be parsed
with the current grammar). I am not sure that's a good idea, and it
means that tinycss is not going to pass the CSS2.1 testsuite as there
are too many test cases there that can't be generated with the current
Core Grammar.

As an example, if CSS variables weren't inheritable, a syntax like

  div { var color = red; color: $color; }

should be a candidate too, albeit not following the Core Grammar but the
forward-compatible parsing rules.

Having said all these, I am strongly against the $foo proposal too for
the sort of confusion it might cause (property replacement).

[1] https://github.com/SimonSapin/tinycss/blob/master/tinycss/css21.py#L763

> | The draft currently uses the "var-" prefix.  I think this is ideal for
> | naming purposes, if we decide not to tweak the Grammar, since they're
> | called "variables".  This also happens to match the nomenclature of JS
> | vars.
> 
> Thanks for citing a good reason not to use 'var' :-) If CSS variables
> are not working like JS variables at all, I see no reason to make the
> confusion between them possible. Anyway, if 'var' was going to be the
> used prefix, I would not be upset about it. That's just not my first
> choice (nor my second one), but I can deal with it easily.

What's your second choice than?

> However, I really did a comprehensive job to work around everyone's
> objections to build a compromise, and if they are sill objections about
> the proposal, I would like to hear them. Regarding the objections about
> the goals we all pursue and the points of view I tried to take in
> consideration, it's clear nobody (even me) can't have a perfect match. I
> don't consider that a reason not to consider a proposal.

I am not sure why you sound as if your summary/proposal isn't welcome.
For what it's worth, I greatly appreciate your summary. Without it, I
probably still think the $foo idea is about property replacement.

I would hope we have a wiki page for all the syntax variations people on
this mailing list have come up, and reasons why some people like/dislike it.


Cheers,
Kenny

Received on Wednesday, 6 June 2012 00:33:48 UTC