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

The problem is that the transition would never stop. For the first 0.2s, the color should move from black to gray. Then, the transition stops and the color should be white. As white != gray, there’s a transition initiated but this trigger the color to be gray. Using your rules, the :animating rule never stops to match and the color stays gray even if you remove the :hover for a very long time.

A solution is to say that :animating property declarations are not taken in consideration to compute animations (in our case, there’s a transition from black to white in 0.2s that’s overriden by ‘gray’ when it occurs). It means that when you hover the link, it becomes gray immediately for 0.2s and then switches immediately to white (end of transition). When you remove your mouse from the link, it becomes gray for 0.2s then immediately becomes black. At any time, the animation is computed as if the :animting rule didn’t apply but the current values defined by the animation are overriden by the ones specified in the :animating rule.

Is this possible to implement ?

François

From: Andrew Fedoniouk 
Sent: Saturday, March 31, 2012 4:56 AM
To: François REMY 
Cc: www-style@w3.org 
Subject: Re: [css-transition] :animating state pseudo-class & display property
I do not see any problems here:

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

the result will be exactly as in this case:


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

note last rule.

-- 
Andrew Fedoniouk.

http://terrainformatica.com


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

  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