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

It is not quite ready for consumption yet.
I glanced at your pointers and they are about the condition that triggers
transitions. This is not something we've discussed.

Rik

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

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