- From: James Robinson <jamesr@google.com>
- Date: Tue, 17 Apr 2012 19:23:51 -0700
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Sylvain Galineau <sylvaing@microsoft.com>, "www-style@w3.org" <www-style@w3.org>
- Message-ID: <CAD73mdLLSe+nb64Y8nNcvyKRHXWbr9A75B5+x3kOu8LVSpuncw@mail.gmail.com>
On Tue, Apr 17, 2012 at 6:42 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > I don't think my proposal is nearly that heavyweight. >> > > OK, it's possible that I'm mixing up the various proposals. > > > Here it is again, >> see http://lists.w3.org/Archives/**Public/www-style/2012Jan/0816.**html<http://lists.w3.org/Archives/Public/www-style/2012Jan/0816.html>for >> the fuller context: >> > > OK. This seems somewhat reasonable, yes. The task basically needs to > save off the before/after change values (the ones that led to the browser > noticing a change in the first place). > More specifically when queueing the task the browser has to store the "before" computed value of the animatable/transitionable property and then keep that around until the task runs. > > One issue here is that the transition start would be async, so either > there will be a lag between style change and start or the start event will > fire at time != 0 in the transition. Maybe that's OK; it's not like timing > of transition starts is so precise anyway. I think there's always going to be a lag between the style change and the start simply by the nature of the fact that doing something like "e.classList.append('foo')" doesn't synchronously flush styles to figure out if there is supposed to be a transition or not. > > > Concretely with this proposal in Sylvain's example the transition would >> not occur in either of the scenarios he mentions: >> >> e.style.color = "blue"; >> e.style.display = "block"; >> > > Why would there be no transition in this case? As a reminder, the initial state here is: E { display:none; color:red; transition: color 0.25s; } and I'm assuming that after each statement the browser may or may not resolve styles. Regardless of when that happens, at some point the browser queues a task. When the task runs it evaluates that the computed value for "color" is "blue" and was previously not specified, since there was no CSS box. Thus, no transition. A similar argument applies for an initial state of display:block; color: blue and the JS e.style.color = "red"; e.style.display = "none"; when the task runs the element has no CSS box, so no transition. > > > e.style.display = "block"; >> e.style.color = "blue"; >> > > Or in this one? The same as above (the order of assignment doesn't matter since the event loop does not spin. - James > > > or in this slightly trickier one: >> >> e.style.color = "blue"; >> document.body.offsetTop; // forces a style flush, at least in WebKit >> e.style.display = "none"; >> > > This one is explicitly covered by your proposal, yes. > > -Boris >
Received on Wednesday, 18 April 2012 02:24:21 UTC