[css-variables] Summary of Open Issues

Given the progress made by the Chrome team on the [css-variables] implementation, I think it becomes critical to make sure the community feedback about the specification has been handled properly by the CSS WG before the “unprefixed implementation” lock-down.

Because I understand that reading blog posts and alternative specifications is not something the WG members have time to do, I summed up the community feedback as a set of open issues that I would like to be discussed sometime in the future. Please note that issue numbers refer to the issue numbering in the latest CSS Custom Properties draft. 


--------------------------------------------------------------------------------

ISSUE 4: Referencing all properties

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


--------------------------------------------------------------------------------
ISSUE 1: Custom Properties using ‘var’ as prefix?

Most of us don’t understand why, when ‘Variables properties’ were renamed into ‘Custom properties’ in the spec, the spec itself wasn’t renamed ‘CSS Custom Properties’ like our proposal is.

Also, we contest the ‘var’ prefix being used. If ‘custom properties are not variables’, using the ‘var’ keyword doesn’t make sense anymore. 
The name of CSS Custom Properties specification has been chosen on purpose. Since this spec aims to differentiate itself from macro-like functionality of preprocessed variables, it doesn't make sense for it to be called CSS Variables. In fact, it doesn't define any variable at all, only properties and property references.

This specification uses the 'my' prefix for custom properties on purpose for custom properties for three main reasons:

  1.. It's the prefix that developers used naturally, for years, when they were using or asking custom properties. If necessary, I can find a lot of samples of that. 
  2.. It does clearly explain the status of the property: the property is yours, you can use it for anything you would like to and the browser won't mess up with your code. 
  3.. Meanwhile, it's a very short prefix that's not cumbersome to type. 
Beside this, this specification also ban the 'var' and 'parent-var' functional notations and replace them with the more informative 'use()' and 'inherit()' functions. It’s interesting to note that ‘color: inherit(color)’ has the same behavior as ‘color: inherit’ in our proposal.


--------------------------------------------------------------------------------

ISSUE 2: Targeting features using variable

My next concern is about the lost ability to target browser features-support with variables. Since variables are resolved at computation time, it’s not possible at this time to provide ‘fallback values’ in the case a property doesn’t recognize the value stored in a valid custom property.

The proposal I made to solve this issue is a static checking at the parse time that would reject declarations containing property references whose fallback value isn’t recognized by the browser :

.selector {
   background: use(my-bg-color);
   background: use(my-super-cool-bg, unsupported-feature(...));
}

The second declaration of the 'background' property will probably be discarded by the user agent because it doesn't understand the 'unsupported-feature()' function. In this case, the background will use the 'my-bg-color' custom property value. The specification covers more complete rules for this that handles more complex cases.


--------------------------------------------------------------------------------

ISSUE 3: Resolving cyclical references in a better way

At this time, inadvertant cyclical references in CSS will result to poor results because it marks every custom property invalid, having for consequence the invalidation of many other CSS properties at computation time, which mean the ‘initial’ value of the property will be used instead.

A better way to handle cyclical references is proposed in the current CSS Custom Properties draft which takes in account the fallback value of the broken references to ‘fix’ the issue.


--------------------------------------------------------------------------------

ISSUE 5: Non-inherited custom properties

There have been many request for non-inherited custom properties. However, it’s impossible to specify them in the file in a good way, which makes them impossible.

My proposed solution (don’t necessarily assume Brian and Chris support on this) would be a ‘use-declared()’ function that only takes in consideration the specified value of the referenced property if it was explicitely defined on the element (so, not if it’s initial state or inherited).


--------------------------------------------------------------------------------


I suppose it would have been better to split this mail in 5 (one for each issue) but this would seems to be a message flood which explains why I prefered not to do alike.

Best regards,
François