- From: Cameron McCormack <cam@mcc.id.au>
- Date: Sat, 28 Feb 2009 10:51:10 +1100
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: www-style@w3.org, www-svg@w3.org
Hi Tab. Cameron McCormack: > > Why are some properties defined as animatable and others not? Tab Atkins Jr.: > Because many properties simply don't have a sensical transition. I think it’s worthwhile considering specifying interpolation between non-numeric values (as I suggested earlier for ‘visibility’), even if it is just a step function. Consistency with SVG would make it easier for authors to transition to using CSS Transitions/Animations. :-) (Hmm, I feel like there should be a different verb form of the word “transition” — what is it?) > For example, transitioning from position:static to position:relative, > or display:block to display:inline. Even one that could possibly make > sense, like display:block to display:none, still has way too many > variables to be implementable. For transitions, yes it doesn’t seem to be that useful to be able to transition the ‘display’ property. But for animations, where there can be more than two values involved, it would be helpful to define this. > > Also, it would seem to be useful to be able to transition properties in > > non-visual media as well (e.g. transitioning aural properties), so I > > suggest that these properties apply to all media. > > There just aren't any aural properties currently defined as accepting > a transition. I have a hard time imagining how that would work in any > case, but somebody more familiar You could have a transition on ‘pitch’ so that synthesised speech gradually got lower or higher. Regardless of use cases, though, I can’t see a reason to restrict the ‘transition-*’ proprties to the visual media group. > > It's not exactly defined when transitions are triggered. > > […] > > It seems clear that transitions are triggered whenever the specified > value changes, whether through direct manipulation or through the > cascade. It’s not clear to me at all, from the spec. > The start and end values, similarly, seem to obviously be the previous > specified value, and the newly specified value. Sensible, perhaps, but not defined to be so. > > The transitionend event is defined to be cancelable, but what does it > > mean to cancel this event? > > It means that it doesn't bubble further up the DOM. No, cancelling of events is where you call preventDefault() on them to cancel their default action. (You’re probably thinking of stopPropagation().) So I guess I’m asking for the default action of the event to be defined (or for it to be made not cancelable). Thanks, Cameron -- Cameron McCormack ≝ http://mcc.id.au/
Received on Friday, 27 February 2009 23:51:58 UTC