W3C home > Mailing lists > Public > public-fxtf-archive@w3.org > October 2017

Re: [fxtf-drafts] [motion] Blink shipping animation of offset-path path strings

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Thu, 05 Oct 2017 00:00:36 +0000
To: public-fxtf-archive@w3.org
Message-ID: <issue_comment.created-334322738-1507161622-sysbot+gh@w3.org>
The Working Group just discussed `offset-path strings`, and agreed to the following resolutions:

* `RESOLVED: Computed-value normalize case of path commands (to the absolute version).`
* `RESOLVED: Figure out details on normalizing similar commands into more general ones.`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> Topic: offset-path strings<br>
&lt;TabAtkins> GitHub: https://github.com/w3c/fxtf-drafts/issues/225<br>
&lt;florian> Action Florian to propose text to resolve issue 1828<br>
&lt;trackbot> Created ACTION-864 - Propose text to resolve issue 1828 [on Florian Rivoal - due 2017-10-11].<br>
&lt;TabAtkins> ericwilligers: When you animate a path string in SVG using both upper and lowercase commands, there's no way to read it back out. But CSS can do so.<br>
&lt;TabAtkins> ericwilligers: So we have a proposal to normalize the path strings to a canonical representation during animation.<br>
&lt;TabAtkins> ericwilligers: Related: You're not allowed to animate between different commands even if they're very similar, like H (horizontal line) to L (any-direction line).<br>
&lt;TabAtkins> ericwilligers: There was a suggestion that we should allow it.<br>
&lt;TabAtkins> ericwilligers: There was little UA participation of this in SVGWG tho, so bringing it up here.<br>
&lt;TabAtkins> shane: I don't think anybody thinks its a *bad* idea, but just low use-cases for explicit promotion.<br>
&lt;TabAtkins> ericwilligers: So I'd like to ship offset-path and d, and it's more useful if you can animate them.<br>
&lt;TabAtkins> TabAtkins: So three proposals:<br>
&lt;TabAtkins> TabAtkins: 1) animate path(), affecting motion-path and d (this already has a resolution on it)<br>
&lt;TabAtkins> TabAtkins: 2) When animating, normalize abs and rel commands (upper and lowercase) to a single canonical form (uppercase, specifically) so you can animate "h" and "H".<br>
&lt;TabAtkins> TabAtkins: 3) When animating, normalize "families" of similar commands into a single canonical command, so H/V/L all become L, etc, because they're just convenience syntaxes for each other and not significant differences that should stop animation.<br>
&lt;TabAtkins> shane: Animation of path() in SVG is pretty underspecified in SVG2 right now.<br>
&lt;TabAtkins> shane: It says that 2 property values can only be inteprolated smoothly when the paths have the same structure (same number and type of command).<br>
&lt;TabAtkins> shane: "type" isn't really specified - could mean individual commands, or ignoring abs/rel, or in families.<br>
&lt;TabAtkins> shane: It's hard to say what SVG2 *intends* to specify here fo rinterpolation.<br>
&lt;TabAtkins> shane: I think you want normalization to reflect interpolation behavior.<br>
&lt;TabAtkins> shane: If we said today that we wanted path() to animate between two lines, it should promote between any two line types.<br>
&lt;TabAtkins> shane: Eric suggets shipping the de facto SVG behavior now, iterate on it later. I'm a little afraid of being able to change that later.<br>
&lt;TabAtkins> shane: I think the current behavior is poor for authors. If you wanna do any animation you have to fall back on tools, and those tools dont' exist today.<br>
&lt;TabAtkins> dino: I think we need to define an animation between two paths of any type.<br>
&lt;TabAtkins> dino: If what we come up with conflicts with what's about to ship, defined in SVG1, that would be sad, but I don't think it would be a horrible break.<br>
&lt;TabAtkins> dino: In general I think we should give authors a better experience.<br>
&lt;TabAtkins> TabAtkins: I think if we ship current SVG and then upgrade later, it'll just make things start animating, which is a minor break and probably fine.<br>
&lt;TabAtkins> shane: But also would change computed style - we'd want eventually to normalize eagerly in computed style.<br>
&lt;TabAtkins> TabAtkins: Ah, that's more of a change than I thought.<br>
&lt;TabAtkins> fremy: I'd like to have Bogdan around.<br>
&lt;birtles> I think there's precedent for this with `transform` (i.e. we define rules for animating between different types of transforms and we also normalize to matrix() in computed style)<br>
&lt;TabAtkins> shane: One of Bogdan's concerns was no use-cases; we completely disagree. As soon as you try to path-animate, you run into this. It's basically every single use.<br>
&lt;birtles> normalizing in computed style also makes parsing the value a lot easier for authors<br>
&lt;TabAtkins> shane: He also thought it might prevent them from doing certain types of OS acceleration.<br>
&lt;TabAtkins> shane: We've implemented generic path animation before, it's more expensive, but not something we should consider a concern I think.<br>
&lt;birtles> there are a lot of SVG scripts hanging around that only deal with the subset of path commands the author could be bothered to deal with, since there are just too many otherwise<br>
&lt;TabAtkins> TabAtkins: I think B commands are significant - you get different animation behavior whether you animate a B or resolve it away. It seems useful to keep.<br>
&lt;TabAtkins> shane: I do think we shouldn't add or remove commands, just promote to the most general.<br>
&lt;TabAtkins> shane: And then we could maybe have magic for when the number of commands don't match, like transforms do with matrix().<br>
&lt;TabAtkins> shane: We have an impl of that, and it works pretty well.<br>
&lt;TabAtkins> astearns: So should we resolve on the abs/rel normalization today?<br>
&lt;TabAtkins> RESOLVED: Computed-value normalize case of path commands (to the absolute version).<br>
&lt;TabAtkins> astearns: And it sounds like we're interested in normalizing similar commands, but don't yet have consensus on details.<br>
&lt;TabAtkins> shane: Should we open something on the CSSWG tracker?<br>
&lt;TabAtkins> astearns: Yes.<br>
&lt;TabAtkins> astearns: Anyone object to the general idea of normalizing similar commands?<br>
&lt;TabAtkins> RESOLVED: Figure out details on normalizing similar commands into more general ones.<br>

GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/fxtf-drafts/issues/225#issuecomment-334322738 using your GitHub account
Received on Thursday, 5 October 2017 00:00:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:50:21 UTC