RE: [css-variables] Last call comments

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

What bother me is that the number of arguments is inconsistent between attr() and var() and that adding new stuff to var() will have an impact on your other responses. If add parameters before the property name, replacing 'var(foo' will not work anymore; if we add parameters after, the parameters should be simple enough not to require commas to separate and that's not necessarily going to be possible (or things are going to be very verbose). For instance, I don't like that specifying type conerters on attr() and var() will have different sytnaxes. It's

Also, sorry, it's ugly to have the comma changing of meaning inside the same parser context (it really makes bottom-up parsers hard to write and it breaks the natural parsing operation that my head is performing on the var() function).


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

This argument doesn't apply to my proposal (in fact, I should stop call that my proposal and just say: return to what Roland Steiner initially proposed at the beginning with its apply function that I and Brian did agree with after a lot of doubts and reflection).


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

Again, this does not apply. What we all ask for is the ability to reference the cascaded/specified value and that value doesn't have any internal dependency: that's exactly the same thing that we are doing with custom properties, by the way.


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

Features-wide, I agree. Syntax-wide, you argument doesn't make any sense. Changing the syntax is not really something that will 'slow down' the spec. Whatever. I'm really under the impression that you justify with 'we want to rush' some bad decisions that will hurt in the future but that match your own personnal taste.

It's not because you plan to delay an important feature to level 2 that you should not think about how to integrate the feature later on in your syntax. When I see that from the Tab's initial draft to the current spec the number of changes is exactly 3 (data->var, variable property->custom property, CSS Variables->Custom Properties for Cascading Variables) and that all are pretty minor, I guess that it means the initial work was just pefect. I'm impressed by so much inner greatness.


Anyway, even if I'm still not satisfied with the responses, if it's the response that the group has to give me, then I'm going to dismiss my objection because it doesn't make sense to try any longer to get what people are just not ready to grant you.

Received on Wednesday, 20 February 2013 10:31:32 UTC