RE: [css-variables] Last call comments

> - François thinks the proposed (in spec) syntax is bad and harmful
> to the future of CSS. He proposes another syntax that could allow
> harmonization between CSS Variables and existing functional
> notations in CSS.

This looks like a good summary, indeed.


> 2. Some of the use cases contained in the original message [1] seem
> to me out of scope, namely the one contained in section 2.

I would like to stress that this is what the original author of the current CSS Variables proposal intended, and that he reacted quite quickly to say he did disagree with the fact not all properties could be read? Even the author of SASS, the first 'CSS Variables' implementer if you want my opinion, also disagree with this decision. I don't want this in Level 1 but I'm sure a lot of people, my self included, will continue to want this in the future. The best thing I've ever heard is 'people will get confused because they don't knwo that the cascaded value is' and, honestly, I've very hard time thinking people could be unable to understand that the value they get is exactly the value they wrote in the stylesheet, especially when it's exactly what's going on with custom properties.


> 3. I don't see and don't understand why implementation of var() calls
> prevent us from having something similar to François's get() in
> the future. The explanations about compile-time vs. runtime seems
> to be based on wrong implementation assumptions and going nowhere.

There's a small misunderstanding here. The compile-time vs runtime discussion has nothing to do with my proposed syntax, it's about the fact var(...) was called a 'variable'. Among the points of disagreement I have with the current spec, the naming isn't really the most important one. I'm okay putting that aside.


> My question is (and this is a yes or no
> question): can you live with it or do you plan to maintain your
> objection?

To the question: can I live with the 'var' prefix and the 'variable' naming, the answer is yes.
To the question: can I live with the impossibility of referencing any property, the answer is yes.
To the question: can I live with the fact the var() function doesn't support type converters 
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.
To the question: can I live with the current inextensible and incoherent syntax, sorry, the anwser is no.

I don't plan to delay the [css-variables] standardization but be sure I'm going to make the best use of all the time I still have to get my points through. So, technically, I'm still keeping my objection or however you will call it.

The very first thing I need to get all that sorted out is to understand what is actually going on. As long as I'm under the impression that objective arguments get dismissed in favor of some people's preference, I won't be satisfied. As a result, I promise I'm going to retract my objection within a week as soon as I get a clear reponse to the following questions in a cironcianted and objective document that the group did agree on:


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

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

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

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

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


I'm not asking to agree with the anwsers the group did resolve, I'm just asking to understand why making any change to this spec is so difficult even with much personnal investement, reflection, compromises and arguments... while on the other hand some specs were updated for much less important reasons, at a time where compatibility issues where much more problematic. 

If there's something I'm missing, that's what I want to know; and I'm sure what I may be missing is covered (at least partially) by those questions.

Anyway, if there's no strong volounty to answer the questions, or that there's simply no answer, I make the second promise to retract any objection within 6 weeks if I don't get any response, to make sure the specification isn't taken in hostage of our discussion. Given the importance of CSS Variables, I do think 6 weeks is a good timespan.


Kind regards,
François

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