[go: up one dir, main page]

RE: [css3-transitions] Transitions from display:none


[Tab Atkins Jr.:]
> 
> On Fri, Jan 13, 2012 at 11:15 AM, Sylvain Galineau
> <sylvaing@microsoft.com> wrote:
> > [Boris Zbarsky:]
> >> On 12/14/11 1:49 PM, Tab Atkins Jr. wrote:
> >> > Yup, which is a good reason why Transitions should act like
> >> > Animations and not start if the start-state was display:none.
> >>
> >> My point is that the not-computing behavior may not be limited to
> >> display:none.
> >>
> >> Again, nothing in the spec currently says when styles are actually
> >> computed.  Transition starts depend on changes to computed style, so
> >> transitions can only start if the style changes after the first time
> >> it's computed.
> >>
> >> If we seriously wanted to define this somehow, we would need to
> >> define _exactly_ when styles are computed.  Doing this and getting UA
> >> vendors to agree to the definition could be exciting.
> >>
> > This definitely seems challenging. Given something like:
> >
> > E { display:none; color:red; transition: color 0.25s; }
> >
> > ...then script such as:
> >
> > e.style.color = "blue";
> > e.style.display = "block";
> >
> > The expectation is that no transition occurs because the element was
> > display:none when the color property was updated.
> >
> > But if we now did:
> >
> > e.style.display = "block";
> > e.style.color = "blue";
> >
> > ..then the expectation is that A transition should occur as the color
> > update occurs after the element is told to generate visible boxes
> > again. Which puts pretty stringent requirement on browsers with
> > respect to when styles are computed. Today only Opera and IE10 seem to
> > align with this expectation though I haven't done anywhere enough
> testing to establish that can be relied on.
> 
> Actually, I'd expect both of those to act the same, since the style wasn't
> flushed between the two declarations.  

Expectations based on entirely undefined browser-specific optimizations does
not sound like a sound basis for standardization. I would also, at the least, 
wager that a *lot* of authors don't understand style flushing. Nor, I suspect, 
do they wish to, assuming they even should.

We have defined a basic rule - transitions do not occur if display is set to
none - that would lead to certain runtime expectations given the use-case
outlined above. But browsers will currently have a hard time fulfilling those
reliably without the kind of computation definition Boris alluded to.

I wonder whether and how the Animations and Transitions spec can cover this. 
(Or "define its undefinedness" ?) Once you explain that "in the absence of 
some kind of synchronizing event - such as request for data that requires 
style computation e.g. through getComputedStyle() - one cannot make any 
assumptions as to the timing of style computations based on conflicting 
property changes applied sequentially or in rapid succession by a script. 
As a result, some property updates may not trigger transitions" you're pretty 
much saying: "transitions start when the computed value changes, whatever 
*that* means in your UA". 

I think this is the point Boris has been making for quite some time. I don't 
have a solution but this reflects my understanding of the constraints 
implementations have in this respect. 

It seems implementations have been able to achieve a useful level of interop
without defining this so this need not impede Level 3 progress. Still, it feels
really weird to leave the trigger of transitions largely undefined.

Received on Friday, 13 January 2012 22:21:20 UTC