Re: [svgwg] Serialization format for path strings

Okay, I'm going to retract my concerned musings from the call.

I was worried that there were cases where animating between numbers in a relative path string would have different effects than animating between their normalized form (similar to how, with CSS transforms, animating between two rotate parameters is different from animating their matrix representations).

But now that I've worked through it more carefully, I realize that isn't an issue. It's an issue with transforms because they are using non-linear transformations (trigonometric conversions between the angle parameters and the matrix parameters). But since all the normalization we're talking about here can be decomposed into series of additions, I'm pretty sure that everything works out the same (haven't done any mathematical proofs, mind you). 

But what I _would_ like to see is the normalization rules written out as a PR to the Paths chapter of the spec (since that seems to be the only place that defines interpolation of path strings).

Then the question is whether normalization should only happen as an "upgrade if necessary" for animation, or if it should be part of the computed value process, or if it should be part of the serialized value process. @ewilligers, can you explain how you think it should work, based on the recent WPT tests you've added?

As an author who has been known to hand-code her path strings, I'm slightly uncomfortable with the idea that the original path data just disappears in the CSS OM, so that you get the normalized version back in any serialized form. If I'm using relative notation, I'm using it for a reason.

-- 
GitHub Notification of comment by AmeliaBR
Please view or discuss this issue at https://github.com/w3c/svgwg/issues/321#issuecomment-422182789 using your GitHub account

Received on Monday, 17 September 2018 21:47:10 UTC