Serialization format for path strings

[ewilligers]

This issue came up in an Intent to Ship (offset-path animation) discussion on blink-dev.
https://groups.google.com/a/chromium.org/d/msg/blink-dev/_DPl-JG6bV8/y2_GUwFVDwAJ

'd' path strings can contain a mix of absolute and relative coordinates, and a mix of comma and
space separators. https://www.w3.org/TR/SVG2/paths.html#TheDProperty

It is also possible to animate between paths that differ in the use of separators and absolute and
relative coordinates, for example between 'M 200 400 H 500 v -100' and 'm100,200h400V300'.

Now that 'd' is exposed as a presentation attribute, page authors can use getComputedStyle to
inspect the path string.

For consistency between implementations, it would be helpful if the standard specified absolute
[or relative] coordinates in the serialization format, and space separators.

The above example path strings would become 'M 200 400 H 500 V 300' and 'M 100 200 H 500 V300'
when serialized.

Blink's currently shipping implementation uses space separators, and uses the 'to' format for
absolute/relative coordinates, except at animation progress 0, where the 'from' format is used:-
property from [path('M 200 400 H 500 v -100')] to [path('m100,200h400V300')]
at (0) is [path('M 200 400 H 500 v -100')]
at (0.5) is [path('m 150 300 h 350 V 300')]
at (1) is [path('m 100 200 h 400 V 300')]

If we specify absolute coordinates for the serialization format, these would become:
property from [path('M 200 400 H 500 v -100')] to [path('m100,200h400V300')]
at (0) is [path('M 200 400 H 500 V 300')]
at (0.5) is [path('M 150 300 H 500 V 300')]
at (1) is [path('M 100 200 H 500 V 300')]

If we specify relative coordinates for the serialization format, these would become:
property from [path('M 200 400 H 500 v -100')] to [path('m100,200h400V300')]
at (0) is [path('m 200 400 h 300 v -100')]
at (0.5) is [path('m 150 300 h 350 v 0')]
at (1) is [path('m 100 200 h 400 v 100')]

No backward compatibility issues are anticipated in moving to consistent absolute coordinates [or consistent relative coordinates].

If issue #320 is accepted, there is also the choice of quote character around the path string. Blink uses single quotes.

[ewilligers]

There was an additional suggestion from Brian Birtles
https://groups.google.com/a/chromium.org/d/msg/blink-dev/_DPl-JG6bV8/bdRsDsS5EQAJ

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.

All H and V commands would be normalized to L in the serialization format,
and CSS Animations could animate between them. However, this would
introduce divergence between SMIL animation and CSS animation.

[AmeliaBR]

The reason that the path syntaxes (with and without path() function notation) use strings is because implementations did not want to have to parse path data with the CSS parser. Given that the path data is just a string to the parser, it seems a bit strange to normalize it for getComputedStyle. Are there any other examples of normalization of string values during serialization (e.g., in font-family)? You might need to run this by the CSS folks to make sure that's ok.

That said:

I like the idea of being able to access normalized path data for path() functions used in CSS, not only for entire elements. getComputedStyle seems an appropriate means of doing that normalization. I suppose we could define a new data type <path-string> which is equal to a string for parsing but which is internally parsed and normalized when returning computed styles.

As you say, using normalized paths for computed styles would increase the flexibility of path interpolation considerably. It wouldn't be that much of a stretch to go one step farther and allow interpolation to/from the other shape functions, by converting them to equivalent paths.

There is an existing standard for what a "normalized" path string looks like: the normalizedPathSegList getter from SVG 1.1 (removed from SVG 2 along with all the other PathSeg DOM), which is re-created as the normalize option in the getPathData() method in the SVG Paths module.

The big limitation of that standard is that the normalized path notation doesn't include true arcs, and instead recommends they get converted into straight lines! I'd definitely not want to see that re-created in any new spec. (If you have to normalize arcs to another segment type, at least use cubic beziers!)

[ewilligers]

Given that the path data is just a string to the parser, it seems a bit strange to normalize it for getComputedStyle.

When we are animating, we have to choose a format. It is reasonable for the format to be specified by the standard.

The normalizedPathSegList normalization

if normalize is set to true then the returned sequence of path segments is converted to the base set of absolute commands ('M', 'L', 'C' and 'Z'), with the values adjusted accordingly.

gives a precedent for normalizing to absolute instead of relative coordinates.

I agree with Amelia's preference against normalising arcs to straight lines.

A new normalization proposal is required, perhaps the following:-

All relative commands are normalized to the equivalent absolute commands.

When animating paths using CSS, interpolation is possible provided the paths have the same number of commands, and the corresponding path segments have the same types and numbers of arguments after any necessary promotion.

Given current point (cx, cy), we define promotions
H/V -> L -> Q -> C
as follows:

H x -> L x cy
V x -> L cx y
L x y -> Q (cx + x)/2 (cy + y)/2 x y
Q (x1 y1 x y)+ -> C (x1 y1 x1 y1 x y)+

Thus H, V and Q can appear in getComputedStyle results, but animation from H to V would result in L, and animation from V to C would result in C.

[BigBadaboom]

Do we need a promotion to Q, given that we are normalising to 'M', 'L', 'C' and 'Z'?

So all that's needed is the following, correct?

H x -> L x cy
V x -> L cx y
Q (x1 y1 x y)+ -> C (cx + (2/3)(x1-cx), cy + (2/3)(y1-cy), x + (2/3)(x1-x), y + (2/3)(y1-y), x y)+
A -> C (?)

Also, there is probably a need to briefly address the handling of the new 'B' (bearing) command also, isn't there? I.e. that it affects the following commands, but drops from the normalisation.

Regarding Arcs. If they are going to be normalised to cubic beziers for animation, then I believe some additional info is going to need to be added to the centre<->endpoint parameterization section. There is current;y no advice supplied on how to position the bezier curves.

[tabatkins]

The reason that the path syntaxes (with and without path() function notation) use strings is because implementations did not want to have to parse path data with the CSS parser.

Rather, we can't parse path data with the CSS parser; it's written in a way that is wholly incompatible with the CSS tokenizer, and would require heroic efforts to reverse the obtained tokens back into reasonable path commands. (If it's even possible at all; without a thorough review, I'm not willing to say that some cases aren't impossible to recover.) Thus you have to pass it thru the CSS parser as a string, and then do special-case parsing at the impl level.

This doesn't mean it's a "string" in a semantic sense; it doesn't contain arbitrary opaque data. It's very much transparent, and contains meaningful structured data! As such, the computed value of a path() is definitely a segment list (probably normalized to some degree).

Do we need a promotion to Q

While not strictly necessary, doing so means that animating an L to a Q will output a Q, rather than going all the way to a C.

A -> C (?)

You can't convert an arc to a cubic bezier in general. (You can get very close, but it's impossible to get a correct perfect equivalence.) Maybe it's worthwhile to try, tho? If people can animate between arcs and lines (yes), and they can animate between lines and curves (yes), I presume they'd want to be able to animate between arcs and curves. Doing so, tho, would mean we've have to downgrade the arc into one or more curves, which then becomes tricky to animate (subdivide the curve it's animating against into the same number of subcurves? where do place the cuts?). It's a difficult problem with some tradeoffs.

Also, there is probably a need to briefly address the handling of the new 'B' (bearing) command also, isn't there? I.e. that it affects the following commands, but drops from the normalisation.

That's not necessarily obvious. Animating a B 0 h 10 to a B 90 h 10 looks different depending on whether you elide the Bs (resulting in a normalized L 10 0 and L 0 10, I think?) or don't; the former moves the endpoint in a straight diagonal line, while the latter moves it in a circular arc.

B might be similar to a rotate() in a transform list - it could be interpreted as just rewriting the rest of the transform list, but it's typically used semantically, such that you want to preserve and animate it as a rotation.

[ewilligers]

The graphic at https://pomax.github.io/bezierinfo/#circles_cubic illustrates that a single cubic Bezier is a reasonable approximation for small arcs, but terrible for large arcs (e.g. 300 degrees).

So any animation between an arc and a spline would have a large jump in the first frame, defeating the usual purposes of animation.

One way to avoid that would be to represent large arcs by a sequence of splines, but in that case we should allow animation between paths that contain different numbers of commands. This would be useful, but it is also a large departure from SMIL path interpolation.

[tabatkins]

Right, I think in general you shouldn't approximate more than 90deg of arc with a cubic bezier. This is a hard problem, as you note, due to it opening up general multi-segment interpolation.

[AmeliaBR]

I would prefer if "normalization" only included lossless changes: making coordinates absolute, converting smooth connections into explicit control points, upgrading H/V to L, and maybe Q to C. Leave arcs as arcs. They're still not great for interpolation, but at least you'd be re-creating the SMIL behavior.

[boggydigital]

Not blocking updated 2.0 CR publication - assigning 2.1 WD milestone

[birtles]

@ewilligers We're implementing this in Gecko now and apparently Blink currently does normalization at animation time, not computed value time. That is, in the absence of animation the result from getComputedStyle doesn't have the commands converted to absolute equivalents. I think we agreed that it should. Is that right?

It seems like always returning absolute commands would make life easier for authors since they only need to parse the absolute commands. If that's right, is someone able to update Blink to normalize at computed value time?

[BorisChiou]

By the way, about this issue:

If issue #320 is accepted, there is also the choice of quote character around the path string. Blink uses single quotes.

Gecko uses double quotes because CSS object model [1] says to use double-quotes.

[1] https://drafts.csswg.org/cssom/#serialize-a-string

cc @emilio

[tabatkins]

Yeah, CSS things all use double quotes; we should consistently be doing this.

[ewilligers]

Yes, getComputedStyle should be returning absolute commands. I can also change Blink to double quotes.

[BorisChiou]

Cool. Thanks, Eric. I will change Gecko to normalize the path string at computed time (Bug 1489392).

[ewilligers]

Yes, getComputedStyle should be returning absolute commands

Actually, I suspect we will normalize earlier, specified value will also show absolute commands. I'm not sure Blink's CSS implementation of paths will be able to easily distinguish the two. Proposed Blink CL

[emilio]

I think that's acceptable, it saves us having to have two different representations for the path...

[BorisChiou]

If I understand correctly Chrome currently does 3.

It seems the recent update of Chrome keeps the original path segment data, and normalize it for animations or calling getComputedStyle (serialization) [1], I guess. @ericwilligers?

[1] https://chromium-review.googlesource.com/c/chromium/src/+/1215150

[birtles]

I'm not really keen on 3. There is currently no concept of "when needed" and it introduces a lot of complexity.

For example, is normalization needed when you have a timing function of step-end? Is it needed when you sample at exactly one of the keyframe offsets? Is it needed when you are filling? Is it needed when a path is combined with another value that makes the whole value fall back to 50% flip behavior? Different engines have different answers to these questions.

In order to implement any answer to the above we will need to add special case code that feels to me like a layering violation (e.g. passing flags around to say, "Are we in an animation path in a particular animation state where we need to return a normalized value").

Furthermore, from an authoring point of view having getComputedStyle return absolute paths for some set of the above situations, but not others is surprising and seems to violate the idea of avoiding discontinuities.

My experience is that adding complexity to interpolation code almost always creates more work over time (particularly as the set or permutations continues to grow) and should be done at computed value time if possible. This is particularly so as we try to extend this behavior through additive CSS, additive animations, collapsing forwards-filling animations etc.

[AmeliaBR]

Per your comment above, looks like the behavior that would break D3 is either 1 or 2, and what you want is 3, right?

Yes, I'm fine with spec'ing the Chrome 69 behavior.

There is currently no concept of "when needed" and it introduces a lot of complexity.

I don't see how this different is from any other data format that converts values to support transitions. E.g., transitioning from transform: rotate(1turn) to transform: scale(2), you transition via a matrix transform. To transition from width: 100% to width: 10px you transition via a calc() expression. So the answers re step timing functions and values at exact keyframe points would be "do whatever you do in those cases".

My experience is that adding complexity to interpolation code almost always creates more work over time

Well, that much may be true…

---

A final option is just stick with the SVG 1 path animation rules (for now, anyway), and don't change any segment types to facilitate animations.

[ewilligers]

If I understand correctly Chrome currently does 3.

It seems the recent update of Chrome keeps the original path segment data, and normalize it for animations or calling getComputedStyle (serialization) [1], I guess. @ericwilligers?

[1] https://chromium-review.googlesource.com/c/chromium/src/+/1215150

Correct.

A final option is just stick with the SVG 1 path animation rules (for now, anyway), and don't change any segment types to facilitate animations.

SMIL implementations allowed animation between absolute and relative commands.

[AmeliaBR]

SMIL implementations allowed animation between absolute and relative commands.

Well, that's interesting. That's not how I read the SVG 1.1 spec:

Path data animation is only possible when each path data specification within an animation specification has exactly the same list of path data commands as the ‘d’ attribute.

But I tested, and it works in Safari, Chrome and Firefox. Other devs must have had more generous interpretations of "exactly the same" than I did.

PS, The current spec text isn't much clearer on that point, so whatever gets resolved here, it should be clarified.

[birtles]

There is currently no concept of "when needed" and it introduces a lot of complexity.

I don't see how this different is from any other data format that converts values to support transitions. E.g., transitioning from transform: rotate(1turn) to transform: scale(2), you transition via a matrix transform. To transition from width: 100% to width: 10px you transition via a calc() expression. So the answers re step timing functions and values at exact keyframe points would be "do whatever you do in those cases".

The transform example is difficult because computed transform lists are always serialized as matrix() so the "when needed" behavior isn't observable and doesn't give us any precedent (e.g. we can't tell if the value corresponding to scale(2) returned from getComputedStyle during an animation's forwards fill phase is being converted to a matrix() due to it still being treated as an animated value, or simply due to the serialization behavior).

Similarly for width since the result is always a pixel value there (due to getComputedStyle returning the used value with width).

For properties that actually do return calc() from getComputedStyle such as background-position the notion of "when needed" isn't particularly consistent.

For example, if you try this pen: https://codepen.io/birtles/pen/BObNXd

In Firefox you'll get results like:

Calc used with step timing function? false
Calc used when sampling exactly at keyframe? true
Calc used when filling forwards? false
Calc used when filling backwards? true
Calc used when using keywords? false

In Chrome you'll get false everywhere (i.e. (2) from above, which I'm pretty sure is wrong per-spec).

I'm concerned about saying "do whatever you do in those cases" since even if we take that to mean "do whatever you do for background-position" it's different between engines (and inconsistent even within the one engine). Furthermore, I'm not even sure what behavior we would want to specify for each of the different cases.

[birtles]

If it seems like I'm being pedantic here, part of the background is that implementations will have the computed values as derived from @keyframes etc. and then as part of their animation computation might notice, "Oh, actually I don't need to interpolate this after all" (e.g. because they recognize the step timing function etc.) and instead just return one of the interpolation end points as-is.

With approach (3) that kind of optimization will be observable so we need to spec when it is allowed/required. With approach (1) or (2) we don't need to.

[svgeesus]

This issue has become slightly complicated in terms of spec interactions, compared to when the issue was opened. It now affects the slimmed-down SVG 2 Paths chapter, and also requires changes to parts of the split-out Paths module (or perhaps backporting the normalize operation from paths module to Paths chapter, if anyone implements that), and also affects the animation part of MotionPath.

[tigt]

As an author, I would trade the ability to interpolate between paths with different-but-similar path segments in exchange for consistency when inspecting the value in devtools, script in the console, etc. The convenience of passing in a looser range of values (that are probably coming from a tool, at least for me) doesn't seem to outweigh the potential debugging headaches.

I personally would like to see the path data absolutized at the 1 or 2 points in @emilio's choices — it seems more consistent with having my authored values normalized for other data types (which may be wrong, but that's my impression from living in devtools and having stuff like color values normalized).

[BorisChiou]

It seems like there is no conclusion for now, so I update the WPT to accept both normalized path string and non-normalized path string at computed time, in https://bugzilla.mozilla.org/show_bug.cgi?id=1489392.