[css-variables] Referencing all properties (Issue 4, !important)

Historically, one of the first ‘property references’ introduced in CSS has been the ‘em’ unit and the ‘currentColor’ keywords. Those are not references to some custom, author-defined properties but native properties of the browser. Chris, Brian and myself strongly argue that all properties should be referencable.

While we understand that should probably be delayed to Level 2, we do not want a syntax to be chosen that makes this impossible or cumbersome to add. The current syntax var-xxx and var(xxx) makes it imposible to target the ‘background-color’ property for use in ‘outline-color’ because ‘var(background-color)’ targets ‘var-background-color’. Our proposal differentiates use(my-background-color) and use(background-color) very easily.

There are also other advantages to this approach: the IDENTIFIER used to ‘name’ the property is the same whatever the context you are in (in the current proposal, it’s ‘var-x’ when you define it, but only ‘x’ when you actully use it, which makes renaming variables using a text editor more cumbersome than it should be).

Tab’s response to this has been that “we need the ‘used value’” for that feature to be useful (and not the specified value), which seems untrue to me. For exemple, having an ‘outline-color’ identical to the ‘background-color’ seems a good use case, as well as using ‘width’-relative’s ‘padding-left’ and ‘padding-right’, so that you can update the ‘width’ property and have the ‘padding-left’ and ‘padding-right’ automatically default to 5% of the specified width (whether you used %, px or em to define it). 

Certainly, not everything would work, but I think that this is still better than the ‘nothing can work’ that the current Tab’s position implies.

To be complete, another Tab’s argument on the matter has been that ‘native property references’ don’t require a fallback mechanism because they always exists, which is ignoring the fact that a property may exist in a browser but not in another, and that we still need to define fallback for those cases. If we need to specify fallback, specifying it in another way than for custom properties would not make much sense (or, at least, I was not presented a case where it would).