Re: document transition effect

How do you define "if the transition was smoothley enough" ? I don't think
there's a one-fit-all definition.

For example, imagine a Metro-like button whith a 'red' background. If you
want to have a smooth transition to an 'orange' background, you may be
satisfied by a classical color blend. However, you may also want to decide
that changing the background color was a sufficient reason to trigger a
"checkerboard" visual transition. It's the same property transition, but you
just changed the intent. The first time, you wanted to have a transition on
the property (the R,G,B values are interpolated from an initial to a final
value). The second time, you didn't want the R,G,B properties to be
animated. You just have an initial visual, a final visual, and you want to
perform a transition between the two.

Another good example of the is the MVVM paradigm. If you change the content
of an HTML element but not its style, you may want to trigger a visual
transition (for example a wipe transition). Let's say, for example, that
your HTML tag was rendering data about some object and you decide to change
the data object to another one. The style behind the DOM tag didn't change,
but its visual changed since their children (in this case, some of its
textnode grand-children) have changed.

A last example can be found here :
[http://samples.msdn.microsoft.com/workshop/samples/author/filter/CheckerBoard.htm]

For those who don't have IE: you have one (parent) element containing two
child elements. One of them is visible, the other is hidden. When you invert
the style on the parent element, the visible element among the children is
changed (it's like a "tab" control). When the visible element changes, you
may want to trigger a transition. But the style of the master element didn't
change. Only the children' style has been impacted.

The last sample could be implemented easily using the "visual: <identifier>"
property:

.parent > * { display: none }
.parent.firstChild { visual: first; visual-transition: push(left);}
.parent.firstChild :nth-child(1) { display: block; }
.parent.secondChild { visual: second; visual-transition: push(right); }
.parent.secondChild :nth-child(2) { display: block; }

But maybe something simpler exists. How would you that using your proposal ?

Regards,
François

-----Message d'origine----- 
From: Brad Kemper
Sent: Wednesday, March 16, 2011 4:20 AM
To: François REMY
Cc: Yves Lafon ; <www-style@w3.org>
Subject: Re: document transition effect

>> Sure it is. The second document decides how it wants to transition in,
>> and the transition happens when the DOM for the second document is loaded
>> (alternatively, when the whole document is loaded, images and all).
>>
>
>
> Nice idea. However, you could  have conflicts. If one document moves to
> the left while the other animates its opacity, you may get strange
> results. But it seems acceptable to have conflicts, as it's up to the
> developer to think about those.

Right. That's how I see it. If the author wants some sort of weird effect,
he can get it. But with a CSS file that is shared throughout a site, it
would be pretty easy to not do that accidentally.

> > Visual transitions are something different from property transitions. >
> > Many transitions are not representable in term of property transitions.
> >  > It is sufficient to have a look at PowerPoint to notice the 
> > difference
> >  > between "object animations" and "slides transitions".
>>
>> That is true when you are doing any transition, it may be that we
>> eventually want to define some visual effect transitions to, for example,
>> transition properties like 'visibility', to allow page curls, dissolves,
>> zoom in/out, checkerboard reveals, barn door reveals, etc., and these may
>> also work for page transitions.
>>
>>
>
> Good point, too. It however still seems to me it's definitively another
> property. You're probably not wanting to introduce this new concept in the
> already existing 'transiton' properties, because such "special"
> transitions only apply to some special kind of property, not all.

I was thinking it would be functional notation within
'transition-timing-function', since that is pretty useless for properties
with only a couple or so states, like visibility.  So, for example:

transition-timing-function: effect(wipe-left ease);

Or something like that. The first argument of the function would be ignored,
I'm thinking, if the transition-property was something that was smoothly
transitional without it. And it still wouldn't help properties like
'display'.


>
> Additionnaly, you may also want to perform such "transition" when updating
> the background property, for example.

Sure.

> What about a "visual-transition: (none|dissolve|zoom-in|...) <duration>;"
> property. Each time the visual representing the DOM element is modified,
> the visual-transition occurs and the old visual is smoothly transformed
> into the new one.
>
> The only problem is that all visual changes are not always expected to
> trigger a transition. Exemple: in a flexible layout, the visual may be
> regenerated just because the size of the window changed. The Microsoft way
> to solve the triggering problem was to use JavaScript, which is probably
> not what we want here (even if it does the trick, most of the time). Maybe
> something like "visual-transition-triggers: visibility, display,
> background;" ? Or a "visual: <identifier>" property which would trigger
> the visual-transition when changing its value ? More reflection should
> happen here to see what's the best solution. Visual transitions in pure
> CSS is not an easy thing. Maybe not to implement, but at least to
> implement in a good way.

This sounds more complicated than what I had in mind. =

Received on Wednesday, 16 March 2011 19:52:41 UTC