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 <news@terrainformatica.com>
> *Sent:* Saturday, March 31, 2012 12:07 AM
> *To:* François REMY <fremycompany_pub@yahoo.fr>
> *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 <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
>>
>>
>
>
>