W3C home > Mailing lists > Public > www-style@w3.org > May 2006

Re: [CSS3] transition effects

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Mon, 15 May 2006 09:12:34 +0200
To: Laurens Holst <lholst@students.cs.uu.nl>
Cc: www-style@w3.org
Message-ID: <gc8g62t4q9dtdbdgceq2gdbtjrkhp71f21@hive.bjoern.hoehrmann.de>

* Laurens Holst wrote:
>> how the proposed solution interacts with those other facilities
>
>Just like CSS does right now.

Well, it is not clear to me how your proposal interacts with CSS in the
first place. If you have a 2s transition of the color from red to blue,
what is the specified and computed value of the color property at 1s? If
these are unaffected by your proposal, it is unclear to me what happens
if the computed value of the property changes at 1s especially if there
is no state transition, or what happens if you mutate the animate-*
properties while the transition effect is being applied.

>As an example of that, quoting from the SMIL animation module:
>>
>> The following example sets the |class| attribute of the text element 
>> to the string "highlight" when the mouse moves over the element, and 
>> removes the effect when the mouse moves off the element. 
>>
>> <text>This will highlight if you mouse over it...
>>    <set attributeName="class" to="highlight" 
>>             begin="mouseover" end="mouseout" />
>> </text> 
>>   
>
>With the CSS properties I proposed, SMIL could set this, and the CSS 
>would then make this happen smoothly instead of instantly.

Well, that's

  <div style="color:red">
    <animateColor attributeName="color" to="blue" dur="2s"
             begin="mouseover" end="mouseout" />
    ...

You cannot interpolate from one class to another using current means,
while that seems possible under your proposal, it is unclear to me how
this is supposed to work. The code above will, by the way, work with
minor adjustments in your favourite SMIL and SVG implementations, in-
cluding Internet Explorer, Opera, and other CSS implementations.

>I also do not think SMIL offers such functionality without putting 
>styling properties in the SMIL code, especially not as extensive as in 
>my proposal (all properties can be animated)?

I don't think putting animation effect information into animation effect
markup is any worse than putting animation effect information into style
sheets. What can be animated is for markup languages and CSS to define,
SMIL does not restrict this in any way.

>But when you would want to create ‘state transitions’ with them would 
>actually be counterproductive as you’re moving part of the positioning 
>information out of CSS into the SMIL ‘from’, ‘to’ and ‘by’ attributes. 
>There is nothing particularly wrong with this for (event-driven or 
>timeline-driven) animations, but for mere transition effects I do not 
>think this is good.

I don't follow you here. The only concern that I could see is that you
might want to have different animation effects depending on the style
sheet, and the animation effects should consequently not be specified
as part of the document that is being styled; where that is a concern
it should be easy to define XBL2<->SMIL interaction in a way that allows
you to make transition effect XBL2 documents. If you'd have that, what
pain would your proposal solve?
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 
Received on Monday, 15 May 2006 07:12:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:45 GMT