W3C home > Mailing lists > Public > www-style@w3.org > March 2011

Re: document transition effect

From: Brad Kemper <brad.kemper@gmail.com>
Date: Tue, 15 Mar 2011 20:20:04 -0700
Message-Id: <5F161C39-488D-4AA9-BB8F-5B7026EA3FA1@gmail.com>
Cc: Yves Lafon <ylafon@w3.org>, "<www-style@w3.org>" <www-style@w3.org>
To: François REMY <fremycompany_pub@yahoo.fr>
>> 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.


> 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 03:20:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:49:57 UTC