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

On 1/13/12 2:47 PM, Tab Atkins Jr. wrote:
> It was observable before, by timing.

"Maybe".  Timing takes a lot of effort and assumptions to observe this 
sort of thing with.

And more important, the only reason web devs care about timing, really, 
is if things are slow.

>> I'm not sure I follow.  Why would it need that?
>
> Sorry, misspoke.  It'd have to do two computed-value runs, not layouts.

Possibly, yes.  You have to do that now anyway, no?

>>> WebKit and Firefox should both align with this "you haven't flushed
>>> the styles yet" behavior
>>
>> Why would they?  There's no spec for it, and at least in Gecko there are
>> various things that may involve style flushes which may not be obvious to a
>> casual observer.  For example, getting or setting the .value of an
>> HTMLInputElement involved flushing styles for a while.  I don't know whether
>> it still does or not.
>>
>> I fully expect that it's trivial to write testcases in which some operation
>> has the side effect of flushing styles in WebKit but not Gecko, and vice
>> versa.
>
> Sorry, that "should" was about what I thought they did, not what I
> thought they *should* do.

Yes, I know.  My point was that outside the most trivial testcases 
they're probably not interoperable.

> Yes, our flushing behavior probably differs somewhat from yours.  I
> expect we're fairly close, though

I don't.

>- close enough that defining it and aligning wouldn't be a huge deal.

I think it would be.  We'd need to defined flushes at the superset of 
points where the browser needs style information... or might need it in 
the future for some reason.  Unless we plan keep changing the definition 
of where flushes happen as browsers change internals and discover that 
some operation that previously didn't need style information suddenly 
needs it.

> Deciding whether an operation
> should or shouldn't flush styles is fairly easy, after all.

No, it's not.

> (Getting or setting .value on an<input>  shouldn't flush, for example.  ^_^)

That overconstrains the implementation in ways that are undesirable. 
Again, Gecko needed to flush there at one point because of the way value 
state management was split up between the editing widget and the 
element.  We may since have changed that such that flushing is no longer 
needed, but trying to pin down exactly when flushing is and is not 
allowed to happen will prevent all sorts of existing and future 
implementation choices that I don't think we want to prevent.

Perhaps we should just face up to the fact that the current definition 
of when transitions start is broken by design and come up with a better one?

-Boris

Received on Friday, 13 January 2012 20:04:17 UTC