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

| Confusion can persist no more than a few seconds.  ^_^
| Further, we *can not ever* have property names determined by
| variables, without drastically altering the way the cascade is
| resolved.

Because something is technically (and, if you want my opinion, 
fundamentally) flawned doesn't mean people can't think about them. If you 
use a token programming languages use to indicate replacement to introduce 
your set operation, you're taking the risk to face confusion.

Additionnaly, I'm not sure at all how many people know about the ':root' 
pseudo-class. People who are unaware of it will read

    :root {
        $myvar: myvalue;
    }

just like

    @variables {
        $myvar: myvalue;
    }

and will not understand the whole scoping thing.




| 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.




| 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.

However, I would really enjoy using { my-property: value; } in my 
stylesheets.




| There is a good reason to not allow properties to access the values of
| other properties on the same element - properties can potentially
| refer to other properties to define their values, creating an
| *implicit* dependency that's harder to reason about than the explicit
| dependency of a var referring to another var. [...]
|
| However, there's nothing wrong with referencing the inherited value.
| If we come up with decent use-cases, we can always extend parent-var()
| to take an arbitrary property name (rather than just a variable
| property name).

Your point of view looks kinda strange to me this time because you refuse 
something I didn't mean and agree with something I didn't mean but could 
have brought you to my reasoning, both at the same time :-) It's why I like 
so much to discuss with other people; they may have different origins and 
different points of view but, sometimes, they come to the same conclusion, 
and (when it happens) that's truly enjoyable :-D

The whole point of CSS variables is that the replacement happens at 
specified-value time. The whole point of property inheriting is that the 
replacement happens at specified-value time. That's why they are compatible 
with the current way the cascade works.

    .inner, .outer { height: 100px; background: rgba(0,0,0,0.5); }

    .outer { width: 50em; }
    .inner { font-size: 50%; width: inherit; } //width: 50em, not width: 
compute(50em, relatively to outer)

I wouldn't expect $property to use anything else than the specified value, 
just like we do for CSS variables already. It doesn't introduce any other 
complexity to allow that.

    .elem { border-width: calc($width/10); }
    // uses the specified value for 'width', not computed one.
    // fails if 'width: inherit' was specified.

Strong, computation-time links should continue to be handled like they are 
now (css units, prose in properties, ...); this is another, very interesting 
but also completely unrelated debate. I had to resist very hard not to scrap 
everything I just wrote about this and 'forget' to reply to this point.




To return to where we came, could I ask you, Tab, if you would strongly 
reject my proposal if it was going to be proposed in the WG, for exemple? 
Could you write in a single mail the things you don't like about it and why 
you consider them bad design? This is way more productive if people respond 
in one batch with all their thougts about a proposal than if they reply 
paragraph by paragraph. Such discussion almost never converge because a 
partenthese leads to another parenthese, which in return leads to another 
parenthese...

Making a compromise isn't about getting everybody on the same line regarding 
the reasons behind a proposal (because we all have different ways to see the 
things), but rather to get everybody on the same line regarding the final 
result. We'll all have different personnal preferences, and it's clear 
everybody would like something different from my proposal ('just use 
variable name', 'make the $ part of the name' or even 'use @variables').

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.

Received on Tuesday, 5 June 2012 09:45:39 UTC