Re: [css-variables] cyclic dependencies involving fallback

On Mon, Dec 16, 2013 at 4:02 PM, François REMY
<francois.remy.dev@outlook.com> wrote:
> ± I think you're right that it does need more work if you ignore the unused
> ± fallback variable references when determining whether a variable is invalid.
> ± Also I'm not sure it's that useful; deliberately including cycles and then relying
> ± on fallback for them to resolve doesn't seem like a pattern that authors will
> ± need.  I think making them all invalid is simpler and is powerful enough.
> ±
> ± (fremy may disagree about whether it's useful to allow it, though:
> ± https://bugzilla.mozilla.org/show_bug.cgi?id=950497#c3.)
>
> Of course I do (I already did back then) but the issues on this group are ruled out by the majority principle ;-)
>
> Still, I don't understand this desire to detect loops early, the backtracking algorithm I propose for value resolution simply makes this unnecessary and has much better fallback semantics. But when I first proposed it, Tab had the same reaction as you: "that looks nice, so why not, but is it really worth the implementation cost?" and decided it wasn't, after all.
>
> I'm pretty sure it does, though, because it has a negligible footprint, but that's just my personal opinion =)

You can't just do simple back-tracking, un-invalidating variables as
you go.  That privileges random custom properties and makes things
rather weird.

Thinking on it more, I don't think it's consistent to try to
batch-uninvalidate a cycle either.  It would mean that a given
variable is resolved to different values in different properties, even
on the same element (fallback within the cycle, resolved outside of
it).

So I'm thinking that cycles of the "var-a: var(b,1); var-b: var(a,
2);" variety should just definitely be invalid.

~TJ

Received on Tuesday, 17 December 2013 01:22:31 UTC