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

On Fri, Jan 13, 2012 at 11:56 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 1/13/12 2:47 PM, Tab Atkins Jr. wrote:
>>> 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?

No?  You should be able to just apply the diff (changing 'display' and
'color') and then make a single computed-value recalc, if you don't
care about transitions.


>> - 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.

I expect that the set of points that need flushing would change over
time, yes, as we add new things.


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

"Does this operation require up-to-date style information to be
completed correctly?" sounds fairly easy.


>> (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.

Getting the input's value doesn't require up-to-date style information
(or any style information at all, actually).  If there was an odd
coupling in Gecko at some point, that was a bug at that point.  A bug
that's mostly undetectable without transitions, sure, but a bug
nonetheless.


> 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?

Transitions, by definition, start when some value changes.  We can
tweak which value we pay attention to, but I don't think that any of
them really avoid the problems we're raising.

~TJ

Received on Friday, 13 January 2012 20:09:15 UTC