Re: [css-variables] CSS Custom Properties L1

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:



[[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'?

- 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

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

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



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



[[4. CSSOM]]

- Introduced the CSSTokenStreamReference interface (reworked 
CSSVariableInstance)
--- provider as DOMString
--- streamName as DOMString
--- fallbackValue as any
--- providedValue as readonly any

- Renamed 'style.vars.color' in 'style.my.color' in the issue note.



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

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

- Define the 'host' provider
--- similar to the 'parent' provider, but would target the host of the 
current Shadow DOMTree, if any.
--- rationale: usage expected in conjunction with HTML components; could be 
included in the Shadow DOM spec.




I hope this does solve the 'diff' problem a little bit, and that I didn't 
miss anything. However, nothing can replace reading a specification & his 
reasons, in my opinion.

François

Received on Thursday, 21 June 2012 19:15:25 UTC