Intent to Ship: animation of the offset-path property

[Eric Willigers]

Contact email

ericwi...@chromium.org

Spec

https://drafts.fxtf.org/motion-1/#offset-path-property

The offset-path property has already shipped, but without animation as that intent explicitly didn't ship any new behavior, and the old motion-path property wasn't animated. (Originally, only motion-rotation and motion-offset were animated.)

There was a tag review for the original spec.

Summary

We will now support animations and transitions on offset-path. An example use case is when an element moves along a path that is itself moving. Another use case is circular movement as the direction of a ray path animates.

Link to “Intent to Implement” blink-dev discussion

Covered by original Intent to Implement.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Demo link

http://codepen.io/ericwilligers/pen/PpqMqM

Interoperability and Compatibility Risk

No risk expected. Eight people have raised minor issues with the motion path spec, which is an encouraging level of engagement. Many of the open issues are about wording, none are about animation.

OWP launch tracking bug

crbug.com/696412

Entry on the feature dashboard

https://www.chromestatus.com/feature/5198375053950976

[Chris Harrelson]

LGTM1

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Brian Birtles]

A few questions:

1. The spec doesn't link to a definition of interpolation/addition for path(). Where is this defined?
2. Are there web-platform-tests for this?
3. Less relevant: What are your plans for supporting animation of the offset shorthand when this name conflicts with Web Animations keyframe offset property?

Thanks!

Brian

[Eric Willigers]

Responses inline.

1. The spec doesn't link to a definition of interpolation/addition for path(). Where is this defined?

https://www.w3.org/TR/SVG/paths.html#DAttribute

This is the definition for interpolation and addition of path attributes that is used for SMIL.

I've uploaded a pull request for the Motion Path spec.

 

2. Are there web-platform-tests for this?

Not yet for motion path. There are SVG tests for SMIL animation of path data. e.g.

https://www.w3.org/Graphics/SVG/Test/20110816/harness/htmlSVGWeb/animate-elem-83-t.html

I can write some interpolation web-platform-tests for the motion path properties.

Two of our recent interns began a polyfill for CSS Motion Path, building on top of the Web Animations polyfill. We would like to bring this polyfill, and Blink's native implementation, to a state where many tests can be written to pass with both implementations. (This polyfill doesn't parse style sheets. All motion path properties would need to be specified in Web Animations keyframes.)

 

3. Less relevant: What are your plans for supporting animation of the offset shorthand when this name conflicts with Web Animations keyframe offset property?

I forgot about the Web Animations aspect of https://github.com/w3c/fxtf-drafts/issues/51

The best option would be cssOffset, like cssFloat.

[Brian Birtles]

On Mon, Mar 6, 2017 at 9:18 AM, Eric Willigers
<ericwi...@chromium.org> wrote:
> Responses inline.
>
>> 1. The spec doesn't link to a definition of interpolation/addition for
>> path(). Where is this defined?
>
>
> https://www.w3.org/TR/SVG/paths.html#DAttribute
>
> This is the definition for interpolation and addition of path attributes
> that is used for SMIL.

That doesn't define how addition works. Does the Blink implementation
support addition?

Also, the definition in SVG 2 appears to be more thorough so we should
probably refer to that instead:
https://svgwg.org/svg2-draft/paths.html#DProperty

I wonder why we don't normalize the path before trying to match up the
segments? Does the Blink implementation do that?

It seems like the computed value for the 'd' property and
'offset-path' property should be the normalized path (i.e. M, L, C, z
only) or at least have some strict serialization so that "M0,-.5"
becomes "M0,-0.5" etc. What does Blink do for serialization?

>> 2. Are there web-platform-tests for this?
>
>
> Not yet for motion path. There are SVG tests for SMIL animation of path
> data. e.g.
>
> https://www.w3.org/Graphics/SVG/Test/20110816/harness/htmlSVGWeb/animate-elem-83-t.html
>
>
> I can write some interpolation web-platform-tests for the motion path
> properties.

That would be great. Thanks.

>> 3. Less relevant: What are your plans for supporting animation of the
>> offset shorthand when this name conflicts with Web Animations keyframe
>> offset property?
>
>
> I forgot about the Web Animations aspect of
> https://github.com/w3c/fxtf-drafts/issues/51
>
>
> The best option would be cssOffset, like cssFloat.

Ok.

Thanks,

Brian

[Fredrik Söderquist]

On Mon, Mar 6, 2017 at 2:17 AM, Brian Birtles <bbir...@mozilla.com> wrote:

On Mon, Mar 6, 2017 at 9:18 AM, Eric Willigers
<ericwi...@chromium.org> wrote:
> Responses inline.
>
>> 1. The spec doesn't link to a definition of interpolation/addition for
>> path(). Where is this defined?
>
>
> https://www.w3.org/TR/SVG/paths.html#DAttribute
>
> This is the definition for interpolation and addition of path attributes
> that is used for SMIL.

That doesn't define how addition works. Does the Blink implementation
support addition?

I believe the operation is at least implemented, I'll leave it for Eric to answer if it's wired up though.

Also, the definition in SVG 2 appears to be more thorough so we should
probably refer to that instead:
https://svgwg.org/svg2-draft/paths.html#DProperty

I wonder why we don't normalize the path before trying to match up the
segments? Does the Blink implementation do that?

IIRC, that will give you problems with arcs (A/a).

It seems like the computed value for the 'd' property and
'offset-path' property should be the normalized path (i.e. M, L, C, z
only) or at least have some strict serialization so that "M0,-.5"
becomes "M0,-0.5" etc. What does Blink do for serialization?

No normalization and "%.6g" formatting for numbers I think. Spaces as separators. (I.e "M 0 -0.5" for the above.)

/fs

[Brian Birtles]

On Mon, Mar 6, 2017 at 6:45 PM, Fredrik Söderquist <f...@opera.com> wrote:
> On Mon, Mar 6, 2017 at 2:17 AM, Brian Birtles <bbir...@mozilla.com> wrote:
>> Also, the definition in SVG 2 appears to be more thorough so we should
>> probably refer to that instead:
>> https://svgwg.org/svg2-draft/paths.html#DProperty
>>
>> I wonder why we don't normalize the path before trying to match up the
>> segments? Does the Blink implementation do that?
>
>
> IIRC, that will give you problems with arcs (A/a).

Seems like it would be ok if arcs were included in the normalization?

Even a normalization that simply converts all relative commands to
absolute commands (or vice versa) would seem to make authoring a
little easier both in terms of creating interpolable paths and parsing
the output of getComputedStyle. I don't feel too strongly about it,
however.

>> It seems like the computed value for the 'd' property and
>> 'offset-path' property should be the normalized path (i.e. M, L, C, z
>> only) or at least have some strict serialization so that "M0,-.5"
>> becomes "M0,-0.5" etc. What does Blink do for serialization?
>
>
> No normalization and "%.6g" formatting for numbers I think. Spaces as
> separators. (I.e "M 0 -0.5" for the above.)

That needs to be specified (certainly the separators at least) or
we're going to have a compat issue where content that reads
getComputedStyle only parses the subset of path syntax produced by the
dominant/first-to-ship UA and other UAs need to follow suit or break
content.

Best regards,

Brian

[Fredrik Söderquist]

On Tue, Mar 7, 2017 at 4:49 AM, Brian Birtles <bbir...@mozilla.com> wrote:

On Mon, Mar 6, 2017 at 6:45 PM, Fredrik Söderquist <f...@opera.com> wrote:
> On Mon, Mar 6, 2017 at 2:17 AM, Brian Birtles <bbir...@mozilla.com> wrote:
>> Also, the definition in SVG 2 appears to be more thorough so we should
>> probably refer to that instead:
>> https://svgwg.org/svg2-draft/paths.html#DProperty
>>
>> I wonder why we don't normalize the path before trying to match up the
>> segments? Does the Blink implementation do that?
>
>
> IIRC, that will give you problems with arcs (A/a).

Seems like it would be ok if arcs were included in the normalization?

Yeah, sure. Then it's no longer "normalization" as "described" by [1] or [2] though. (Not that those references actually specify the exact normalization steps - just what segment types could be in the resulting path...)

Even a normalization that simply converts all relative commands to
absolute commands (or vice versa) would seem to make authoring a
little easier both in terms of creating interpolable paths and parsing
the output of getComputedStyle. I don't feel too strongly about it,
however.

Yes, there's certainly lots of possible normal forms one could think of. I don't think "absolutization" would make _parsing_ significantly easier though - handling of the data most certainly though... Authoring-wise I think that relative commands could make a lot of sense in some cases, so imposing any unnecessary restriction on the input would not appear to be helpful. So it seems this is mostly about what amount of leeway a UA should have.

>> It seems like the computed value for the 'd' property and
>> 'offset-path' property should be the normalized path (i.e. M, L, C, z
>> only) or at least have some strict serialization so that "M0,-.5"
>> becomes "M0,-0.5" etc. What does Blink do for serialization?
>
>
> No normalization and "%.6g" formatting for numbers I think. Spaces as
> separators. (I.e "M 0 -0.5" for the above.)

That needs to be specified (certainly the separators at least) or
we're going to have a compat issue where content that reads
getComputedStyle only parses the subset of path syntax produced by the
dominant/first-to-ship UA and other UAs need to follow suit or break
content.

This is left as an exercise for the relevant spec editor =).

/fs

[1] https://www.w3.org/TR/SVG11/paths.html#InterfaceSVGAnimatedPathData 

[2] https://svgwg.org/specs/paths/#InterfaceSVGPathData

[Brian Birtles]

On Tue, Mar 7, 2017 at 6:02 PM, Fredrik Söderquist <f...@opera.com> wrote:
> On Tue, Mar 7, 2017 at 4:49 AM, Brian Birtles <bbir...@mozilla.com> wrote:
>> Even a normalization that simply converts all relative commands to
>> absolute commands (or vice versa) would seem to make authoring a
>> little easier both in terms of creating interpolable paths and parsing
>> the output of getComputedStyle. I don't feel too strongly about it,
>> however.
>
> Yes, there's certainly lots of possible normal forms one could think of. I
> don't think "absolutization" would make _parsing_ significantly easier
> though - handling of the data most certainly though... Authoring-wise I
> think that relative commands could make a lot of sense in some cases, so
> imposing any unnecessary restriction on the input would not appear to be
> helpful. So it seems this is mostly about what amount of leeway a UA should
> have.

The discussion is about computed values (i.e. output) since animation
is performed on computed values.

If the computed value uses only *either* absolute or relative forms,
then an author can animate between:

offset-path: path('M0 100l100-100');

and

offset-path: path('M0 100L100 50');

Without that step, they need to manually convert one to the other.

If the computed value was to be further normalized the author could
animate between:

offset-path: path('M0 100l0-100');

and

offset-path: path('M0 100v-100');

Furthermore, such normalization would mean the author does not need to
parse or process 'v' commands or 'l' commands when reading
getComputedStyle(elem).offsetPath.

But, like I said, I don't feel strongly about this, only that it
deserves discussion before shipping.

>> >> It seems like the computed value for the 'd' property and
>> >> 'offset-path' property should be the normalized path (i.e. M, L, C, z
>> >> only) or at least have some strict serialization so that "M0,-.5"
>> >> becomes "M0,-0.5" etc. What does Blink do for serialization?
>> >
>> >
>> > No normalization and "%.6g" formatting for numbers I think. Spaces as
>> > separators. (I.e "M 0 -0.5" for the above.)
>>
>> That needs to be specified (certainly the separators at least) or
>> we're going to have a compat issue where content that reads
>> getComputedStyle only parses the subset of path syntax produced by the
>> dominant/first-to-ship UA and other UAs need to follow suit or break
>> content.
>
>
> This is left as an exercise for the relevant spec editor =).

Right, but we need to get this speced before we can ship it.

In fact, that spec needs quite a bit more clarification. offset-path
has the syntax:

none | ray( [ <angle> && <size>? && contain? ] ) | <path()> | <url>
| [ <basic-shape> || <geometry-box> ]

But is animatable as "as <angle>, <basic-shape> or <path()>"

How does animation work if you have 'ray(45deg contain)' and
'ray(180deg)'? Does it fall back to discrete animation for the whole
thing, or just for the 'contain' part?


Brian

[Eric Willigers]

In fact, that spec needs quite a bit more clarification. offset-path
has the syntax:

  none | ray( [ <angle> && <size>? && contain? ] ) | <path()> | <url>
| [ <basic-shape> || <geometry-box> ]

But is animatable as "as <angle>, <basic-shape> or <path()>"

How does animation work if you have 'ray(45deg contain)' and
'ray(180deg)'? Does it fall back to discrete animation for the whole
thing, or just for the 'contain' part? 

Discrete animation for the whole thing. Same for offset-rotate animation between 'auto 45deg' and '180deg'.

[Fredrik Söderquist]

Yepp, that's a fair point, but also means you start to veer towards interpolation semantics (which tends to be a discussion with no end...) I.e having a normalization chain like v=>l=>L=>C and so on would offer a lot more flexibility to the interpolation...

 

Furthermore, such normalization would mean the author does not need to
parse or process 'v' commands or 'l' commands when reading
getComputedStyle(elem).offsetPath.

But, like I said, I don't feel strongly about this, only that it
deserves discussion before shipping.

Absolutely.

/fs 

[Eric Willigers]

>> 1. The spec doesn't link to a definition of interpolation/addition for
>> path(). Where is this defined?
>
>
> https://www.w3.org/TR/SVG/paths.html#DAttribute
>
> This is the definition for interpolation and addition of path attributes
> that is used for SMIL.

That doesn't define how addition works. Does the Blink implementation
support addition?

Blink does not currently support addition: the current results show replacement instead. I think addition was implemented behind a flag previously when the Web Animations spec was different (no adding in one keyframe and replacing in another). Blink's addition implementation has changed and path addition needs to be re-implemented.

Addition can be discussed in another thread and need not block shipping.

[Eric Willigers]

Many of the interpolation questions have already been considered by SMIL implementations, where

v and V interpolate.

V and L do not interpolate

SMIL example

Blink's current CSS path interpolation code copies this, and therefore does animate between

   path('M0 100l100-100');

and

   path('M0 100L100 50');

but not between

   path('M0 100l0-100');

and

   path('M0 100v100');

CSS example

Blink's current serialization format can be seen in an interpolation test. Arcs (A/a) do not cause problems.

Interpolating between L and H and V would be trivial to add if there is interest and consensus.

Blink shipped (Intent, SVG minutes)

   d: path('...')

without normalizing ever being discussed, but that presentation attribute could be updated to normalizing if consensus occurs. Normalizing would reduce the space of possible serialization results.

There was a stage in Blink's implementation when CSS Transitions and CSS Animations serialised some of these interpolation cases differently: one using relative when another used absolute. If the spec mandated absolute forms (for example) in the serialization format, such cases would be avoided.

 

[Eric Willigers]

I have created https://github.com/w3c/svgwg/issues/321 for the discussion of path string interpolation options.

I'll update this Intent when there is a decision.

[Eric Willigers]

On Wednesday, May 31, 2017 at 7:59:30 PM UTC+10, Eric Willigers wrote:

I have created https://github.com/w3c/svgwg/issues/321 for the discussion of path string interpolation options.

I'll update this Intent when there is a decision.

From the issue discussion, there has been no preference for relative commands instead of absolute commands. We can clearly serialize to absolute commands.  There is a suggestion that "B" commands be omitted in the normalized form. This isn't immediately relevant as these haven't been implemented, but it is another argument for absolute commands.

There is also interest in much more general interpolation, for example between arcs and splines. However, browser vendor engagement has been limited. I don't think it is worth pursuing this further until we hear from other browser vendors. 

My proposal is that we ship only the conservative path interpolation that SMIL already supports, and that we shipped for the 'd' presentation attribute.

We will serialize to absolute commands (M H V A etc.)

I have submitted web platform tests for interpolation of the other offset properties, and I would add web platform tests for interpolation of offset-path.

 

[Philip Jägenstedt]

That all SGTM, is that to say would you like to revive this intent now?

[Eric Willigers]

Yes, that would be great. 

[Philip Jägenstedt]

I mistakenly thought https://github.com/w3c/svgwg/issues/321 was resolved based on all the commits at the end, but it's still open. If the issue is pretty much settled, is there anything blocking that change being made in the spec? The serialization is something I presume could also be covered by shared tests?

[Eric Willigers]

SMIL's conservative path animation semantics are well understood.

Any animation between a large arc and a single spline would have a large jump in the first frame. I don't want to be inventive without more of the browser vendors actively participating.

Yes, serialization would be covered by web platform tests.

[Philip Jägenstedt]

Great, LGTM2 given that https://github.com/w3c/svgwg/issues/321 is eventually merged and tested.

[Rick Byers]

LGTM3

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYezL-XkHc50qiynxjMD58d-oFvbKF6zQCfJtfAohBXovQ%40mail.gmail.com.