Confirmed users
166
edits
Platform/Layout/Web Animations: Difference between revisions
m
→Issue 2: Timing function list syntax
| Line 106: | Line 106: | ||
Google don't like the long list of numbers. So they have proposed chaining timing functions like so: | Google don't like the long list of numbers. So they have proposed chaining timing functions like so: | ||
We had another think about how best to represent chained timing functions and | We had another think about how best to represent chained timing functions and | ||
still prefer the idea of splitting the input time fraction into ranges, and | |||
specifying a timing function to cover that range. | |||
"ease-in 0.4 0.4, cubic-bezier(1, 0, 1, 0) 0.7 0.7, ease-out" | "ease-in 0.4 0.4, cubic-bezier(1, 0, 1, 0) 0.7 0.7, ease-out" | ||
| Line 114: | Line 116: | ||
- It allows chaining of arbitrary types of timing function | - It allows chaining of arbitrary types of timing function | ||
- It allows specification of discontinuous timing functions | - It allows specification of discontinuous timing functions | ||
- Each timing function can be parameterised independently of the range it spans. For example, in the above, the arguments to cubic-bezier() specify the shape of the curve, which is unchanged if the size or position of its range is changed. | - Each timing function can be parameterised independently of the range it | ||
spans. For example, in the above, the arguments to cubic-bezier() specify the | |||
shape of the curve, which is unchanged if the size or position of its range | |||
is changed. | |||
- It matches the keySplines / keyTimes feature of SVG exactly | - It matches the keySplines / keyTimes feature of SVG exactly | ||
To simplify the common-case of chained beziers where c1 continuity is required, we propose adding a 'smooth' option. Specifying this option means that the direction of the vector representing the starting control point of the bezier is ignored, and only its magnitude is used. Instead its direction is set to be equal to that of the tangent at the end of the previous segment (ie the negative of the vector representing the end control point in the case of a bezier). If the smooth option is specified on the first segement, a direction of (1, 0) (i.e. horizontal) is used. For example ... | To simplify the common-case of chained beziers where c1 continuity is required, | ||
we propose adding a 'smooth' option. Specifying this option means that the | |||
direction of the vector representing the starting control point of the bezier | |||
is ignored, and only its magnitude is used. Instead its direction is set to be | |||
equal to that of the tangent at the end of the previous segment (ie the | |||
negative of the vector representing the end control point in the case of | |||
a bezier). If the smooth option is specified on the first segement, a direction | |||
of (1, 0) (i.e. horizontal) is used. For example ... | |||
"ease-in 0.4 0.4, smooth cubic-bezier(1, 0, 1, 0) 0.7 0.7, smooth cubic-bezier(0, 1, 0, 1)" | "ease-in 0.4 0.4, smooth cubic-bezier(1, 0, 1, 0) 0.7 0.7, smooth cubic-bezier(0, 1, 0, 1)" | ||
Here the direction of the start control point of the first bezier is ignored, and set to match the end of the ease-in segment. Similarly, the direction of the start control point of the second bezier is ignored, and set to match the end control point of the first bezier. | Here the direction of the start control point of the first bezier is ignored, | ||
and set to match the end of the ease-in segment. Similarly, the direction of | |||
the start control point of the second bezier is ignored, and set to match the | |||
end control point of the first bezier. | |||
As a further simplification, we propose that if the coordinates specifying the end of the range are ommitted for some segment, the ranges of any underspecified segments are set so as to evenly distribute the available space (both in x and y). For example ... | As a further simplification, we propose that if the coordinates specifying the | ||
end of the range are ommitted for some segment, the ranges of any | |||
underspecified segments are set so as to evenly distribute the available space | |||
(both in x and y). For example ... | |||
"ease-in 0.2 0.2, ease-in, ease-in" | |||
is equivalent to ... | is equivalent to ... | ||
| Line 131: | Line 149: | ||
"ease-in 0.2 0.2, ease-in 0.6 0.6, ease-in" | "ease-in 0.2 0.2, ease-in 0.6 0.6, ease-in" | ||
Furthermore, if only one such coordinate is omitted, it is used for both the x and y components. For example ... | Furthermore, if only one such coordinate is omitted, it is used for both the | ||
x and y components. For example ... | |||
"ease-in 0.2, ease-in, ease-in" | |||
is equivalent to ... | is equivalent to ... | ||
"ease-in 0.2 0.2, ease-in 0.6 0.6, ease-in" | |||
I'm a bit concerned about the complexity of the numbers after the timing function. It's not obvious what they are and it's an additional concept, "rendering the timing function into a window". However, we need something like this not only for bounce effects but also because we removed timing functions from key frames. | I'm a bit concerned about the complexity of the numbers after the timing function. It's not obvious what they are and it's an additional concept, "rendering the timing function into a window". However, we need something like this not only for bounce effects but also because we removed timing functions from key frames. | ||