CSS Variables fallback incorrectly implemented (primary cycles)

RESOLVED FIXED in mozilla29

Status

()

Core
CSS Parsing and Computation
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: François REMY, Assigned: heycam)

Tracking

Trunk
mozilla29
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
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?
Blocks: 773296
Flags: needinfo?(cam)
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.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Flags: needinfo?(cam)
OS: Windows 8.1 → All
QA Contact: cam
Hardware: x86_64 → All
Version: 29 Branch → Trunk
Created attachment 8347826 [details] [diff] [review]
patch
Assignee: nobody → cam
Attachment #8347826 - Flags: review?(dbaron)
QA Contact: cam
(Reporter)

Comment 3

4 years ago
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 on attachment 8347826 [details] [diff] [review]
patch

r=dbaron
Attachment #8347826 - Flags: review?(dbaron) → review+
(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.
https://hg.mozilla.org/integration/mozilla-inbound/rev/574c74c2f035
https://hg.mozilla.org/mozilla-central/rev/574c74c2f035
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla29
You need to log in before you can comment on or make changes to this bug.