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

On Tue, Apr 17, 2012 at 6:38 PM, Rik Cabanier <cabanier@gmail.com> wrote:

> 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.
>

Does this (or a draft form) exist anywhere that we can look at?  Can you
describe how it would deal with the test cases posted on this thread so far
(see http://lists.w3.org/Archives/Public/www-style/2012Jan/0582.html and
http://lists.w3.org/Archives/Public/www-style/2012Jan/0816.html for some
examples)?

- James


>
> 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
>>>
>>
>>
>