- From: Sylvain Galineau <galineau@adobe.com>
- Date: Mon, 11 Aug 2014 00:49:56 +0000
- To: Lea Verou <lea@verou.me>
- CC: "L. David Baron" <dbaron@dbaron.org>, Tab Atkins Jr. <jackalmage@gmail.com>, "<www-style@w3.org>" <www-style@w3.org>
On Aug 10, 2014, at 5:17 PM, Lea Verou <lea@verou.me> wrote: > On Aug 11, 2014, at 03:08, Sylvain Galineau <galineau@adobe.com> wrote: >> Yes, if it is common to not define transition-property and rely on its initial value of 'all' then this could cause some awkward surprises. > It’s *extremely* common. I’d say it’s the most common way transitions are used. I believe it. After all, not maintaining a list of properties sounds like less work :) > >> We'd have to redefine 'all' to mean 'all properties with interpolable values' which does sound awkward. >> >> At the same time, if animating all values is a good thing for animations it also seems awkward to arbitrarily prevent it in transitions. Or maybe animations are the fallback in this case? > IMO it would be very useful to allow this in transitions as well and would open up some very interesting possibilities that require hacks today. > One solution that minimizes (but doesn’t completely eliminate) the backwards compat consequences would be to make `all` mean all properties, but redefine the initial value to a new keyword that means "all interpolatable properties". Since most authors use `all` implicitly, that would prevent most cases of breakage. Speaking of which, it's not 100% clear to me what is supposed to happen to non-animatable properties. Do they transition immediately as they do in a browser with no css-transitions support? Or should they switch at the end of the specified duration? Either way, it still seems awkward for these properties to change value at a different point than in css-animations. I might have missed the css-transitions prose for this though.
Received on Monday, 11 August 2014 00:50:27 UTC