Re: document transition effect

> From: Brad Kemper
> Sent: Tuesday, March 15, 2011 9:58 PM
> To: François REMY
> Cc: Yves Lafon ; <www-style@w3.org>
> Subject: Re: document transition effect
>
> On Mar 15, 2011, at 12:47 PM, François REMY <fremycompany_pub@yahoo.fr> 
> wrote:
>
> > You would need to redefine completely the semantics behind the "left" 
> > property. [...]
>
> OK, use transforms then. Or use opacity for a dissolve.
>
> > , it don't mean the other (=new) document is forced to follow the 
> > current document by moving by the same amount.
>
> No, but if it is using the same sort of CSS on its :loaded pseudo-class 
> and it is from the same site, then we can allow the two transitions to 
> happen in a coordinated fashion. Otherwise, it could happen more as a 
> reveal than a push wipe.
>
>
> > It would be very complex for another reasone : it means that if you 
> > define a transition on the "left" property, the new document moves from 
> > the right of the current document; but if it's the opacity property 
> > that's animated, then the new document should be located behind the 
> > other. It's not really intuitive...
>
> 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.


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

Additionnaly, you may also want to perform such "transition" when updating 
the background property, for example. 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.

Received on Tuesday, 15 March 2011 22:01:39 UTC