- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 3 Dec 2009 12:22:18 -0600
- To: fantasai <fantasai.lists@inkedblade.net>
- Cc: Giovanni Campagna <scampa.giovanni@gmail.com>, "L. David Baron" <dbaron@dbaron.org>, www-style <www-style@w3.org>
On Thu, Dec 3, 2009 at 12:14 PM, fantasai <fantasai.lists@inkedblade.net> wrote: > Tab Atkins Jr. wrote: >> >> On Tue, Nov 24, 2009 at 7:57 AM, Giovanni Campagna >> <scampa.giovanni@gmail.com> wrote: >>> >>> Section 3, it says: "Implementations must not start a transition when >>> the computed value of a property changes as a result of declarative >>> (as opposed to scripted) animation. " >>> I read this as "changing the :hover state of an element must not start >>> a transition", which is obviously against the purpose of declarative >>> transitions (as opposed to script-controlled animations) >> >> Note the word "animation" at the end of that sentence. Changing the >> :hover state is not a declarative animation, and so doesn't fall under >> the scope of that sentence. > > Actually, I think Giovanni's got a really good point. The distinction > we want here is triggering on changes to specified values, not changes > that only affect the computed value. And we want this limitation to > apply to scripting as well: triggering a transition on <span> because > I changed <p>'s color doesn't make any more sense if I do it via JS > instead of 'transition'. Hmm? We certainly do want to trigger a transition on the <span>. The only time we don't is if the <p> is *already* transitioning color (we don't want the span undergoing tons of transitions, one per animation-step), and that's already taken care of by the line in the spec. I don't want there to be a difference between "span { transition: color 1s; } p { color: blue; } p { color: red; }" and "span { transition: color 1s; color: blue; } span { color: red; }" when I'm looking at a simple <p><span>foo</span></p> markup. True, we don't it to trigger a transition on the <span> if we're doing a js-based transition of the <p>'s color, but the js can temporarily turn off transitions on child elements and then restore them afterwards. (And this can be done in the library, so it's invisible to authors.) The eventual goal is to make CSS-based transitions powerful enough to handle virtually all transition needs. ~TJ
Received on Thursday, 3 December 2009 18:22:46 UTC