W3C home > Mailing lists > Public > www-style@w3.org > June 2009

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

From: Giovanni Campagna <scampa.giovanni@gmail.com>
Date: Sat, 27 Jun 2009 16:25:10 +0200
Message-ID: <65307430906270725n3ba6cf93l3941621a0a9dca5e@mail.gmail.com>
To: "L. David Baron" <dbaron@dbaron.org>
Cc: www-style@w3.org
2009/6/27 L. David Baron <dbaron@dbaron.org>:
> 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.

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

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.

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 {
transition: 3s color;

p:active {

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

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

> -David
> --
> L. David Baron                                 http://dbaron.org/
> Mozilla Corporation                       http://www.mozilla.com/

Received on Saturday, 27 June 2009 14:25:54 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:27 UTC