This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
""" Since this specification does not define when computed values change, and thus what changes to computed values are considered simultaneous, authors should be aware that changing any of the transition properties a small amount of time after making a change that might transition can result in behavior that varies between implementations, since the changes might be considered simultaneous in some implementations but not others. """ http://dev.w3.org/csswg/css3-transitions/#starting I understand that we don't want to spec this precisely, but can we at least place some constraints? It's not possible to test transitions if browsers are allowed to say that changes after setTimeout(..., 10000) are considered simultaneous by their implementation. :) Basic test script: data:text/html,<!doctype html> <body> <script> var div = document.createElement("div"); div.textContent = "The quick brown fox jumped over the lazy dog"; div.style.transition = "5s color"; document.body.appendChild(div); div.style.color = "green"; </script> Tested browsers: IE10 Developer Preview, mozilla-central build from 2012-02-17, Chrome 18 dev, Opera Next 12.00 alpha. * No transition in any browser for the basic test. * Adding "getComputedStyle(div);" before the last line: still no transition in any browser tested. * Adding "getComputedStyle(div).color;" before the last line: IE still does not transition. Other browsers transition. * Adding "</script><script>" before the last line: no transition in any browser tested. * Wrapping the last line with "setTimeout(function(){" ... "}, 0)": transition in every browser tested. * Wrapping the last line with "onload = function(){" ... "}": IE does not transition. Other browsers transition. Can we at least require that if you make a change, then a setTimeout() function makes another change, they can't be simultaneous? There should be at least one way for authors to change styles and know it's not simultaneous.
(In reply to comment #0) > Can we at least require that if you make a change, then a setTimeout() function > makes another change, they can't be simultaneous? There should be at least one > way for authors to change styles and know it's not simultaneous. I think that's too strong -- it prevents implementations from coalescing changes that happen within the same screen refresh, for example. I think if we wanted to say something we'd want to say something about the previous style having been visible to the user.
Then there's no guarantee at all, because maybe the browser cleverly failed to update the rendering because it's in a background tab. We need some type of guarantee if we're going to test this, right?
Here's a test-case where browsers aren't compatible: data:text/html,<!doctype html> <p style="transition: 4s -1s"></p> <script> var p = document.querySelector("p"); setTimeout(function() { p.style.marginLeft = "100px"; p.textContent = getComputedStyle(p).marginLeft }, 100); </script> In IE10 Developer Preview, Chrome 18 dev, and Opera Next 12.00 alpha, this outputs "0px" and animates nicely. (You have to change marginLeft to textIndent in both places for it to work in Opera.) In Firefox 13.0a1, it outputs "40.85px". So Firefox is considering the transition to start right away, and others start it a little later. If I do data:text/html,<!doctype html> <p style="transition: 4s -1s"></p> <script> var p = document.querySelector("p"); setTimeout(function() { p.style.marginLeft = "100px"; }, 0); setTimeout(function() { p.textContent = getComputedStyle(p).marginLeft }, 2); </script> then in Chrome it outputs "40px", but if I change the second timeout from 2 to 1 it's "0px" again. In IE, the second timeout has to be around 50 for it to display a nonzero value consistently, but it will sometimes be nonzero as low as 10. In Opera the cutoff is around 40. Is this something we can realistically specify, or do we have to leave it undefined? Gecko's behavior makes the most sense to me.
I placed some constraints in https://hg.csswg.org/drafts/rev/e24fe4941c41 ; I'm not comfortable adding more constraints at this point.