- From: Håkon Wium Lie <howcome@opera.com>
- Date: Thu, 8 Apr 2010 01:27:13 +0200
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: www-style@w3.org
Maciej Stachowiak wrote: > > So, to conclude, the effects are not tied to "states". Rather, the > > effect trigger when the value of the 'effect' property changes for a > > given element. When this happens, the respective 'on-exit' and > > 'on-entry' effects will be shown. > I think triggering when the "effect" property changes is not as clean > and convenient as triggering implicitly when the value of an animated > property changes, as transitions do currently. This is the best argument I've heard so far. Indeed, it would be hard to determine which changes happen "simultaneously enough" to be considered a transition. Accordingly I have revised my proposal slightly so that transitions (called 'change effects' in my proposal below) are triggered by changes in property values. As such, the revised proposal is closer to the current specification. There are a number of differences, though: - the syntax is more readable for humans (at least this human) - only one set of properties is needed - animations can also be played 'on-exit', thereby capturing the "blue bouncy box" use case (3b in the link below) Here is a set of use cases and a comparison of the syntax used in the two models: http://people.opera.com/howcome/2010/ta/index.html And here's a more formal write-up of the proposal: The 'effect' property The 'effect' property accepts a comma-separated list of effects as value. Each effect must contain on change() or play() function in addition to optional other values. An effect is referred to as a 'change effect' or a 'play effect'. The change() function takes a property name as value. A change effect indicates that the specified property should be monitored; whenever it changes, the change effect will be shown. The length of the change, the delay of the change, and the timeing function of the change can be specified. For example, this declaration specifies that the change should take 1s, there should be a 0.2s delay for both changes, and the 'ease-in' timing fuction should be applied: effect: change(left) 1s 0.2s ease-in; The play() function takes the name of an animation as value. Animations are specified in separate @keyframes constructs. Unlike change effects, play effects are not triggered by value changes other properties, but rather by value changes on the 'effect' property itself. When an element is assigned a new value on 'effect' property, the value is examined and any effects set to start immediately are started, while effects with delayes are sceduled to be started later. Further, any effect marked to start 'on-exit' on the previous value is started. For example, this rule specifies that the 'bounce' animation should be played twice: when the 'effect' value is first set, and when the 'effect' value is reset the animation is played in reverse: a:hover { effect: play(bounce) 1s, on-exit play(bounce) 1s reverse; } Or one could write: a:hover { effect: on-entry play(bounce) 1s, on-exit play(bounce) 1s reverse; } The 'on-entry' can be considered to be a delay equal to 0. The 'reverse' keyword is offered as an alternative to the proposed 'alternate' keyword. The 'during' keyword (see the use cases) is offered as an alternative to the proposed 'infinite' keyword. If a functional notation is considered too difficult for scripts to deal with, it can be dropped. This will result in possible namespace conflicts between properties and animations. (But that conflict already exists in the current specs; we will, e.g., never be able to create a property called 'alternate' without conflicts.) If a functional notation is acceptable, one may consider putting more values inside the function. E.g: effect: change(color, 1s); Cheers, -h&kon Håkon Wium Lie CTO °þe®ª howcome@opera.com http://people.opera.com/howcome
Received on Wednesday, 7 April 2010 23:27:57 UTC