- From: Dean Jackson <dino@apple.com>
- Date: Wed, 4 Mar 2009 12:24:10 +1100
- To: Erik Dahlström <ed@opera.com>
- Cc: "www-style@w3.org" <www-style@w3.org>, www-svg <www-svg@w3.org>
Hej Erik! On 27/02/2009, at 7:54 PM, Erik Dahlström wrote: > == 5.2 "Properties from SVG" == > > The list of properties here is incomplete, and incompatible with the > SVG CSS properties that are defined to be animatable. E.g audio- > level, line-increment, and a bunch of properties that aren't > naturally interpolable, e.g fill-rule. > > Why not simply refer to the SVG specifications for which such > properties are animatable? Partially answered elsewhere, but the summary is that we only wanted properties that could be smoothly interpolated (unlike SMIL, we don't have step animation... yet). But I will revisit this suggestion. I'd like to remain compatible if possible. > > == 2.1 The ‘transition-property’ Property == > > What happens when there's a mismatch between the number of > 'transition-property' values and the number of 'transition-duration' > values? Tab answered correctly, and it's been asked before - I just need to update the specification. The lists repeat (as a whole, not just the last value). You don't use the values you have no need for. > == 2.2 The ‘transition-duration’ Property == > > The property uses <time> values, which is different from > <Clockvalue> used for specifying time in SVG[3] and SMIL. The > grammar of <time> is undefined, though a guess is that it's from CSS > 2.1 [2]. If that is the case, there are a few incompatibilies, e.g > the ability to specify time in minutes and hours, or a full > timevalue with semicolon separators. > > What's the rationale for not using the <Clockvalue> syntax? Yes, <time> is defined in CSS already, so we didn't repeat it. There is no good reason either way here - <time> is easier to implement and it doesn't rule out large values. > > == 3 Transition Events == > > Would one always get a 'transitionend' event, even if the duration > was 0? No. A zero duration means there is no transition. That allows the default value of transition-property to be "all". Just set the transition-duration and things start to animate. Without a transition there will be no event. > How about if a duration was close to 0 and the implementation was > too busy to actually apply the transition, and there was another > transition on the same property starting at some minor timedelta > ahead? Would you still get the 'transitionend' event on the first one? If a transition interrupts another transition, then the interrupted transition will not get an end event. The duration or efficiency of the implementation shouldn't matter. > What's the rationale for not using (extending if need be) the > TimeEvent interface[4]? You're right - they probably should extend the TimeEvent interface. Although, it's a remarkably bare interface, which doesn't have much to do with time, so I'm not sure what the benefit is. We'd obviously need new event names, and extra properties. Is there a strong use case for being able to identify them as TimeEvents? > == 4 Animation of property types == > > What happens if you want to interpolate two values that have > different units? Is that something that can never happen? You can certainly interpolate between "3em" and "50px", for example. The trick is, and this has been covered elsewhere, animating between percentages and values like "auto". > Color interpolation in svg takes into account the 'color- > interpolation' property[5], why does transitions not use that as well? It should, for SVG content at least. Having said that, the 'color- interpolation' property isn't that useful - it doesn't really give you much control over what the intermediate values should be, just a choice between two constant equations. More use would be the ability to interpolate in HSL, for example (which would allow brightness to remain the same but to rotate the hue). Even then, we played around with this for a bit and you still get unexpected intermediate values. Turning the request around, I suggest the SVG WG look at enhancing the 'color-interpolation' property to be more powerful. > What's the rationale for wanting to interpolate HSL color values in > RGB space? I said it above, but suppose you are animating between a color at 100% saturation and the same color at 0% saturation, or similarly for hue and brightness. Doing this in RGB gives a different result than HSL, and can sometimes give weird intermediate values. Actually, they can be weird in both RGB and HSL, but only the author can decide which they think is less weird. Having said this, we (Apple) decided to stick with only RGB for now. I'd be interested if anyone thinks it is useful to allow HSL. Dean
Received on Wednesday, 4 March 2009 01:24:53 UTC