Re: [css-variables] Last call comments

On Tue, Feb 19, 2013 at 3:02 PM, François REMY
<francois.remy.dev@outlook.com> wrote:
> To the question: can I live with the 'var' prefix and the 'variable' naming, the answer is yes.

Cool.

> To the question: can I live with the impossibility of referencing any property, the answer is yes.

...until/unless we introduce a feature actually designed to do that,
that addresses the problems inherent in this idea.

> To the question: can I live with the fact the var() function doesn't support type converters

...yet.  We can introduce typing to variables or custom properties later.

> To the question: can I live with the fact var() cannot be extended easily to select another scope (ancestor, shadow-dom root...), the anwser is yes.

...yet.  This can be introduced later.

> To the question: can I live with the current inextensible and incoherent syntax, sorry, the anwser is no.

It's not at all inextensible, as I've explained.  I'm sorry you feel
it's incoherent, but I (and several others in the WG) disagree, and
there's not much to be done about that.

> - Why is there no real plan to unify the CSS references syntaxes in the long run? Why don't we at least try to find a common denominator in the way of working of the two so similar things that attr() and var() are?

Because it's not important yet.  Unifying them is low-value and
requires deliberation to get right.  It's probably not appropriate to
introduce at all right now (because of its relatively low value), but
if it is, it definitely needs more baking and implementation interest
before it's put into a spec.

> - Why don't you find alarming that a function number of parameters cannot be changed in the future because of the strange decision of to use the comma both for the argument separator and as a part of the remaining value (and, worse, that the number of arguments is different in the planned attr() and var() functions while they serve the same goal)? My proposal would at least allow to split the parameters in three section (target, options, fallback) instead of just two.

Because we have a long history in CSS of being able to extend things
without needing to employ commas already.  I think it's been
well-established that we're capable of doing this.  We use commas only
to separate lists of parallel items, and sometimes to separate
arguments in functions.

> - Why is a solution that disallow the simple CTRL+F replace of a variable name in a css file prefered to a solution that doesn't?

This has been explained - using the exact same syntax on both setting
and getting has a good chance to lead to confusion, which we can avoid
by making them slightly different.  Fully repeating the name of the
variable, like "var(var-foo)", seems redundant.  As it stands, you can
perform two find-and-replace operations to rename a variable - one for
"var-foo" and and one "var(foo".  If your variable name is chosen
well, you can do it with a single operation, just replacing "foo".

> - Why is the chosen syntax making it impossible to write all property names (or even completely unrelated things you may want to reference to) while there would be no technical difficulties to allow them at the same cascaded time than custom properties (and when it's already possible in some preprocessors).

This has been explained several times - there are substantial
difficulties with allowing arbitrary cycles in CSS properties, because
a lot of CSS properties already rely on each other's values in
particular ways.  There are ways to avoid this, but they have their
own drawbacks.  This requires further thought and implementation
interest before the group is comfortable working on it.

> - Why did the spec evolve so few in the past year albeit all the feedback that the list has received in the mean time? Weak signals aren't immediately actionnable, I can understand that, but in the era of Big Data that no one did take the time to really extract objective arguments out of the subjective proposals out there is making me disturbed.

Because the feedback has been mostly bikeshedding on names and syntax,
and this version of the spec is purposely trying to deliver a simple
version of the functionality, rather than padding out the spec with a
lot more stuff that'll slow it down.  I am very purposely *not*
interested in adding more functionality right now - I wish to save
that to v2.  This has been mentioned before.  (Note that I've got a
list of things that I'd definitely like to add to Variables right now,
but I'm purposely holding them back to help the spec's own progress.)

~TJ

Received on Tuesday, 19 February 2013 23:20:10 UTC