[css-variables] Last call comments

Hi all,


I’m pleased to see [css-variables] making seemingly good progress and I’m taking the Last Call period as an opportunity to make a summary of the comments I believe still remain to be properly addressed by the group.

 

 

 

1] Absence of CSS Reference concept

While the concept of reference has been present for a while in my own fork of the spec, I guess it wasn’t really understood by lack of the explicit use-cases I was trying to solve. Let’s try to fix that. The problem I’m trying to solve is the interaction between different reference types. Consider the following case:


    a[href] {

        my-href: attr(href); // resolved when used

    }

    

    a > div.tooltip::before { 

        content: get(my-href); 

    }


This won’t work as the attr() reference won’t be resolved on the anchor but on the div, which lacks any href attribute. The problem is that the attribute and the property references don’t interact properly. This is why I want to define a broader syntax that will give references much more expressive power over time. 


   a[href] {

        my-href: get(attr href); // resolved when computed

   }


   a > div.tooltip::before {

        content: get(my-href);

   }

 

The second important thing about reference is that it make sure we can use attribute references as a fallback for property references and vice-versa by creating an abstraction level behind all kind of references, and creating a framework for other kinds of referencable content (counters, document properties, string-sets, ...).

 

For example, the next level of CSS References could include new features like choosing the context in which a reference is resolved, and making that change allow to use it for any of the already-defined reference types: get(parent attr data-abc), get(shadow-host attr data-mode), ...


Concrete proposals:

- Refactor the reference resolution algorithm into a reusable wording for other references types to come (divide CSS Variables into CSS References + CSS Custom Properties).

 

- Remove the attr() function from CSS Value and Units (that section will keep the spec from going to CR, so I guess it’s a good idea anyway) and move it to the CSS References spec (and define there both the resolution-time-replaced get(attr ...) and the used-value-time-replaced attr(...)).

 

- Define both an used-value-time replaced prop(my-...) and a resolution-time-replaced get(prop my-...) in the CSS Property References specification.

 

- Delay the other features Brian & I proposed to CSS References L2.

 

 

 

2] Inextensibility to all properties

I don’t see any reason why we could not reference the cascaded value of any property inside another, and not just custom properties as it’s now. 

 

(Please note I’m not speaking about computed or used value here, because those values aren’t accessible at computation time anyway). Here’s a concrete use-case currently solved neither by CSS Variables in preprocessors nor by [css-variables] as it’s defined now:


    .box {

        width: 100px;

        min-height: get(width / 3);

    }


    .large {

         width: 200px;

    }


    .very.large {

         width: 300px;

    }


The limitation of cascade-time property values is that you can’t use values that depends on the context (like %age in some cases, or auto) but as an author I believe you can understand this (and this is how variables work in preprocessors anway!). 


The benefits in term of expressiveness are huge. Using a custom property in that case would be a waste (think about namespace pollution if you have multiple boxes nested, you nead a lot of rules to clean the state at each level and prevent leaks).


Concrete proposals:

- Replace var(name) by get(var-name)/get(prop var-name) and prop(var-name) to make referencing any property syntaxically possible and delay to CSS Custom Properties L2 the ability to actually reference non-custom properties at cascaded-value time (to make sure the L1 goes CR as soon as possible), for L1 specify that referencing a non-custom property is invalid at computation time.

 

 

 

3] ‘Variables’ naming

I’m not sure it’s still worth mentioning but I’m against the Variables wording. The initial spec evolved completely after Roland Steiner proposal for custom properties and the old naming was conserved even if, actually, the content of the spec changed completely. 

 

I’ve a few slides explaining the difference I see between Variables and Properties and why they’ll coexist, it’s faster to read than a whole text explaining it all.


http://sdrv.ms/10Ws9dB


 

I’m fine with the latest name proposed by Daniel, but I still would like to get rid of the ‘var’ prefix and the ‘variables’ denomination of the spec; the second one being replaced by ‘references’ as explained previously. 

 

For the prefix: choose anything, but not var. Proposals include ‘data’, ‘x’, ‘my’, ‘cst’, ‘ext’ and ‘author’. If needed, I’m okay to prepare a small pro/con for each of those proposals and their origin.

 

I’m not considering this as yet-another-last-call-rename because no widespread implementation is currently in use or largely documented and the renaming proposal holds for a long time, this is not a last-minute change of mind. I think it’s worth considering if we want to avoid people to misunderstand the concept.

 


Concrete proposals:

- Get rid of ‘var’ as a custom property prefix.

 

 

 

4] Default value syntax and comma-overloading

I’m also dropping a note on the currently envisioned syntax for default values in CSS References. My draft is using || as a separator instead or , because it’s much more readable and it allows to append more new arguments (like type converters) to the get()/var() function.

 

    get(my-property | 3 | px);

    var(property, 3, px) // ‘, px’ is parsed as part of the default value not as a third argument

 

    get(my-font || font1,font2,sans-serif); 

    var(font, font1,font2,sans-serif); // confusing

 



Concrete proposals:

- Get rid of ‘,’ as an argument separator in get()/var(), use “||” or “;”

 

 

 

I hope to get those issues discussed at some point, and I’m at your disposal if some more explanations are needed at any point. 

 

Brian & I long-term vision for CSS Custom Properties and References is still largely covered by our fork of the spec. http://fremycompany.com/TR/2012/ED-css-custom/


 

Have a nice day,

François


__________________

PS: By the way, I propose a split-up in two specs of the current one (CSS Custom Properties (custom props & object model for javascript use) + CSS References (using custom props inside CSS, attribute references, ...) and I would not bother the first one to be CR-ized indecently of the second one because JavaScript usages of CSS Custom Properties exist independently of a way to reuse them in CSS.