RE: [css-variables] Last call comments

> the current syntax does
> not block us from doing things similar to what you want in the future.

Ok, this is where we disagree then. To me, its seems that the current syntax is a blocking factor because it makes many things impossible to generalize and is particularized to access custom properties on the current element while it would be trivial to make it more general without even introducing any feature. 

Making things more general without actually adding any new feature isn't adding any new feature, indeed. The point is: I show there are many desirable features and those are not easy to cover with the particularized syntax currently found in the specification. Instead of keeping on adding new syntax, let's make something that's internally improvable.

I feel so sorry to disagree with you; be sure that if I insist it's really because I think this is important.


> > Concrete proposals:
> > - Replace var(name) by get(var-name)/get(prop var-name) and prop(var-name)
> > to make referencing any property syntaxically possible
>
> Using cascaded values is likely confusing, since most authors have
> little conception of the value stages in the first place, and the
> cascaded value leaves quite a lot of things unresolved.

Saying that authors can't understand that the value that will be used is exactly the value they typed with no transformation applied seems like a clear understimation of the average author to me ;-)

Again, it's exactly what's done by the prepocessors people love to use. Those, by the way, use *real* variables.


> Also, this can be done with a light refactoring using current
> variables. In your example, replace all instances of 'width' with
> 'var-width', then add a "width: var(width);" declaration to the first
> rule. While *slightly* less convenient, this is doable with no new
> features, and no possibility of confusion wrt value stages.

This is not only less convenient, this is a large-scale namespace pollution. If you need to do this with multiple nested items, I promise you'll have a hard time understand what's going on. Why use a hack when you can do the legitimate thing?

I can live with this solution, which is why I propose to delay to Level 2, but I would like to make sure it will eventually be fixed in an elegant way in the future.


> For most people, the concept will be "variables", so that's the naming
> I'm using.

I'm still looking for those 'most people' but I guess neither of us can prove our point here so I'll leave this to the group majority. To me, calling custom properties 'variables' is technically wrong and specs should use technical terms correctly. After that, if some people want to use another name they find more friendly, they're still free to do it.


> Comma is a standard separator for arguments in CSS. We can add more
> stuff into the syntax quite easily by just putting it in the first
> argument. The only other separate we use in CSS is /, which can be
> used if necessary for disambiguation later.

There's at this point no function taking an argument accepting a comma as part of the value either. To particular needs, particular solutions. var(font, Calibri, sans-serif) is quite unclear to my eyes. If there's a way to make things better, why not use it?


> There's no reason to separate the two concepts, since they're
> necessary to get the full value out of variables anyway. The spec has
> several examples which talk about using custom properties solely for
> JS, but if you'd like to write your own tutorials for such, feel free.

Actually, I think I tend to agree with you here, this exercice was more of a way to show how I distinguish the two concepts in my mind, this could potentially help follow my reasoning. It's not strictly needed to split the spec up (our own spec is still in one file, btw).

Received on Saturday, 9 February 2013 18:07:07 UTC