CSS transitions on and inside 'display:none'
L. David Baron
transitions. I'll have to bring it up on www-style soon, although
I'm not sure yet what I'm going to say there.
The question is what should happen (1) for CSS transitions on
elements that have display:none at one end of the transition or the
other, most importantly elements that are changing from display:none
to some other value of display and (2) for CSS transitions on
descendants of those elements, when the style changes are
simultaneous with the display change.
The easiest implementation definitely ignores (2), and probably (1)
as well, although supporting (1) wouldn't be as hard as (2).
In order to support (1) only, we would just need to initiate
transitions on style changes when elements are coming out of the
undisplayed map. To support (2), we'd need to keep style data for
elements that are descendants of 'display:none' elements, which
would require some substantive architectural changes, or at the very
least, a significant expansion of the purpose of the undisplayed map
(which currently exists only to contain elements on which style
changes could cause the element to become displayed).
However, if we want to skip transitions on elements that are coming
from being 'display: none', also a real danger here that, if we want
real interoperability here, we'll need to standardize the definition
of what style changes are simultaneous.
Skipping transitions on things that are display:none (rather than
transitioning from it) also means computed style on subtrees inside
display:none elements would be inconsistent with those outside; it
seems like this could be a problem.
It seems to me that the *right* thing to do is to make the
architectural changes needed for transitions on elements that are or
were inside display:none elements. However, that probably has
significant performance costs: it would substantially reduce the
performance saving of making elements display:none (including the
cost of dynamic style changes that we currently skip processing for
subtrees inside display:none elements).
Then there's also the question of supporting transitions on elements
that aren't in the document. I'm inclined not to care, although we
do support computed style on elements not in the document (i.e.,
without a parentNode chain up to the document object).
Thoughts?
-David
--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/
Robert O'Callahan
> It seems to me that the *right* thing to do is to make the
> architectural changes needed for transitions on elements that are or
> were inside display:none elements. However, that probably has
> significant performance costs: it would substantially reduce the
> performance saving of making elements display:none (including the
> cost of dynamic style changes that we currently skip processing for
> subtrees inside display:none elements).
But we'd only need to do that work for documents where transitions are
present, at least?
Rob
L. David Baron
Yes, although we'd have to detect whether transitions are present at
CSS parse time. (If we did it after style resolution we could miss
the cases this would be for until after they mattered.)
fantasai
> I realized another possible spec and implementation issue with CSS
> transitions. I'll have to bring it up on www-style soon, although
> I'm not sure yet what I'm going to say there.
>
> The question is what should happen (1) for CSS transitions on
> elements that have display:none at one end of the transition or the
> other, most importantly elements that are changing from display:none
> to some other value of display and (2) for CSS transitions on
> descendants of those elements, when the style changes are
> simultaneous with the display change.
>
> The easiest implementation definitely ignores (2), and probably (1)
> as well, although supporting (1) wouldn't be as hard as (2).
>
> Thoughts?
I would
1. Disable transitions between 'display' values.
2. If necessary, introduce a new collapse value for 'visibility'
that affects elements other than table rows and columns.
Do we really have transitions between other 'display' values defined
already?
~fantasai
fantasai
> On Friday 2009-07-31 13:35 -0700, fantasai wrote:
>> 1. Disable transitions between 'display' values.
>
> transitions from changes on other properties that happen at the same
> time as a change to 'display'.
So 'none' is not a special case, just a common one.
Yeah, I'd say disable transitions when you're swapping 'display' or
'position' values. Anything that requires frame reconstruction. If
people want things to appear and disappear, they should use 'opacity'
or 'visibility' transitions. And if they want them to be put in or
out of flow, then we should create a new collapse-type value for
'visibility' to handle that use case.
~fantasai
L. David Baron
But, as I pointed out elsewhere, that requires that we come up with
an interoperable definition of when two style changes are
"simultaneous".
fantasai
> On Monday 2009-08-03 13:20 -0700, fantasai wrote:
>> L. David Baron wrote:
>>> On Friday 2009-07-31 13:35 -0700, fantasai wrote:
>>>> 1. Disable transitions between 'display' values.
>>> The issue isn't transitions between 'display' values. It's
>>> transitions from changes on other properties that happen at the same
>>> time as a change to 'display'.
>> So 'none' is not a special case, just a common one.
>>
>> Yeah, I'd say disable transitions when you're swapping 'display' or
>> 'position' values. Anything that requires frame reconstruction. If
>> people want things to appear and disappear, they should use 'opacity'
>> or 'visibility' transitions. And if they want them to be put in or
>> out of flow, then we should create a new collapse-type value for
>> 'visibility' to handle that use case.
>
> But, as I pointed out elsewhere, that requires that we come up with
> an interoperable definition of when two style changes are
> "simultaneous".
Oh, hm. I think that reaches way beyond my knowledge areas then.
As someone completely ignorant of the relevant issues, I'd say
"any style changes triggered by the same event are simultaneous".
~fantasai
Boris Zbarsky
> Oh, hm. I think that reaches way beyond my knowledge areas then.
> As someone completely ignorant of the relevant issues, I'd say
> "any style changes triggered by the same event are simultaneous".
Can you define "same event"? :(
-Boris
fantasai
DOM event?
~fantasai
Boris Zbarsky
There's no concept of "the DOM event triggering the change". A number
of changes are not associated with DOM events at all, or happen
significantly after the DOM event that "really" triggered them.
Further, while a DOM event is "active", one can have arbitrary changes
happening (think DOM events that spin the event loop).
-Boris
L. David Baron
Many style changes happen from things that aren't DOM events. They
can happen as a result of script setting attributes or changing
style sheets, script inserting elements, and the script could be
running due to page loading, due to DOM events, due to timeouts, or
probably due to a bunch of other things.
fantasai
> On Tuesday 2009-08-04 13:28 -0700, fantasai wrote:
>> Boris Zbarsky wrote:
>>> fantasai wrote:
>>>> Oh, hm. I think that reaches way beyond my knowledge areas then.
>>>> As someone completely ignorant of the relevant issues, I'd say
>>>> "any style changes triggered by the same event are simultaneous".
>>> Can you define "same event"? :(
>> DOM event?
>
> Many style changes happen from things that aren't DOM events. They
> can happen as a result of script setting attributes or changing
> style sheets, script inserting elements, and the script could be
> running due to page loading, due to DOM events, due to timeouts, or
> probably due to a bunch of other things.
So, how about DOM mutation or user-interaction event?
In a script with two SetAttribute calls, any style changes triggered
by a single call are "simultaneous", but the style changes triggered
by one call are not simultaneous with the changes triggered by another.
If these calls are triggered by a mouseover event, they are not
simultaneous with :hover-based changes due to the mouseover event.
~fantasai
who is shooting blindfolded here