Re: [css3-animations] display:none, visibility:hidden and animations

On Sun, Oct 2, 2011 at 10:04 AM, L. David Baron <dbaron@dbaron.org> wrote:
> On Sunday 2011-10-02 09:24 -0700, Tab Atkins Jr. wrote:
>> I'm somewhat confused, probably due to lacking some crucial bit of
>> knowledge.  You still have to do full selector matching and cascading
>> on display:none elements in order to tell when they shouldn't be
>> display:none anymore, right?  What optimizations surround this that
>> make starting animations so hard?
>
> Yes, but you don't have to do any selector matching and cascading on
> their descendants.  This means, from a CSS perspective, that the
> performance characteristics of a display:none *subtree* are pretty
> much like that subtree weren't there (since it's only the cost of a
> single element).  Authors do rely on those performance
> characteristics.

Ah, yes, that's what I was missing.  I was only thinking of the
display:none element itself, not its subtree.  Thanks!

Hmm, that's more subtle then.  I *would* still like animations to run
on display:none subtrees - the fact that we optimize subtrees away
here seems like it could surprise authors at times, because it's
detectable now.

However, I'm much more concerned about animations on display:none
elements.  The justification for subtrees is understandable, but
stopping or pausing animations on display:none elements themselves is
just wrong.  There's no efficiency justification for it, and it'll
definitely be surprising when we gain the ability to animate
'display'.


On Sun, Oct 2, 2011 at 10:54 AM, Brad Kemper <brad.kemper@gmail.com> wrote:
> On Oct 2, 2011, at 12:48 AM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
>> I expect to be able to animate an element to/from display:none, once
>> Transitions is fixed to allow animating all properties.
>
> What did you have in mind for that? Treating 'display: none' as if it was roughly equivalent to 'width:0; height:0; box-sizing: border-box'? And how would you transition between any two of the other display values?

No, of course not.  'display' takes keywords.  They transition in a
discrete manner, suddenly switching from one value to the next.  You
can control when that transition happens with the existing timing
functions and keyframes.  I expect that when we gain the ability to
transition all properties, anything without an explicitly defined
transition behavior will act like this.


On Mon, Oct 3, 2011 at 8:52 AM, Sylvain Galineau <sylvaing@microsoft.com> wrote:
> 1. Given an animation A currently running on E, what is the effect on A of giving E
> display:none ?
> 2. Given an element E with display:none, what is the effect of applying an animation
> A to E ? What happens when E is given non-none display after A is applied ? Specifically,
> when the element is given a visible display less t seconds of the animation being applied,
> with t being the animation's duration ?
> 3. Given an animation A currently running on a descendent of E, what is the effect on A of
> giving E display:none ?
> 4. Given an element E with display:none, what is the effect of applying an animation
> A to a descendant of E ? What happens when E is given non-none display after A is applied?
> Specifically, when the element is given a visible display less than t seconds of the animation
> being applied, with t being the animation's duration ?
>
> Does that make sense ? And am I missing other interesting cases ?

Those are all the cases.  I feel quite strongly that for #1 and #2
there should be no special effect - the animation should apply and run
as normal.

I'd prefer the same for #3 and #4, but I'd grudgingly accept the
answer being "animations are removed when E becomes display:none, and
are started from the beginning when E is change to non-none".  If we
went down this route, I'd prefer the "properties don't cascade into
display:none subtrees" to be defined generally as part of CSS, rather
than a random weird quirk of the 'animation' property.  If we bow to
the optimization here, we should do it everywhere.  (I don't think
there's anything else currently that would depend on that, but there
may be in the future.)

~TJ

Received on Monday, 3 October 2011 17:32:01 UTC