W3C home > Mailing lists > Public > www-style@w3.org > August 2014

Re: Proposal: Motions along a path in CSS

From: Dirk Schulze <dschulze@adobe.com>
Date: Fri, 29 Aug 2014 06:50:03 +0000
To: Tab Atkins Jr. <jackalmage@gmail.com>
CC: www-style list <www-style@w3.org>
Message-ID: <C26A3075-1DAB-4BAC-8742-64BB65175E18@adobe.com>

>> These are the properties and the proposed values:
>> motion-path: <basic-shape> | <url> | none
>>        * basic-shape will be extended by the path() function which takes an SVG Path string.
>>        * initial: none
>> motion-position: <length> | <percentage>
>>        * The current position on the specified path or shape. Basic shapes need to specify the initial position 0.
>>        * initial: 0
> What happens if you specify a <length> longer than the path length, or
> negative?  Same with <percentage> outside of 0%-100%.

IMO the animation should never leave the path. There are a couple of possibilities:
* Shrink all specified values to the range of the path length 0% — 100% and use these values.
* Adapt timely offset and length of animation so that it reflects relative length of the specified distance between two positions. Animations would maybe start later or be faster. (Similar as CSS gradients do with negative offsets.)
* For negative positions: Start at total length of path - the negative offset and jump to 0 and continue from there afterwards. Similar for too far positions.
* Just allow percentage and require a range between 0% and 100%.

I personally like the first and last approach more from an implementers perspective. The last one would probably address possible performance issues with text or viewport dependent length units. The third one just seems confusing.

> Are we going to have the same escape-hatch as SVG for implementations
> to not exactly calculate path length, and allow authors to specify
> one, or do we consider that a legacy allowance for old implementations
> that's no longer needed?

I would not necessarily care about legacy but we should look if it was useful or not.

>> motion-rotation: auto | reverse | <angle>
>>        * ‘auto’ rotates the element dependent on the gradient at the current position on the path
>>        * ‘reverse’ does the same as ‘auto’ but rotated by 180deg.
>>        * <angle> a rotation applied to the element and keeps the rotation consistent along the animation.
>>        * initial: auto
> Does this mean that if I don't want my element to rotate at all, just
> follow the path, I can specify "0deg”?


> What happens at the points where the gradient is discontinuous?  The
> answer isn't really visible for <animateMotion>, as you pass the
> discontinuity instantenously, but motion-position lets you sit exactly
> on it.

That is right. Then the spec would need to define the gradient based on previous or following positions on the path I suppose.

>> motion: <motion-path> && <motion-position> && <motion-rotation>
>>        * The shorthand for the motion longhands above.
>> Motion animations are pre-multiplied to other transformations and apply before the ’transform’ property. Setting up the animation allows implementations to composite the element into the scene and push animations off the main thread into the compositing thread. Just like animated CSS Transforms.
>> ## Example:
>> .box {
>>        motion-path: polygon(0px 100px, 100px 50px, 200px 100px);
>>        motion-rotation: auto;
>>        transition: motion-position 3s;
>> }
>> .box:hover {
>>        motion-position: 100%;
>> }
>> Elements with the class “box” will be positions to the initial position of the motion path. On hovering, the element will be transitioned along the motion path.
>> ## Issues
>> There are some obvious topics that need to be discussed. Should the element behave as a fixed positioned element and override other properties?
> No, it seems most reasonable to do as you're currently doing, and
> treat it as a translate/rotate transform prepended to the transform
> list.

Yes, agree.

>> What about elements with different values for the display property and so on. These issues need to be discussed in the context of WebAnimations anyway.
> What about them?

Yeah, wouldn’t be any different to transform with your approach above.


> ~TJ
Received on Friday, 29 August 2014 06:50:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:45 UTC