W3C home > Mailing lists > Public > www-style@w3.org > October 2012

[css-variables] Resolving fallback-enabled cyclical property references

From: François REMY <fremycompany_pub@yahoo.fr>
Date: Sun, 21 Oct 2012 18:58:35 +0200
Message-ID: <A12C147DDD5640A89A3C1A2726A90CF5@FREMYD2>
To: "CSS WG" <www-style@w3.org>
Hi everybody,

Here was my (favorite) technical challenge of the week-end:

    el {
        my-property-a: get(   my-property-b || no-b    );
        my-property-b: get(   my-property-a   );

I would like to get things like this resolve to :

    el {
        my-property-a: no-b;
        my-property-b: no-b;

In the CSS Custom draft, I esquiss an algorithm which is able to solve this 
problem, but this algorithm is not parallelizable. Also, it doesn't handle 
all cases. In particular, it doesn't handle cases where the fallback value 
of a reference does contain another reference (and after some reasearch I 
actually find that useful).

I spent some time this weekend on resolving the issue and here's the 
algorithm I propose :

I propose a backtracking :
    - where we start from the token list of the property
    - where we try to replace each reference by its referenced value
    - when we hit a cyclical reference, we backtrack to the nearest point 
where a fallback value was defined
        - and we replace the reference in question by its fallback value

When we hit a cyclical reference and there's no possible backtrack anymore, 
the property is marked invalid (obviously).

The nice thing about this algorithm is that it's implementable in parallel 
as you don't need to know about the resolved state of any other property to 
continue. Also, it handles really well most cases when an human would find a 
nice way to resolve the fallback-enabled cyclical references.

It's evident that properties can be resolved in any order (otherwhise this 
would not be parallelizable) and that their declaration order do not impact 
the algorithm outcome.

Last but not least, it's easy to track the dependencies of such an algorithm 
since every reference you "touch" in the algorithm is a dependency. There's 
no need to track cross-property dependencies. Tracking dependencies may help 
implementors to optimize the re-evaluation strategy of references if they 
use an observable pattern.

NOTE: You can test the algorithm here:


The input format is a list of property definitions.
- A definition is a list of token.
-- A token is a list of possible replacement values.
--- ref(...) are property references.
--- val(...) are plain tokens.


I would love to get your feedback on this.

Best regards,
Received on Sunday, 21 October 2012 16:58:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:22 UTC