Re: [css3-transitions]

2009/3/30 Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>:
> Giovanni Campagna:
>> 2009/3/29 Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>:
>> > Hello,
>> >
>> > these comments are related to
>> > http://www.w3.org/TR/2009/WD-css3-transitions-20090320/
>> >
>> >
>> >
>> > 1. It is not obvious to me how to specify the values, the
>> > transition appears between - ok, the initial value seems
>> > to be what is called in SMIL/SVG animations the
>> > underlying value, how is the 'to-value' specified?
>> > Is it possible to specify a transition from a 'to-value' to
>> > the underlying value too?
>> > Is it required to use the animation module or another
>> > language (like scripting) to specify all this?
>> > If another language or scripting is required, this would be
>> > disappointing and discouraging for many authors relying on
>> > declarative notations for styling and layout and simplicity.
>> > Other authors would be forced to create constructions
>> > not accessible anymore either without activated scripting or
>> > CSS, what would be bad/poor styling.
>>
>> It seems to me that you missed the meaning of transition:
>
> I did not find or understand this within the draft/specification,
> maybe more complete samples can be useful to improve
> better understanding. Yesterday and today I found some
> WebKit samples somewhere around, but this draft should
> be understandable on its own.

Well, it says something about css properties changing value, but I
agree with you, it should be explained better what transitions are.

>> a transition
>> happens when the Specified Value of a property that is defined to be
>> transitioned is changed. The from value is the previous value of the
>> property, the to value is the new value.
>> Transitions don't require animations, SMIL or scripting. Just a
>> property value changing.
>> If you want the opposite transition (from "to" to "from"), just go
>> back to the previous value.
>
> About the found samples - this was always CSS for
> (X)HTML, roughly about 50% use :hover to change
> something, the other 50% use scripting (therefore
> those 50% did not work at all with
> my preferences for unkown pages ;o)

> I did not found an example using :focus or :active
> of maybe a SMIL/SVG set of a CSS property - does
> this cause a transition too or is the effect overwritten
> by the higher priority of SMIL/SVG CSS-property
> animations?

SMIL/SVG animations don't change the Specified Value of a property (if
I remember correctly), so the don't cause transitions.

> SVG+CSS samples I created today did not work at
> all in the WebKit I have installed (528.16, Safari 4 beta),
> neither with :hover nor with setting a property.

This is an implementation bug.

> Already this indicates, that it can be very useful, to explain
> it better and to provide more examples for better
> understanding for CSS in (X)HTML and SVG.
>
>>
>> > 2. It is not obvious to me, how the native CSS works to begin
>> > the transition or is this always triggered from outside of CSS
>> > or with the onload event of the CSS file?
>> > I think, it would be essential especially for authors, who want
>> > to use these module to style (X)HTML or XML, to have a
>> > native CSS method to start the transition. This is less important
>> > for SVG authors, because SVG has already its own more
>> > advanced animation methods covering this problem in a
>> > convenient way.
>> > This SVG/SMIL solution could be a guide, what is required
>> > to start transitions.
>> > Especially the events activate, beginEvent, endEvent,
>> > repeatEvent could already cover a lot of use cases.
>> > Device dependent events like click, mousedown, mouseup,
>> > mouseout, mouseover, mousemove could be useful too,
>> > however they have of course the problem, that they are
>> > not accessible, if the user has no pointing device.
>> > Another essential feature is the possibility to combine
>> > the event with an identifier.
>>
>> Transitions don't depend on events, they depend on property Specified
>> Value changes. This is caused by changing the set of selectors
>> matching an element (ie adding a class, a pseudo-class or moving an
>> element).
>>
>
> Then it could be shown with samples, how values can be changed
> natively within CSS.
>
> For example:
>
> First CSS-file:
> div {
> transition-property: opacity;
> transition-duration: 20s;
> opacity:0.5
> }
>
> Second CSS-file:
> div#something {
> opacity: 0.9
> }
>
> Does it cause a transition 'onload' of the second CSS-file,
> especially visible, if the 'onload' of the second CSS-file is
> retarded for some reasons by the server for 5s?

Uhm... this can be a big source of bugs. But AFAIK, browsers start
rendering only when all stylesheets have been downloaded, to prevent
Flash of Unstyled Content

>
> Or this:
> input#something {
> transition-property: transform;
> transition-duration: 9s;
> transform: rotate(180deg)
>  }
>
> input#something:focus
> {
> transform: scale(-1.2,1.2)
> }

This causes a transitions rotating back the element to 0° and scaling
it at the same time.


> Or this one:
> a#something {
> transition-property: color;
> transition-duration: 5s;
> color: blue
> }
>
> a#something:active
> {
> color: red
> }

This causes a transition that gradually changes the color of the
element (being violet in the middle)

> Or this one:
> div#something {
> transition-property: left;
> transition-duration: 17s;
> position: absolute;
> left: 1em;
> top: 1em;
> }
>
> div#something:hover {
> left: 200em;
> }
>
> There is no precise definition of :hover concerning
> timing of those transitions in the selector section/module.
> When does it exactly start, when does it stop?
> Trying similar things with WebKit today, this viewer
> starts something, when the pointing device
> above #something is changed.
> However, if only #something is moved away from
> the pointing device, this does not mean for WebKit,
> that :hover is not applicable anymore. But much
> later, when the pointing device is moved again, but
> far away from #something, :hover becomes not
> applicable anymore and the transitions starts again.
> I think, this is not the only possible interpretation
> of :hover according how this is specified in CSS.
>
Please not that, per CSS21 and Selectors Level 3, there is no precise
definition of :hover at all. You should not move, shrink, rotate while
hovering, different implementation have different effects (Firefox
flashes, for example)

>> > Currently CSS mainly seems to have :hover and :focus
>> > to begin or to change something. If we have for example
>> > the :hover, is the transition stopped, if :hover does not
>> > apply anymore? This could be avoided of course with
>> > something like ID.activate or ID.click as begin.
>>
>> If :hover doesn't apply anymore, and :hover changed a property (and
>> started a transition), then the new Specified Value is the one the
>> property add before hovering. The property is so transition between
>> the current Computed Value (in the middle of transition) and the
>> Computed Value found for the new (ie the old) Specified Value.
>>
>
> Following discussions between many authors and looking on their
> 'desires' in the last 10 years, I think, events like ID.activate or ID.click
> would be in general useful to be able to change a value - with or without
> a transition and natively in CSS without using another language
> like SMIL or a scripting language.

CSS is declarative: you don't have events, you have states (like
:hover and :active) and state changes (Transitions). This means that
ID.activate is ID:active

> ....
>>
>> > 5. in section 4. it is not noted, how to animate
>> > between keywords (they are mentioned
>> > in 5. too). This will be the same as for
>> > 'visibility'? Or are the keywords always
>> > converted into numbers for the current
>> > animatable properties (seems to apply
>> > only to vertical-align).
>>
>> Not all properties are animatable (see section 2). I expect that a
>> specific section for vertical-align will be included if we want to
>> support it (or vertical-align will be modified to find a Computed
>> Value being always <length> or <percentage>)
>
> It is noted to be animatable/transitionable already in 5. as
> I noted above, including 'keywords' ...

I meant that we should include something specific instead of relying
on the general "keywords" type.

>> > About paint-server - how to interpolate
>> > between a radial and linear gradient?
>> > Is the direction vector for linear gradients
>> > interpolated too if different? Respectively
>> > the cx, cy, fx, fy, r for a radial gradient?
>> > What about gradientUnits, gradientTransform,
>> > spreadMethod, xlink:href? Or is the interpolation
>> > done for each pixel of the output separately?
>> > I think, it needs some more explanations
>> > how this should work.
>>
>> Probably only gradients of the same types can be interpolated.
>
> Maybe, doing it pixel for pixel would be an interesting effect too ;o)

Out of scope of my knowledge (and my taste) :)

>> This is
>> similar with happens with width (you cannot transition from a length
>> to a percentage)
>
> Why not? The percentage can be computed at any time to a
> measurable length, if it represents a fraction of a length.
> You cannot have a transition between seconds and millimeter
> maybe, because both are units for different entities in physics.

You always transition and animate on the Computed Value. This means
that the Computed Value must be of the same type or they cannot be
interpolated (this is to avoid recomputing the layout for every
transition tick)

>> > 6. in section 5. Animatable properties
>> > the transform property seems to miss,
>> > but in 4. it is noted, that this is animatable too.
>>
>> Again, editiorial
>>
>> > Why not animation for 'display'? This is already
>> > now quite popular to be changed with :hover,
>> > I think more than for example 'visibility'
>>
>> What is the meaning of display in the middle of a transition, eg.
>> between block and inline? Inline-block? :D
>> Or you want to transition the reflowing caused by display change?
>
> The same applies for visibility, what is indicated to be
> animatable/transitionable ...

In fact, I'm not sure that visibility should be animatable at all.
Anyway, it is possible that both visibility and display will be made
animatable for compatibility with SVG12

>> Next time you start a thread remember to post to "public-fx@w3.org",
>> that is the best place for visual effects in CSS / SVG.
>>
>
> It is noted in the draft:
> "The (archived) public mailing list www-style@w3.org (see instructions) is
> preferred for discussion of this specification."
>
> Should be changed then to the new list as soon as applicable ...

Well, the public-fx list is rather new and anyway temporary (is the
cross-group list for both CSS and SVG)

>
> Olaf
>

Giovanni

Received on Monday, 30 March 2009 16:24:48 UTC