Re: [css-variables] Last call comments

On Sat, Feb 9, 2013 at 11:06 AM, François REMY
<francois.remy.dev@outlook.com> wrote:
>> 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.

Nope, we can totally still generalize in the future.  The var()
function being specialized for referencing custom properties doesn't
block any later generalization any more than attr() or counter() does
today.  In fact, it's better, because it doesn't take up any generic
name with a too-early attempt at a generalization, before we've had
the chance to examine the idea in real depth.

In the future, we can still do something like "get(var foo)" and
"get(attr foo)" or whatever.  Trying too hard to generalize it right
now, particularly before we actually add any features that benefit
from the generalization, is almost certainly a mistake.

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

Which preprocessors do this?  Sass doesn't have this ability, for instance.

And dude, there's no such thing as "real" variables.  Sass's variables
have lexical scope according to their nesting level.  CSS's variables
have dynamic DOM scope.  Both are useful instantiations of the
"variables" concept.

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

This is what SASS does.  (Their vars are nesting-scoped, so they can
avoid polluting the rest of the stylesheet, but when we add local
vars, it'll be similar.)

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

That's not what I'm calling them.  Go look at the spec.  They are
called "custom properties".

Custom properties define variables, which are referenced by var().

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

Incorrect - attr() uses the same syntax.  Given that they're
instantiations of very similar concepts, this makes sense.

~TJ

Received on Saturday, 9 February 2013 18:44:06 UTC