Since vector-effect options other than non-scaling-stroke already have multiple implementations, is the "at risk" flag valid?

[satakagi]

Gecko patch: https://bugzilla.mozilla.org/show_bug.cgi?id=1318208
Polyfill: http://svg2.mbsrv.net/devinfo/devstd/non-scaling-objects-2/VectorEffect_polyfill_wScreen.html

[jarek-foksa]

AFAIK non-scaling-stroke and none are the only values that have multiple implementations if we don't count the polyfill, thus the "at risk" flag for other values seems to be justified.

[nikosandronikos]

FWIW we were told that a polyfill is a valid implementation.

[svgeesus]

Yes, a polyfill is a valid implementation for the purpose of of CR exit criteria.

[tabatkins]

Tho, for web tech, polyfills aren't useful guarantors of quality/stability without additional assurances from browsers.

[boggydigital]

We'll keep this at risk for SVG 2.0 updated CR publication based on the discussion in this thread and will clarify the final standing when we get closer to 2.0 Recommendation - setting that milestone.

[Tavmjong]

@satakagi Do you have tests? If so, they should be submitted to WPT.

[JonFerraiolo]

My opinion: drop the feature entirely, or at least drop everything but non scaling stroke. Lighten the burden on user agents, authoring tools, converters, book authors, students, and the WG itself. Keep it simple.

Note that I have had a requirement for a non scaling stroke with SVG1 and found that I could achieve the desired result if I simply changed the coordinates of the vectors rather than change the transformation matrix. It usually wasn't much extra work. You get an event and you change something in the graphic. Can just as easily change coordinates as matrices.

[satakagi]

@Tavmjong
This is a test involving polyfill for that.
http://svgmap.org/devinfo/devstd/non-scaling-objects-2/VectorEffect_polyfill_noTf.html

And static test contents and its screen captures.
http://svgmap.org/devinfo/devstd/non-scaling-objects-2/tests/

However, they may not meet the requirements of WPT, so would it be necessary to refurbish?

[satakagi]

Made pull req. for tests
web-platform-tests/wpt#13302

[dirkschulze]

We have implementations in Firefox, WebKit and Blink (Latter 2 counting as one implementation as implementation happened before fork.) That should fulfill requirements already but didn’t test Edge yet.

[dirkschulze]

We have the other property values in the SVG 2.1 implementation. I suggest moving the other properties out of SVG 2.0.

[css-meeting-bot]

The SVG Working Group just discussed vector-effects at-risk status, and agreed to the following:

• RESOLVED: Remove "at-risk" flag for vector-effects in SVG 2.

The full IRC log of that discussion

<AmeliaBR> Topic: vector-effects at-risk status
<AmeliaBR> github: https://github.com//issues/306
<AmeliaBR> Dirk: The spec has many other values for vector-effects, which were marked at risk because of lack of implementations.
<AmeliaBR> ... We now have a browser implementation (Firefox), plus also JavaScript implementations.
<AmeliaBR> Tav: And these are independent?
<AmeliaBR> Dirk: Yes.
<AmeliaBR> Tav: I'm also planning to work on an implementation in Inkscape.
<AmeliaBR> Eric: Are there tests merged into WPT, or is this specifically the PR that is currently open?
<AmeliaBR> Tav: I suspect those are the tests we're talking about.
<AmeliaBR> Amelia: Might be merged tests for non-scaling-stroke.
<ericwilligers> vector-effects tests that need review: https://github.com/web-platform-tests/wpt/pull/13302
<AmeliaBR> Dirk: You'll want to check with the Firefox people, since they would have made some for their implementation.
<AmeliaBR> Dirk: So, question is: can we remove the "at risk" flag.
<AmeliaBR> Tav: We had previously agreed that JS implementations do count for PR status.
<AmeliaBR> Amelia: Is there any harm in keeping it at-risk for now? Does that prevent going to PR status?
<AmeliaBR> Eric: Has anyone looked at the polyfill? Is it high quality for production sites?
<AmeliaBR> Dirk: There's a link on the issue (#306). I haven't looked at it carefully.
<AmeliaBR> Eric: It looks good at a glance. I think we can count it as an implementation.
<AmeliaBR> Amelia: Still need to do full testing.
<AmeliaBR> Dirk: But that's true for many features.
<AmeliaBR> RESOLVED: Remove "at-risk" flag for vector-effects in SVG 2.

[longsonr]

We have implementations in Firefox, WebKit and Blink (Latter 2 counting as one implementation as implementation happened before fork.) That should fulfill requirements already but didn’t test Edge yet.

The Firefox bug contains code that has not landed in any branch, it may no longer apply and it certainly hasn't been reviewed or tested. That surely doesn't count as an implementation does it?

[dirkschulze]

@longsonr No, it doesn't. Was my misunderstanding then. Are there plans to review/land it?

[longsonr]

There are no plans to review it or land it without commitment from other vendors.

[Tavmjong]

@satakagi I've implemented the rest of the vector effects in Inkscape (less than 20 lines of code!) but I'm not sure about one thing. In your polyfill, checking the 'non-scaling-size' or the 'non-rotation' box causes the dotted shapes to move to the corresponding solid shape. Is this really correct? I would not expect the translations to be removed on the dotted shapes when one of these vector effect values is used.

[satakagi]

@dirkschulze Please tell me the criteria of counting as an implementation. The implementation on the forked gecko was made certainly as in the above patch, but it has not landed on the main stream. As discussed in bugzilla, it will not enter the mainstream unless other vendors adopt it.

[dirkschulze]

@satakagi There must be 2 independent implementations. The implementation must be accessible and testable. The SVG WG has the additional requirement that at least one of the 2 implementations must be in one of the major browser (Firefox, Safari, Chrome, Edge) and must at least ship in a preview version with the feature accessible by anyone. (Could be disabled by default but must be able to be enabled for testing.)

[satakagi]

@dirkschulze In the context of svgwg, the forked gecko implementation does not satisfy the requirements of svgwg. By the way, where is the requirement stated?
Well, I remember that this specification was created based on the task of listing requirements for SVG 2 when most browser vendors participated, but unfortunately the current browser vendor's The situation seems to have changed.
As you can see from the discussion in bugzilla, this seems to be falling into a chicken or egg dilemma.
This situation does not seem to change as long as multiple implementations with polyfill or authoring tool do not meet the requirements.
At least we feel that contributing by native implementation to browsers is no longer difficult.

[dirkschulze]

@satakagi Lets discuss the details in the next WG call. I'll find previous resolutions for that meeting.

[css-meeting-bot]

The SVG Working Group just discussed Implementation interest for vector-effects, and agreed to the following:

• RESOLVED: Hold off on removing "at-risk" note re vector-effects

The full IRC log of that discussion

<AmeliaBR> Topic: Implementation interest for vector-effects
<AmeliaBR> github: https://github.com//issues/306
<AmeliaBR> Dirk: Last month, we decided to remove the at-risk flag, but a question was raised about what counts as an implementation
<AmeliaBR> ... there is a test implementation in Firefox, but it has not landed in master and they're not currently going to review or land it until there is stated implementer interest in other browsers.
<AmeliaBR> ... Myles, Eric, any knowledge of whether there is interest in WebKit or Blink?
<AmeliaBR> Eric: Is this something that's requested by authors?
<AmeliaBR> Chris: It is something that is liked by authors & was originally proposed based on author feedback.
<AmeliaBR> ... Would be better to more document those use cases. What do you really need?
<AmeliaBR> Eric: We don't have strong opinions. I discussed with Frederick, he asked whether there was author demand.
<AmeliaBR> Amelia: I think there's not strong author feedback because there aren't any existing implementations for authors to play with. Getting the polyfill polished and out in the wild might help provoke interest.
<AmeliaBR> Myles: I don't see any work in WebKit. We only get comments about non-scaling-stroke. But we would look at it if there were other implementations.
<AmeliaBR> Dirk: So, it sounds like everyone is waiting on everyone else. But at least, no one objects to it.
<AmeliaBR> Chris: Have people tested the Firefox implementation?
<AmeliaBR> Dirk: Well, right now it's just a patch. You'd need to download and compile it yourself before testing.
<AmeliaBR> Amelia: So, for the spec: don't remove anything, but also don't remove the at-risk flag yet?
<AmeliaBR> Dirk: I think so. But also we should file issues on browsers.
<AmeliaBR> Chris: Yes, and user voice polls and such so authors can mark support.
<AmeliaBR> RESOLVED: Hold off on removing "at-risk" note re vector-effects
<AmeliaBR> Dirk: I'll also follow up with the issues.
<AmeliaBR> Amelia: I'd suggest that if anyone want to take another look at Satoru's polyfill, to see if there's anything that's needed to get it ready for real-world use. That would help get author interest.
<AmeliaBR> Tav: I've also looked at implementing for Inkscape, although it is less useful for us.
<AmeliaBR> s/I've also looked at implementing/I've implemented/

[dirkschulze]

We heard positive feedback from Chrome and WebKit giving the same statement as @longsonr. If other implementations implement they'll follow. Let's wait a little bit longer and we may not need to decide if a published patch counts as implementation.