- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 17 Sep 2018 20:29:33 +0000
- To: public-svg-issues@w3.org
The SVG Working Group just discussed `Normalizing before serializing paths`. <details><summary>The full IRC log of that discussion</summary> <krit> topic: Normalizing before serializing paths<br> <krit> GitHub: https://github.com/w3c/svgwg/issues/321<br> <krit> AmeliaBR: Eric has posted new web platform tests.<br> <krit> krit: is this about serialization/normalization for CSS or animation or both?<br> <krit> chris: both<br> <krit> AmeliaBR: If you have visual identical paths but with different segements, should they animate together and get normalised upfront.<br> <krit> AmeliaBR: Initial issue was that normalisation only happens for animation<br> <krit> AmeliaBR: Eric suggests that we always normalise for computed style<br> <krit> krit: Does Erik refer to getComputedStlye or used style?<br> <krit> AmeliaBR: I assume the former but we need to ask hmi<br> <krit> AmeliaBR: when you set a value and query it back, did it change? Where did the change happen in the process?<br> <krit> AmeliaBR: the way animation was defined in SVG 1.1 and SMIL, you have to be using the exact same path types.<br> <krit> AmeliaBR: So L and l would not animate together. With Erics change to blink they would get normalised to abs values and then interpolated.<br> <krit> AmeliaBR: this could have unexpected results as well for instance M to m<br> <krit> AmeliaBR: I am not sure this is the best way to go... there might be unintuitive ones.<br> <krit> AmeliaBR: but we need to define when the upgrading should happen and why.<br> <krit> krit: normalisation was defined in SVG 1.2 Tiny as well but was very strict about the types supported in the normalised string. For instance, elliptic segments got normalised to cubics which caused dfifferences between implementations.<br> <krit> chris: I think this is really just about normalisation to absolute type and not reducing segments to other types.<br> <krit> AmeliaBR: my concern is that dealing with relative values and animating additional values you get different results than animation of all points. I need to come up with an example that demonstrates the different visual effects depending on the normalisation.<br> <krit> krit: what is the goal of this issue? To make animations easier for authors or implementations?<br> <krit> AmeliaBR: To make it easier for 2 things that look similar to animate.<br> <krit> krit: I am concerned about "similar paths". Are we discussing 2 paths with totally different segments that look different or still the same type of segment in the same order but differ between rel and abs?<br> <krit> krit: the former needs interpolation algorithms which we should not get into right now.<br> <krit> chris: we are talking about the latter<br> <krit> AmeliaBR: ...and in addition some of the shorthands.<br> <AmeliaBR> https://codepen.io/AmeliaBR/pen/22197a68306ad0d52e35054e408acef0?editors=1000<br> <krit> krit: AmeliaBR do you think you can come up with examples in on of the next meetings?<br> <krit> AmeliaBR: I actually have one.<br> <krit> AmeliaBR: In the example one point is relative and the other absolute. Animating them together you get a different pattern.<br> <krit> AmeliaBR: never mind. This example doesn't show the issue. Will look into it and post on the GitHub issue.<br> <krit> trackbot, end telcon<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/svgwg/issues/321#issuecomment-422159487 using your GitHub account
Received on Monday, 17 September 2018 20:29:35 UTC