- From: François REMY <fremycompany_pub@yahoo.fr>
- Date: Sun, 21 Oct 2012 18:58:35 +0200
- 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: ======================================= http://fremycompany.com/temp/2012-10/ReferenceResolver/algo-resolve-references.html 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, François
Received on Sunday, 21 October 2012 16:58:45 UTC