Re: [css3-transitions]

Giovanni Campagna:

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

The priority question could be interesting, if all of this happens
for one property - SMIL/SVG animation with attributeType XML,
CSS stylesheets, CSS transitions or CSS animations
and SMIL/SVG animation with attributeType CSS and
of course author stylesheet with !important rule and 
CSS transitions or CSS animations ;o)
Due to SMIL animation this should be already roughly
the list of priorities, lowest first. 
However there is a SMIL timesheets draft as well, and
as far as I remember they did not note yet clearly, what happens,
if different timesheet files and internal animation is available.
Gets even more complex with transitions/animations within 
the CSS files if an author is crazy enough to mix them all ;o)

....

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

Hmm, as already noted, most people use this, if not java-script.
This may indicate already that there is a need for some mechanism
to change something with precise timing in a native CSS way to
avoid the need to mix up quite different things for layout/styling.

....

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

SMIL/SVG animations are declarative as well and have these events fortunately.

And you can start #x with y.activate or y.click - this means an event on one
element starts something for another element - quite useful for many
applications (and for some advanced desired layout too).

Typically in some browsers you cannot even see a visible effect with
:active but I will have a try with transitions, whether it is possible to get
a longer visible effect or not ...



Olaf

Received on Monday, 30 March 2009 17:17:25 UTC