Re: [css-transition] :animating state pseudo-class & display property

I do have working implementation of this so can prove that this is working
in principle.

In fact algorithm is pretty straightforward. When styles need to be
recalculated algorithm is like this:

1) Apply/calculate styles as usual.
2) If there is no change of transition/animation properties then we are
done, exit. Otherwise:
3) transition/animation needs to be started/stoped, set :animation state
accordingly.
4) reapply/recalculate styles again ignoring any change
of transition/animation properties.
5) do start/stop of transition/animation using styles calculated on step 4.

-- 
Andrew Fedoniouk.

http://terrainformatica.com


On Fri, Mar 30, 2012 at 2:51 PM, François REMY <fremycompany_pub@yahoo.fr>wrote:

>   The real problem is that the rule matching phase occurs before the
> style computation phase. Consider the following CSS code :
>
>     a { color: black; transition: all 0.2s; }
>     a:hover { color: blue; }
>     a:animating { ... }
>
> In the browser, the matching phase occurs at a time where the only
> available information is :
>
>     a { ... }
>     a:hover { ... }
>     a:animating { ... }
>
> It’s impossible to determine with that information if :animating is
> matching or not.
>
> With :hover (which faces a similar problem), a small trick has been used:
> each time the layout is recomputed, the previous location of the element on
> the screen is used to find out if :hover matches or not. But with your
> sample it wouldn’t work because the first time the element would be
> redrawn, it wouldn’t have the “overflow-y” applied (because it previously
> didn’t have :hover matching and therefore no transition applied), causing a
> visible glith on the screen.
>
> However, isn’t it possible to keep the declaration “overflow-y: hidden”
> valid all the time? I mean, if you set height to max-content, there’ll be
> no overflowing so the value of overflow-y should not influence the layout
> (expect if you used ‘scroll’). If not, I guess you’ll have to wait for SVG
> Timesheets to have more granular control about that.
>
> Regards,
> François
>
>   *From:* Andrew Fedoniouk <news@terrainformatica.com>
> *Sent:* Friday, March 30, 2012 11:28 PM
> *To:* www-style@w3.org
> *Cc:* www-style@w3.org
> *Subject:* Re: [css-transition] :animating state pseudo-class & display
> property
>
>
> On Fri, Mar 30, 2012 at 2:15 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:
>
>> On Fri, Mar 30, 2012 at 2:10 PM, Andrew Fedoniouk
>> <news@terrainformatica.com> wrote:
>> > Consider that we have expanding/collapsing section that we would like to
>> > animate.
>> > At the end of collapsing the section should be set to display:none.
>> > And at start of animation it shall get display:none. While animating it
>> > should have overflow:hidden
>> > to achieve needed effect.
>> >
>> > I propose to add :animating pseudo-class that is "on" while element is
>> under
>> > the animation.
>> > So we will have this:
>> >
>> > section.expanded
>> > {
>> >    display:block;
>> >    height: max-content;
>> >    transition: height 400ms;
>> > }
>> > section.expanded:animating { display:block; overflow-y:hidden; }
>> >
>> > section.collapsed
>> > {
>> >    display:none;
>> >    height: 0;
>> >    transition: height 400ms;
>> > }
>> > section.collapsed:animating { display:block; overflow-y:hidden; }
>> >
>> > The :animating state pseudo-class will help to deal with
>> > other discrete non-animateable properties while animations.
>> >
>> > We are using :animating year or so ago and found it
>> > quite useful in many animation related cases.
>>
>> This seems to fall under the general "selectors can't depend on CSS
>> properties" rule.
>>
>> What happens in the following?
>>
>> :animating { animation: none; }
>> :not(:animating) { animation: foo 1s infinite; }
>>
>> ~TJ
>>
>
> To prevent possible oscillations implementations can ignore
> transition/animation properties
> in styles derived from rules with :animating pseudo-class used in any
> form.
>
> --
> Andrew Fedoniouk.
>
> http://terrainformatica.com
>
>

Received on Friday, 30 March 2012 22:08:27 UTC