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

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

The only reasonable (definitive/determined) moment of time I can think of is
the moment when styles are used for rendering so inside 
"paint event" - immediately before elements are getting rendered
using that style.

Transition, when applied does not change current rendering 
style values - the transition just starts timed sequence.
On its next step used style property values will change. 

But this effectively disables animations on display:none elements - 
there is no initial rendering for them so nothing can start
transition from display:none.

We should rather enable visibility:collapsed for all elements
to overcome problem of transitions from state of element when
it has no space to taking some space.

-- 
Andrew Fedoniouk.

http://terrainformatica.com



-----Original Message----- 
From: Boris Zbarsky 
Sent: Friday, January 13, 2012 12:15 PM 
To: Tab Atkins Jr. 
Cc: Sylvain Galineau ; www-style@w3.org 
Subject: Re: [css3-transitions] Transitions from display:none 

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.

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

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

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

-Boris

Received on Friday, 13 January 2012 21:48:42 UTC