Closed Bug 950497 Opened 11 years ago Closed 11 years ago

CSS Variables fallback incorrectly implemented (primary cycles)


(Core :: CSS Parsing and Computation, defect)

Not set





(Reporter: fremycompany_pub, Assigned: heycam)




(1 file)

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 []. Would it make sense to reopen that debate?
Blocks: 773296
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.
Ever confirmed: true
Flags: needinfo?(cam)
OS: Windows 8.1 → All
QA Contact: cam
Hardware: x86_64 → All
Version: 29 Branch → Trunk
Attached patch patchSplinter Review
Assignee: nobody → cam
Attachment #8347826 - Flags: review?(dbaron)
QA Contact: cam
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:
(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.
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla29
You need to log in before you can comment on or make changes to this bug.