Re: [css3-transitions] Transitions from display:none

Hi James,

I'm not sure about transitions, but Brian, Shane and I are working on an
animation specification that defines amongst other things how animation
will synchronize along with animation event handlers.
This should fix most of the problems that people are trying to fix with
'display: none'. We're also trying to address the issue that the "small
amount of time" introduces.

Rik

On Tue, Apr 17, 2012 at 4:40 PM, James Robinson <jamesr@google.com> wrote:

>
>
> On Tue, Jan 17, 2012 at 11:06 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>
>> On 1/18/12 1:14 AM, James Robinson wrote:
>>
>>> This is problematic if the page is in a background tab, since that turns
>>> off the requestAnimationFrame mechanism.
>>>
>>
>> Why is that a problem?  Do transitions actually start immediately in
>> WebKit in background tabs?  In Gecko they start whenever the style is
>> recomputed, which happens on either flushes or precisely when the
>> requestAnimationFrame timer would fire, fwiw.
>>
>>
>>  it sounds like he's proposing each script assignment to Element.style be
>>> treated atomically and changes resolved against each of those.  That
>>> would be very difficult to implement in WebKit and I believe in gecko as
>>> well because we treat larger blocks as atomic.  Roughly speaking WebKit
>>> treats all changes between style flushes within a given document as
>>> atomic.
>>>
>>
>> Yep.
>>
>>
>>  There's not total consistency here either - WebKit flushes
>>> styles on documents independently of each other, but it seems Gecko
>>> flushes across documents in some cases - compare:
>>> http://webstuff.nfshost.com/**tests/outer.html<http://webstuff.nfshost.com/tests/outer.html>
>>> http://webstuff.nfshost.com/**tests/outer2.html<http://webstuff.nfshost.com/tests/outer2.html>
>>>
>>
>> Yeah, the Gecko behavior here is sort of required if you really want to
>> get meaningful answers out of APIs that return layout data (or even style
>> data: the styles in a subframe depend on media queries, which depend on the
>> size of the CSS viewport, which depends on the layout of the parent
>> document).  What WebKit is doing is sort of racy.  But maybe web pages
>> aren't depending on this in practice.
>>
>> But the larger point that the flushing mechanism is not identical is
>> absolutely true.  I expect there are other differences as well.
>>
>> Need to think a bit about the proposal.
>
>
> Have you had a chance to think about this yet?  This is still a serious
> problem with animations and transitions that authors are hitting.
>
> - James
>
>>
>>
>> -Boris
>>
>
>