[css3-transitions] transitions and rendering objects vs. DOM nodes

I have another question about transitions that I think ought to be
addressed in the spec ( http://dev.w3.org/csswg/css3-transitions/ ),
though in this case I'm not exactly sure how it should be addressed
in the spec.
This is the question of whether transition should be associated with
a change in style on a content node, or a change in style on a
rendering object (a box). Either solution poses a bunch of
problems.
If transitions are associated with the style on an element (DOM
node), then we have problems in any case where a content node has
more than one style. The main case of this I can think of is
pseudo-elements. For example, I think it's hard to do something
sensible with:
p { color: gray; }
p::first-line { color: black; }
p:hover { color: blue; }
p:hover::first-line { color: aqua; }
a { transition: 3s color; }
then it's really not clear what the transition on the anchor should
be when the p goes into the :hover state (either when the anchor is
split between the first line and the second, or when the anchor is
entirely in the first line).
On the other hand, if transitions are associated with the style on a
rendering object, you end up with transitions not occurring when
there's also a change in 'display' or some other property that
changes what rendering objects are present.
I think the specification should define more precisely how
transitions interact with pseudo-elements and when they should occur
so that this distinction is clear.
-David
--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/

2009/6/27 L. David Baron :
> I have another question about transitions that I think ought to be
> addressed in the spec ( http://dev.w3.org/csswg/css3-transitions/ ),
> though in this case I'm not exactly sure how it should be addressed
> in the spec.
>
> This is the question of whether transition should be associated with
> a change in style on a content node, or a change in style on a
> rendering object (a box). =A0Either solution poses a bunch of
> problems.
First of all, "transition" does not apply to pseudo-elements, at least
currently. So only boxes that are directly connected to DOM elements
can have their properties transitioned.
> If transitions are associated with the style on an element (DOM
> node), then we have problems in any case where a content node has
> more than one style. =A0The main case of this I can think of is
> pseudo-elements. =A0For example, I think it's hard to do something
> sensible with:
> =A0p { color: gray; }
> =A0p::first-line { color: black; }
> =A0p:hover { color: blue; }
> =A0p:hover::first-line { color: aqua; }
> =A0a { transition: 3s color; }
> then it's really not clear what the transition on the anchor should
> be when the p goes into the :hover state (either when the anchor is
> split between the first line and the second, or when the anchor is
> entirely in the first line).
This is not a css3-transition issue, but rather a css2 issue, namely:
what is the Computed Value for color for "a"?
In fact, a lot of places in css2 and css3 modules assumes a mapping
like (element, property) =3D> (computed value), which is generally true,
as long as you don't use line level pseudo-elements (currently only
::first-line, in the future, who knows?)
Other pseudo-elements also cause similar problems (in particular
::selection and ::first-letter), although they're either unspecified
or undefined when problematic.
This means that neither css3-selectors nor css2 can advance to cr / pr
without resolving this issue. I guess the best place to solve it would
be css3-cascade, since it involves finding inherited and specified
values for splitted elements.
Given one or more Computed Values for "color", transitioning does not
require any other knowledge of parent element / pseudo-element.
> On the other hand, if transitions are associated with the style on a
> rendering object, you end up with transitions not occurring when
> there's also a change in 'display' or some other property that
> changes what rendering objects are present.
Do you mean like
p {
color:red;
transition: 3s color;
display:block;
p:active {
display:none;
color:blue;
}
In this case, the transition of color is not needed. Problems can
arise if display goes to block again while the transition should be in
progress.
> I think the specification should define more precisely how
> transitions interact with pseudo-elements and when they should occur
> so that this distinction is clear.
It is not just a css3-transitions problem, it affects most of css, from 1 t=
o 4.
> -David
>
> --
> L. David Baron =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 http://dbaron.org/
> Mozilla Corporation =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://ww=
w.mozilla.com/
>
>
Giovanni

On Saturday 2009-06-27 16:25 +0200, Giovanni Campagna wrote:
> First of all, "transition" does not apply to pseudo-elements, at least
> currently. So only boxes that are directly connected to DOM elements
> can have their properties transitioned.
That's not relevant; my cases describe issues where it applies to
things inside of pseudo-elements.
> This is not a css3-transition issue, but rather a css2 issue, namely:
> what is the Computed Value for color for "a"?
> In fact, a lot of places in css2 and css3 modules assumes a mapping
> like (element, property) => (computed value), which is generally true,
> as long as you don't use line level pseudo-elements (currently only
> ::first-line, in the future, who knows?)
> Other pseudo-elements also cause similar problems (in particular
> ::selection and ::first-letter), although they're either unspecified
> or undefined when problematic.
>
> This means that neither css3-selectors nor css2 can advance to cr / pr
> without resolving this issue. I guess the best place to solve it would
> be css3-cascade, since it involves finding inherited and specified
> values for splitted elements.
If you think there are problems with the concept of "Computed Value"
in those drafts, please raise them in a *separate* thread (and
explain why they are problems).
> > On the other hand, if transitions are associated with the style on a
> > rendering object, you end up with transitions not occurring when
> > there's also a change in 'display' or some other property that
> > changes what rendering objects are present.
>
> Do you mean like
> p {
> color:red;
> transition: 3s color;
> display:block;
>
> p:active {
> display:none;
> color:blue;
> }
>
> In this case, the transition of color is not needed. Problems can
> arise if display goes to block again while the transition should be in
> progress.
But people might want a transition when changing from 'display:none'
to some other value. For example, they might simultaneously change
'width' and want 'width' to transition.
They might also want to transition 'width' at the same time as
changing a value of 'overflow' (which is like display, at least in
our implementation, though that could be implementation-specific,
which is a reason it's bad for behavior to depend on it).
-David
--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/

In WebKit, at the moment we do transitions on rendering objects (and
yes this means changes to display:none just kill transitions). We
don't allow transitions to occur on pseudo elements. Not sure if this
is the right decision though, but it's what we have done so far.
dave
(hyatt@apple.com)
On Jun 26, 2009, at 6:44 PM, L. David Baron wrote:
> I have another question about transitions that I think ought to be
> addressed in the spec ( http://dev.w3.org/csswg/css3-transitions/ ),
> though in this case I'm not exactly sure how it should be addressed
> in the spec.
>
> This is the question of whether transition should be associated with
> a change in style on a content node, or a change in style on a
> rendering object (a box). Either solution poses a bunch of
> problems.
>
> If transitions are associated with the style on an element (DOM
> node), then we have problems in any case where a content node has
> more than one style. The main case of this I can think of is
> pseudo-elements. For example, I think it's hard to do something
> sensible with:
> p { color: gray; }
> p::first-line { color: black; }
> p:hover { color: blue; }
> p:hover::first-line { color: aqua; }
> a { transition: 3s color; }
> then it's really not clear what the transition on the anchor should
> be when the p goes into the :hover state (either when the anchor is
> split between the first line and the second, or when the anchor is
> entirely in the first line).
>
> On the other hand, if transitions are associated with the style on a
> rendering object, you end up with transitions not occurring when
> there's also a change in 'display' or some other property that
> changes what rendering objects are present.
>
> I think the specification should define more precisely how
> transitions interact with pseudo-elements and when they should occur
> so that this distinction is clear.
>
> -David
>
> --
> L. David Baron http://dbaron.org/
> Mozilla Corporation http://www.mozilla.com/
>

On Sun, Jun 28, 2009 at 9:37 AM, David Hyatt wrote:
> In WebKit, at the moment we do transitions on rendering objects (and yes
> this means changes to display:none just kill transitions). We don't allow
> transitions to occur on pseudo elements. Not sure if this is the right
> decision though, but it's what we have done so far.
>
What if you have a which fits on one line, a transition on 'color'
starts, but halfway through the container width changes so the breaks
across two lines? The second box gets the final color immediately? If this
happened because the user resized the window, I think it's clearly a bug.
Rob
--
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

On Sat, Jun 27, 2009 at 11:44 AM, L. David Baron wrote:
> I have another question about transitions that I think ought to be
> addressed in the spec ( http://dev.w3.org/csswg/css3-transitions/ ),
> though in this case I'm not exactly sure how it should be addressed
> in the spec.
>
> This is the question of whether transition should be associated with
> a change in style on a content node, or a change in style on a
> rendering object (a box). Either solution poses a bunch of
> problems.
>
> If transitions are associated with the style on an element (DOM
> node), then we have problems in any case where a content node has
> more than one style. The main case of this I can think of is
> pseudo-elements. For example, I think it's hard to do something
> sensible with:
> p { color: gray; }
> p::first-line { color: black; }
> p:hover { color: blue; }
> p:hover::first-line { color: aqua; }
> a { transition: 3s color; }
> then it's really not clear what the transition on the anchor should
> be when the p goes into the :hover state (either when the anchor is
> split between the first line and the second, or when the anchor is
> entirely in the first line).
>
How about: if an element has a first-line or first-letter rule setting a
property on it, then transitions on that property are disabled for the
element and all its descendants.
Rob
--
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

On Jun 28, 2009, at 10:57 PM, Robert O'Callahan wrote:
> On Sun, Jun 28, 2009 at 9:37 AM, David Hyatt wrote:
> In WebKit, at the moment we do transitions on rendering objects (and
> yes this means changes to display:none just kill transitions). We
> don't allow transitions to occur on pseudo elements. Not sure if
> this is the right decision though, but it's what we have done so far.
>
> What if you have a which fits on one line, a transition on
> 'color' starts, but halfway through the container width changes so
> the breaks across two lines? The second box gets the final
> color immediately? If this happened because the user resized the
> window, I think it's clearly a bug.
>
Unlike Gecko, our "rendering objects" are not affected by changes in
line structure. We create separate objects for lines. So what you
describe is not an issue in WebKit.
It's better to think of transitions as happening on nodes and on
pseudo elements, since obviously the notion of a "rendering object"
isn't the same in every engine.
I believe we just need to make pseudo elements work in WebKit.
first-line is a particularly thorny case that we'll just need to work
out.
dave

On Jun 28, 2009, at 11:12 PM, Robert O'Callahan wrote:
> On Sat, Jun 27, 2009 at 11:44 AM, L. David Baron
> wrote:
> I have another question about transitions that I think ought to be
> addressed in the spec ( http://dev.w3.org/csswg/css3-transitions/ ),
> though in this case I'm not exactly sure how it should be addressed
> in the spec.
>
> This is the question of whether transition should be associated with
> a change in style on a content node, or a change in style on a
> rendering object (a box). Either solution poses a bunch of
> problems.
>
> If transitions are associated with the style on an element (DOM
> node), then we have problems in any case where a content node has
> more than one style. The main case of this I can think of is
> pseudo-elements. For example, I think it's hard to do something
> sensible with:
> p { color: gray; }
> p::first-line { color: black; }
> p:hover { color: blue; }
> p:hover::first-line { color: aqua; }
> a { transition: 3s color; }
> then it's really not clear what the transition on the anchor should
> be when the p goes into the :hover state (either when the anchor is
> split between the first line and the second, or when the anchor is
> entirely in the first line).
>
> How about: if an element has a first-line or first-letter rule
> setting a property on it, then transitions on that property are
> disabled for the element and all its descendants.
I'm not understanding why transitions can't be made to work on first-
line and first-letter?
dave
(hyatt@apple.com)

2009/6/29 David Hyatt :
> On Jun 28, 2009, at 11:12 PM, Robert O'Callahan wrote:
>
> On Sat, Jun 27, 2009 at 11:44 AM, L. David Baron wrot=
e:
>>
>> I have another question about transitions that I think ought to be
>> addressed in the spec ( http://dev.w3.org/csswg/css3-transitions/ ),
>> though in this case I'm not exactly sure how it should be addressed
>> in the spec.
>>
>> This is the question of whether transition should be associated with
>> a change in style on a content node, or a change in style on a
>> rendering object (a box). =A0Either solution poses a bunch of
>> problems.
>>
>> If transitions are associated with the style on an element (DOM
>> node), then we have problems in any case where a content node has
>> more than one style. =A0The main case of this I can think of is
>> pseudo-elements. =A0For example, I think it's hard to do something
>> sensible with:
>> =A0p { color: gray; }
>> =A0p::first-line { color: black; }
>> =A0p:hover { color: blue; }
>> =A0p:hover::first-line { color: aqua; }
>> =A0a { transition: 3s color; }
>> then it's really not clear what the transition on the anchor should
>> be when the p goes into the :hover state (either when the anchor is
>> split between the first line and the second, or when the anchor is
>> entirely in the first line).
>
> How about: if an element has a first-line or first-letter rule setting a
> property on it, then transitions on that property are disabled for the
> element and all its descendants.
>
> I'm not understanding why transitions can't be made to work on first-line
> and first-letter?
> dave
> (hyatt@apple.com)
>
Because in that case you would have two starting values and two ending
values, one for the part of element that inherits from ::first-line,
the other from the part of element that inherits from the element
directly, whereas transitions expect one.
The same happens with ::first-letter, although it is rare, because
most often the pseudo-element is contained completely inside one
element. You need punctuation across elements to get this problem.
If the innermost approach is used for text-level pseudo-element
(including ::first-letter but also ::selection and possibly others),
this is a non-issue, since nothing can inherit from such
pseudo-elements.
Giovanni

On Jun 29, 2009, at 9:29 AM, Giovanni Campagna wrote:
> 2009/6/29 David Hyatt :
>> On Jun 28, 2009, at 11:12 PM, Robert O'Callahan wrote:
>>
>> On Sat, Jun 27, 2009 at 11:44 AM, L. David Baron
>> wrote:
>>>
>>> I have another question about transitions that I think ought to be
>>> addressed in the spec ( http://dev.w3.org/csswg/css3-transitions/ ),
>>> though in this case I'm not exactly sure how it should be addressed
>>> in the spec.
>>>
>>> This is the question of whether transition should be associated with
>>> a change in style on a content node, or a change in style on a
>>> rendering object (a box). Either solution poses a bunch of
>>> problems.
>>>
>>> If transitions are associated with the style on an element (DOM
>>> node), then we have problems in any case where a content node has
>>> more than one style. The main case of this I can think of is
>>> pseudo-elements. For example, I think it's hard to do something
>>> sensible with:
>>> p { color: gray; }
>>> p::first-line { color: black; }
>>> p:hover { color: blue; }
>>> p:hover::first-line { color: aqua; }
>>> a { transition: 3s color; }
>>> then it's really not clear what the transition on the anchor should
>>> be when the p goes into the :hover state (either when the anchor is
>>> split between the first line and the second, or when the anchor is
>>> entirely in the first line).
>>
>> How about: if an element has a first-line or first-letter rule
>> setting a
>> property on it, then transitions on that property are disabled for
>> the
>> element and all its descendants.
>>
>> I'm not understanding why transitions can't be made to work on
>> first-line
>> and first-letter?
>> dave
>> (hyatt@apple.com)
>>
>
> Because in that case you would have two starting values and two ending
> values, one for the part of element that inherits from ::first-line,
> the other from the part of element that inherits from the element
> directly, whereas transitions expect one.
Sure, but I don't see why that is a problem, as long as you specify
what happens.
dave
(hyatt@apple.com)

On Tue, Jun 30, 2009 at 2:20 AM, David Hyatt wrote:
> On Jun 28, 2009, at 10:57 PM, Robert O'Callahan wrote:
>
> On Sun, Jun 28, 2009 at 9:37 AM, David Hyatt wrote:
>
>> In WebKit, at the moment we do transitions on rendering objects (and yes
>> this means changes to display:none just kill transitions). We don't allow
>> transitions to occur on pseudo elements. Not sure if this is the right
>> decision though, but it's what we have done so far.
>>
>
> What if you have a which fits on one line, a transition on 'color'
> starts, but halfway through the container width changes so the breaks
> across two lines? The second box gets the final color immediately? If this
> happened because the user resized the window, I think it's clearly a bug.
>
>
> Unlike Gecko, our "rendering objects" are not affected by changes in line
> structure. We create separate objects for lines. So what you describe is
> not an issue in WebKit.
>
>
It's better to think of transitions as happening on nodes and on pseudo
> elements, since obviously the notion of a "rendering object" isn't the same
> in every engine.
>
Defining transitions on 'first-line' have nearly the same set of issues as
defining transitions in terms of boxes. ('before' and 'after' are obviously
easy since they can be considered to create anonymous elements of their
own.)
So here's another version of my question:
p { color:gray; }
p::first-line { color:black; }
a:hover { color:red; transition:3s color; }
Suppose initially an fits on the first line its parent , then it gets
hovered, and halfway through the transition 's width changes so the
wraps to the next line. What should happen to the second line of ? Should
it start a new transition from gray to red? Would the answers be different
if the pseudo-element rule was p::first-line { letter-spacing:1px; } ?
Rob
--
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

On Jun 29, 2009, at 4:25 PM, Robert O'Callahan wrote:
> On Tue, Jun 30, 2009 at 2:20 AM, David Hyatt wrote:
> On Jun 28, 2009, at 10:57 PM, Robert O'Callahan wrote:
>> On Sun, Jun 28, 2009 at 9:37 AM, David Hyatt wrote:
>> In WebKit, at the moment we do transitions on rendering objects
>> (and yes this means changes to display:none just kill
>> transitions). We don't allow transitions to occur on pseudo
>> elements. Not sure if this is the right decision though, but it's
>> what we have done so far.
>>
>> What if you have a which fits on one line, a transition on
>> 'color' starts, but halfway through the container width changes so
>> the breaks across two lines? The second box gets the final
>> color immediately? If this happened because the user resized the
>> window, I think it's clearly a bug.
>>
>
> Unlike Gecko, our "rendering objects" are not affected by changes in
> line structure. We create separate objects for lines. So what you
> describe is not an issue in WebKit.
>
> It's better to think of transitions as happening on nodes and on
> pseudo elements, since obviously the notion of a "rendering object"
> isn't the same in every engine.
>
> Defining transitions on 'first-line' have nearly the same set of
> issues as defining transitions in terms of boxes. ('before' and
> 'after' are obviously easy since they can be considered to create
> anonymous elements of their own.)
>
> So here's another version of my question:
> p { color:gray; }
> p::first-line { color:black; }
> a:hover { color:red; transition:3s color; }
> Suppose initially an fits on the first line its parent , then
> it gets hovered, and halfway through the transition 's width
> changes so the wraps to the next line. What should happen to the
> second line of ? Should it start a new transition from gray to
> red? Would the answers be different if the pseudo-element rule was
> p::first-line { letter-spacing:1px; } ?
At the moment in WebKit, we run transitions on the styles that aren't
pseudo-elements and that aren't affected by first-line (e.g., through
inheritance). In other words, it doesn't matter how many lines you
have or what the objects are... we will transition lines 2-n and
ignore line 1 in your example. Our line objects simply observe the
style on a master RenderObject (the master style caches the
subordinate first-line style if it is different), so that transition
would be running regardless of whether you actually had lines 2-n or
not.
It seems like first-line is the problem case, so the options are:
(1) First-line styles transition independently from the "master" style
you'd expect on all other lines.
(2) First-line styles just don't transition, but the other lines do
(i.e., we only transition on the "master" style of a DOM node)
(3) Don't run transitions at all on any lines if a first-line style is
specified.
I would object to (3), and would be fine with either (1) or (2) as
solutions. (2) is what is implemented in WebKit.
dave
(hyatt@apple.com)