950497 - CSS Variables fallback incorrectly implemented (primary cycles)

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, defect)

Description

[François REMY]

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release)
Build ID: 20131215030202

Steps to reproduce:

Those two cases have incoherent outcomes:
html { background: var(x); }
[1] html { var-x: var(x,red); }
[2] html { var-x: var(y,red); var-y: var(x,red); }


Actual results:

[1] red
[2] transparent


Expected results:

-- according to the CSS Variables spec:
[1] transparent [2] transparent

-- according to my sense of logic:
[1] red [2] red

The backtracking algorithm that would come to this outcome has been described here [http://lists.w3.org/Archives/Public/www-style/2012Oct/0599.html]. Would it make sense to reopen that debate?

Comment 1

[Cameron McCormack (:heycam)]

One thing I overlooked from the spec is that it defines cycles as involving two or more variables.  I think that needs to be changed, so that at least it is clear that

  p { var-a: var(a); }

is invalid due to being a cycle.  I'll mail www-style about that.  As for whether

  html { var-x: var(y, red); var-y: var(x, red); }

should result in valid or invalid values for var-x and var-y, I think there is a stronger case based on the current spec text that these are invalid.  If you attempt to evaluate the variables (lazily detecting cycles), then var-x does "attempt" to use var-y; so I believe it should be treated as a cycle.  Backtracking to find a way to break the cycle complicates things with little benefit, IMO.  (And I think it might require ordering the variables, which currently isn't needed.)

Your overall point that [1] and [2] should behave the same is correct.

Comment 2

[Cameron McCormack (:heycam)]

Attachment: patch

Comment 3

[François REMY]

Solving the inconsistency is great, thanks. That being said, I'm still interested in solving properly the fallback issue.

I'm not arguing for a proper fallback mechanism for the sake of completion, there are valid reasons you may want a cycle: you know that two variables should be equal by default, but there are some rare cases where you want to be able to dissociate them:

* {
  var-a: var(b,red);
  var-b: var(a,red);
}

.x {  var-a: blue;  }
.y {  var-b: lime;  }

// * is red red, .x is blue blue, .y is lime lime, .x.y is blue lime

Also, my backtracking proposal does not require to order variables, because I wanted the algorithm to be parallelizable, and does not even need to detect cycles at all. Seriously, have a look at this cool visual tool: http://fremycompany.com/temp/2012-10/ReferenceResolver/algo-resolve-references.html

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 8347826 [details] [diff] [review]
patch

r=dbaron

Comment 5

[Cameron McCormack (:heycam)]

(In reply to François REMY from comment #3)
> Solving the inconsistency is great, thanks. That being said, I'm still
> interested in solving properly the fallback issue.

For that I think the www-style thread is a better place.

Comment 6

[Cameron McCormack (:heycam)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/574c74c2f035

Comment 7

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/574c74c2f035