W3C home > Mailing lists > Public > www-style@w3.org > March 2012

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

From: François REMY <fremycompany_pub@yahoo.fr>
Date: Sat, 31 Mar 2012 00:17:29 +0200
Message-ID: <AF59706ECE4E4B929F456B814A506006@FREMYD2>
To: "Andrew Fedoniouk" <news@terrainformatica.com>
Cc: <www-style@w3.org>
So, you solve the problem by recalculating the whole computed style again. Why not, if it’s acceptable from a performance point of view. 

Just a question: how do you intend to handle such cases :

    a { color: black; transition: color 0.2s; }
    a:hover { color: white; }
    a:animating { color: black; }

?

And, more subtile, that one :

    a { color: black; transition: color 0.2s; }
    a:hover { color: white; }
    a:animating { color: gray; }

(This time, my question is: does the text becomes gray immediately or is it transitioned? When the text should change from gray to white, isn’t that going to retrigger a transition?)



From: Andrew Fedoniouk 
Sent: Saturday, March 31, 2012 12:07 AM
To: François REMY 
Cc: www-style@w3.org 
Subject: 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 
  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:17:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 22 May 2012 03:48:53 GMT