Re: [svgwg] Support pathLength via CSS (#773)

The SVG Working Group just discussed `Support pathLength via CSS`.

<details><summary>The full IRC log of that discussion</summary>
&lt;AmeliaBR> Topic: Support pathLength via CSS<br>
&lt;AmeliaBR> github: https://github.com/w3c/svgwg/issues/773<br>
&lt;krit__> ScribeNick: AmeliaBR<br>
&lt;AmeliaBR> Amelia: Been some blogs &amp; twitter discussion about how pathLength is helpful for stroke effects. But that raised question of why it needs to be an attribute when stroke styles AND geometry are now in CSS.<br>
&lt;AmeliaBR> ... proposal is to make a path-length geometry property.<br>
&lt;AmeliaBR> ... I think it's a good idea. But not sure about adding it to SVG 2. No implementations yet. Is it a priority?<br>
&lt;AmeliaBR> krit: Looks some interest from at least one implementer.<br>
&lt;AmeliaBR> Amelia: Yes, fsoder said he could do the work in Blink. But needs others.<br>
&lt;AmeliaBR> nzimmermann: WebKit doesn't yet do anything with the attribute. It just parses it, doesn't affect rendering. So that still needs to happen. But adding it as a CSS property doesn't seem to make it any more complicated.<br>
&lt;AmeliaBR> Amelia: And might even be easier to do both changes at the same time?<br>
&lt;AmeliaBR> Tav: We (Inkscape) don't appear to implement it (for stroke dashing). But for us, properties and attributes are treated very similarly. Wouldn't make much extra work.<br>
&lt;AmeliaBR> Amelia: So it sounds like first step is get some tests of what pathLength (as attribute) is supposed to do, re stroke dashing and such.<br>
&lt;AmeliaBR> ... Then we can get some feedback on how hard it is to implement.<br>
&lt;AmeliaBR> ... The benefit of adding to CSS depends on it actually affecting rendering!<br>
&lt;AmeliaBR> krit: There is one test. It uses animations.<br>
&lt;AmeliaBR> Amelia: That was the only part explicit in SVG 1. Stroking effect wasn't well defined; that was added in SVG 2.<br>
&lt;AmeliaBR> nzimmermann: One concern is that anything to do with pathLength is very complicated. In WebKit, this is all in the platform-specific underlying code. You tell the backend the path &amp; the stroke pattern.<br>
&lt;AmeliaBR> krit: What you'd need to add is scaling of the stroke pattern.<br>
&lt;AmeliaBR> nzimmermann: Yes, but then you need to ask the backend to calculate a path length. Which isn't trivial.<br>
&lt;AmeliaBR> Amelia: I mean, the purpose of pathLength was to adjust for these underlying differences in path length calculation. But then you do need some back-and-forth between the two code levels.<br>
&lt;AmeliaBR> krit: Original intention was specifically for things like textPath and animation where it is really important to be consistent.<br>
&lt;AmeliaBR> nzimmermann: And for those cases, we already calculate path length on our own, so it's easier to scale. But with stroking we defer to the backend.<br>
&lt;AmeliaBR> ... I'm not sure it's technically possible to get the exact length the underlying code is using for the stroking.<br>
&lt;AmeliaBR> Tav: Is that a big difference?<br>
&lt;AmeliaBR> krit: Maybe, but point is to get rid of that difference, so we need to know it.<br>
&lt;AmeliaBR> Tav: But other use case is just ease for author. To explicitly set length of 100 and then work with that, without having to measure anything.<br>
&lt;AmeliaBR> [more discussions on underlying libraries]<br>
&lt;AmeliaBR> krit: So first thing is to write tests to know if it is implemented at all.<br>
&lt;AmeliaBR> Amelia: Or, implemented consistently in the details.<br>
&lt;AmeliaBR> Tav: And performantly.<br>
&lt;AmeliaBR> krit: We also need buy-in from CSS working group, since this would be a new property.<br>
&lt;AmeliaBR> ... let's ask TabAtkins to bring it up at CSS WG F2F<br>
&lt;AmeliaBR> krit: And for the performance criteria, does that really affect whether it should be in CSS? Or whether it should be there at all?<br>
&lt;AmeliaBR> Amelia: It's not related to CSS. It's whether pathLength should affect stroking that is performance issue.<br>
&lt;AmeliaBR> ... but if we take that out, not much point to add to CSS.<br>
&lt;AmeliaBR> ... Beyond that, only question is can anyone write up some tests?<br>
&lt;AmeliaBR> krit: And writing good tests, considering the subtle differences between implementations.<br>
&lt;AmeliaBR> Amelia: I don't think we need to specifically test *for* those differences. But need to be careful they're not ruining results with pixel differences.<br>
&lt;AmeliaBR> Tav: I can try to write some up.<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/svgwg/issues/773#issuecomment-574846768 using your GitHub account

Received on Wednesday, 15 January 2020 20:40:54 UTC