Re: [css-variables] CSS Custom Properties L1

Le 21/06/2012 21:14, François REMY a écrit :
> Ok, got it. However, asking for a diff between two specs whose second one
> has seen a complete rewrite is really challenging. The changes we introduced
> are not breaking the implementation effort already done by the Chrome team
> and we didn't add (m)any new feature either (even if we have proposals).
>
> Here's an attempt to show what's different from an implementer point of view
> in the revised spec:


Thank you François, this helps a lot. (At least for me.) I agree that 
actual specs/drafts/proposals should be the only normative text. I did 
not realize that this proposal was so different from the current draft.


First, I agree with calling this module Custom Properties rather than 
Variables, to mark the distance from preprocessor variables and the 
similarity with other properties (declarations, inheritance, ...)

Other parts of the proposal should be discussed separately. I don’t want 
a change that might have been accepted to be rejected just because it 
was proposed together with other changes that were rejected.


> [[2. DEFINITIONS]]
>
> - 'Custom properties' replace 'variable properties'.
> --- Behavior is still the same.
> --- Introductory keyword changed from 'var' to 'my'.
>
> - Introduced the 'token stream' concept
> --- this maps to the value of a custom property in the [css-variables] case.
> --- open issue: is this concept needed or can we just speak about 'provided
> value'?

I think that such a concept is useful not only here, but also at the 
boundaries between:

* css3-syntax and selectors
* css3-syntax and css3-values (and the value definition of each property)


> - Introduced the 'reference' concept; this replace the 'variable' concept.
> --- 'references' need a 'provider' (something that identifies where/how to
> get the token stream)
> --- 'references' need a token 'stream name' (to identify the referenced
> stream)
> --- 'references' compute a 'provided value' based on provider and stream
> name
> --- 'references' may have a 'fallback value' to be used in case the
> 'provided value' is invalid

The concept of "provider" was unclear to me until I read the two 
examples of '$' and '$parent'. (Even in the actual text, not just in 
this diff!) Maybe another name would be better but I don’t know which, 
sorry.


> --- proposal: when provided, fallback value of a reference has to be valid
> in his place for the declaration to be valid
> --- rationale: different declarations for browser supporting or not a
> feature, not returning to initial value; can be checked at declaration time.

In particular, any token stream is valid for custom property 
declarations. This extends to fallbacks in references in such declarations.

For "normal" properties however, this is not obvious to determine if a 
declaration value is made of more than a single reference. Whether a 
token stream is valid depends on the context. Consider these examples:

border: green solid; /* valid */
border: green red; /* invalid */
border: $(my-color, green) solid; /* valid if the fallback is used */
border: $(my-color, green) $(my-style, solid); /* ??? */

Is there a combinatorial explosion of the number of 
fallback/non-fallback combinations that need to be checked?


> -  Introduced the 'property reference' concept, which explains how to map a
> CSS property to a 'token stream'.
> --- the name of the stream is the actual name of the property (including the
> 'my' prefix).
> --- only custom properties can be referenced [I actually would like to lift
> that restriction; spec should be fine with any property]
> --- properties declared on target element use their specified value, after
> the substitution of references it contained.
> --- properties inherited on target element use computed value of the parent
> property.
> --- properties not inherited on target element use initial value of the
> property.

The next to last point means that computed values (through inheritance) 
can be mixed with specified value components that "still need to be 
computed". In other words, the computed value of any property must be 
compatible/valid as a specified value. This starts to matter if the 
restriction on references is lifted.


> [[3. SYNTAX]]
>
> - Defined the general syntax of a reference:
> --- $provider(stream-name, fallback value)
>
> --- '$' indicates a reference, by convention.
> --- 'provider' is a provider identifier.
> --- 'stream-name' is the name of the referenced stream.
> --- 'fallback value' is optional and represent the fallback value of the
> reference.
>
> - Defined the default provider ($(my-property) syntax)
> --- simple property reference on the current element itself. same as the old
> var(foo, fallback) syntax.
>
> - Defined the 'parent' provider ($parent(my-property) syntax)
> --- simple property reference on the current element's parent-element. same
> as the old parent-var(foo, fallback) syntax.

I don’t know if the "provider" concept is useful at all. $(my-foo) looks 
much less like a function than var(foo) or var(my-foo), so dropping the 
parentheses is very tempting: $my-foo.

Proposal over the proposal:

* Make the parentheses optional when there is no fallback
* Maybe drop providers and hard-code $parent as special function?

I don’t really like either. I find the draft more consistent:
$foo   var($foo, fallback)   parent-var($foo, fallback)


> [[X. PROPOSALS NOT INCLUDED IN THE SPEC]]
>
> - Define the 'declared' (or 'element') provider ($declared(my-property))
> --- same a the default provider, except that the provided value is only
> valid if the property is declared immediately on the element itself
> --- rationale: allow non-inherited-like custom properties.

If being inherited or not is not intrisic to the property, it becomes 
required for UAs to keep around all "cascade values" as well as 
specified values. (Using CSS21:6.1 terminology.) This may have a 
non-trivial memory cost.


> - Define the 'attr' provider
> --- would use the actual value found in an attribute as provided value.
> --- similar to the attr() function, but returns a token stream instead of a
> <string>.
> --- rationale: would allow to explain the behavior of some HTML attributes
> in CSS terms.

So the attribute value would go through the CSS tokenizer? It could have 
comments, backslash-escapes and everything?

Note that there were several proposals for attr(). In the current 
css3-values ED there is an optional <type-or-unit> after <attr-name>.

-- 
Simon Sapin

Received on Thursday, 21 June 2012 19:59:11 UTC