Re: [css-variables] TLDR: get free hugs by reading this message entirely

My own take for whatever it is worth:

- fix the name, we appear to have wide agreement on that
- once you change the name var doesn't make as much sense
- the general pattern in keeping with css left/right values where the left
value is a fn seems like a winner from all I have seen.

If we get that far, I will be happy enough :)
 On Aug 16, 2012 2:03 PM, "François REMY" <fremycompany_pub@yahoo.fr> wrote:

>   Hi everybody,
>
> I suppose most of you heard about the CSS WG decision to *
> **rule out the $foo syntax from the [css-variables] specification*.
> If not, then now you have :-) As an initial opponent of the $foo
> syntax, I can’t really say I’m unhappy of this decision, whose
> catalysts includes :
>
>     - Difficulty to use $ on both sides of the declaration because
> it *breaks existing CSS tools* (and syntax) and was proven confusing.
>
>     - *Confusion between “templating macros” (aka Preprocessor
> Variables) and “custom properties” (aka CSS Variables)*, which
> includes traditional CSS Properties exclusives like cascading,
> inheritance and element-local scope (which mean they are not
> ‘stylesheet-local’ or ‘rule-local’ like preproc variables).
>
>     - As such, a *necessity to reserve the $ token for future, more
> macro-like microsyntaxes* (selectors variables, mixins, extensions...)
> which will please the “preprocessor” people a lot more than the
> current proposal, which should never have been called “variables”
> by the way.
>
> However, I’m not really satisfied either with the current state of the
> [css-variables] draft, which was rolled back to the initial “var-“ and
> “var()” syntax. I’m not going to repeat here the whole discussions
> that lead us to here, since interested people can use the archives
> to discover it in more details.
>
> *What I would like to point out is that the “var-“ and “var()”
> syntax triggered a lot of constructive comments* and that ruling
> them out with such a rollback is not the way we’re going to make
> any progress on the matter. I’m certainly under the impression that
> we need to look for facts and not for opinions to make this whole
> specification progress.
>
> Really, few people tried to *collect previous usage* of custom
> properties like I did [1]. Brian and I crafted real-life examples for
> our spec [2] and demonstrated custom properties possibilities,
> something that the working group failed to achieve until now.
>
> For a use-case driven working group, this is not what I’m going
> to call a success.
>
> [1]
> http://fremycompany.com/BG/2012/My-research-about-css-custom-ndash-CSSWG-882/
> [2] http://fremycompany.com/TR/2012/ED-css-custom/#sample-global
>
> As the community couldn’t read in your minds, the community
> didn’t understand the [css-variables] thing; and it’s not as if I
> did not warn about it in the past [3].
>
>  <http://fremycompany.com/TR/2012/ED-css-custom/#sample-global>
> [3] http://lists.w3.org/Archives/Public/www-style/2012May/1027.html
>
> Maybe it’s time to take real-life data in consideration in the
> decisions the WG make about [css-variables]. I heard clearly and
> I agree with the current decision to rule out the $foo syntax. That’s
> fine. I’m happy with it. Now, let’s talk about what to do of the
> [css-variables] spec.
>
> *Firstly*, for the sake of -----, rename that spec. Everybody [4] seems
> to agree that “Variables” is problematic and that “Custom Properties”
> would be way better. Let’s just go for it. Why does it take so much
> time to rename a specification?
>
> [4] https://twitter.com/glazou/status/235813031605575681
> [4] https://twitter.com/chriseppstein/status/236116588439416832
> [4] http://www.xanthir.com/b4KT0#4KT0-4
> [4] http://fremycompany.com/BG/2012/Explaining-CSS-Custom-Properties/
> [4] ...
>
> *Secondly*, the community is in demand of being able to target any
> property in the future using references, and not only custom
> properties. [5] *parent.font-size is huge.*
>
> [5] https://twitter.com/chriseppstein/status/236116588439416832
> [5] In fact the CSS Custom Properties was made with that in mind
>
> Oh! I heard you swear! [image: Rire]
>
> Meanwhile, I continue to say that, yes, it’s possible. We want to target
> the specified value and this value doesn’t depend on any other property’s
> value, just on what is written in the CSS file (all details in my previous
> mail [6]). That way, I can target “background-color” and use it for my
> “outline-color”. This is huge.
>
> [6] http://lists.w3.org/Archives/Public/www-style/2012Jun/0277.html
>
> *Thirdly*, we need a decent syntax. Seriously, I did take the time to
> write
> down all the “requirements” of a good CSS Custom Properties syntax.
> At the time, I just tried to make sense. The current var- and var() syntax
> just does *NOT* make sense, in the big picture.
>
> *Alternatives do exist. Here are a few :*
>
>     - *Go with the current CSS Custom Properties draft:*
>
>         .x { my-property: value }
>         .x .y { color: $(my-property) }
>
>
>     - *Go with the {} island proposal :*
>
>         .x { my-property: value }
>         .x .y { color: {my-property} }
>
>
>     - *Go with the OO proposal :*
>
>         .x { my-property: value }
>         .x .y { color: self.my-property }
>
>
> Those alternatives are easily extensible to “parent-var” and “fallbacks” :
>
>      - *Go with the current CSS Custom Properties draft:*
>
>          .x .y {
>             my-property-bak: $parent(my-property, fallback);
>             my-proprety: $parent(my-property-bak, fallback);
>         }
>
>
>      - *Go with the {} island proposal :*
>
>          .x .y {
>             my-property-bak: { parent.my-property | fallback };
>             my-proprety: { parent.my-property-bak | fallback };
>         }
>
>
>      - *Go with the OO proposal :*
>
>          .x .y {
>             my-property-bak: firstOf(parent.my-property, fallback);
>             my-proprety: firstOf(parent.my-property-bak, fallback);
>         }
>
>
> *The decision to rollback the $foo syntax must not come with a
> decision not to consider any new option*, certainly given the fact
> that alternatives that were not using the “$” symbol were declared
> “out” at some point, and no announcement has been made before
> the f2f that this restriction was going to be lifted (nor was it even
> hinted).
>
> We certainly need more reflection. I’m not sure we have the best
> solution in hand now. But I’m sure the current one is certainly not
> the best one of those we have.
>
> Kind regards,
> François
>
> ------------------------------
> *And here are the*
> [image: image]
> [image: Clignement d'œil]
>