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

Very interesting, François. I've been thinking about something similar, but
I wasn't able to come up with a working algorithm. Am I right in thinking
that this only solves problems where backup values are defined? Or are you
suggesting that
   el {
      my-property-a: no-b;
      my-property-a: get(my-property-b);
      my-property-b: get(my-property-a);
   }
would also resolve to "no-b" for both properties?

Tom

On 21 October 2012 17:58, François REMY <fremycompany_pub@yahoo.fr> wrote:

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