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

On Fri, Jan 13, 2012 at 12:15 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 1/13/12 3:08 PM, Tab Atkins Jr. wrote:
>> 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.
>
> Oh, I meant "now" with transitions.  I mean... they're here.  We're just
> talking about better defining how they work, but they already work.

Ah, kk.  Yes.


>>>> 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.
>
> It depends on what one means by "correctly".
>
> Does setting src on an image require up-to-date style information? Well,
> that depends on whether your ad blocker wants to know image sizes, now
> doesn't it?

No, it doesn't.  If the adblocker wants to know an image's size, it
will *request* the image's size.  *That* is an operation that requires
up-to-date layout information.  Setting the src of an image might
trigger an adblocker's operation, but it does not, itself, require any
layout info to complete.


>> Getting the input's value doesn't require up-to-date style information
>> (or any style information at all, actually).
>
> That's simply not true in lots of implementation strategies. Information may
> be lazily passed between the editor widget and the element, and flushing the
> information to the right place may require computing style information.
>
> You seem to think that text input values are simpler than they really are...
> they're not.

I do not understand at all how the style engine is involved in
changing the value of an input.  Enlighten me?

(The only thing I can think of is if it's considered similar to a DOM mutation.)


>>> 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.
>
> OK.  Perhaps the right thing to do is to define particular points when
> values are examined to see whether they have changed, then?  Right now it's
> "whenever the browser notices", which is where the flushing-related issues
> are coming from.
>
> I don't have concrete suggestions here, sadly....

Yes, I'd like to do so.  It makes sense to me to base this timing off
of the flush points (specifying when flush points occur), but there
may be a better place to do so, like "at the end of the current task"
(the hook used for the new mutation events).

~TJ

Received on Friday, 13 January 2012 20:23:07 UTC