Intent to Deprecate and Remove: SVGPathSeg interfaces

[Fredrik Söderquist]

Primary eng (and PM) emails

f...@opera.com

Summary

The SVGPathSeg interface [1][2] was used to individually manipulate a path’s components. One use case was to modify any given component (e.g., a cubic arc command in the center of a path) without explicitly re-creating the path from a string.

[1] http://www.w3.org/TR/SVG11/single-page.html#paths-InterfaceSVGPathSeg

[2] http://www.w3.org/TR/SVG11/paths.html#InterfaceSVGPathElement

Motivation

This interface was difficult to use and has been removed from the SVG spec in favor of a new, awesomer API in the Paths module (https://lists.w3.org/Archives/Public/www-svg/2015Jun/0044.html).

Compatibility Risk

Low, this feature is relatively obscure and didn’t gain much usage so the SVG WG decided it was best to remove it before usage grows. This feature has been in Chrome for a long time and is implemented in all browsers.

Usage information from UseCounter

https://www.chromestatus.com/metrics/feature/timeline/popularity/568 (around 0.001%)

OWP launch tracking bug

This feature is fairly obscure so it is felt that we don’t need an official launch tracking bug. The actual removal is being tracked at http://crbug.com/539385.

Entry on the feature dashboard

https://www.chromestatus.com/features/5708851034718208

Requesting approval to remove too?
Yes.

[Philip Jägenstedt]

LGTM1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Dimitri Glazkov]

LGTM2.

[TAMURA, Kent]

LGTM3

--

TAMURA Kent
Software Engineer, Google

[rms]

Hello Fredrik,

At my company we use the `pathSegList` to iterate the commands of SVG PathElements - it is very convenient.  Can you please confirm for me that after your removal the only way to access this information in Chrome will be for us to parse the `d` attribute ourselves?

Thank you,

[Fredrik Söderquist]

On Tue, Oct 20, 2015 at 2:44 PM, rms <r...@rossis.red> wrote:

Hello Fredrik,

At my company we use the `pathSegList` to iterate the commands of SVG PathElements - it is very convenient.  Can you please confirm for me that after your removal the only way to access this information in Chrome will be for us to parse the `d` attribute ourselves?

Until the new API [1] matures and is implemented - yes that is correct.

/fs

[1] https://svgwg.org/specs/paths/#DOMInterfaces

[seb....@gmail.com]

Svg-Edit is now broken.
https://github.com/SVG-Edit/svgedit

Is there a relatively pain free way to get it back working. The lies a simple grep for "SVGPathSeg" gave me look like these:

svg-edit-2.6/path.js:283: var func = 'createSVGPathSeg' + pathFuncs[type];
svg-edit-2.6/path.js:659: newseg = this.elem.createSVGPathSegLinetoAbs(new_x, new_y);
svg-edit-2.6/path.js:675: newseg = this.elem.createSVGPathSegCurvetoCubicAbs(new_x,new_y, p0_x,p0_y, p01_x,p01_y);
svg-edit-2.6/extensions/ext-closepath.js:40: seglist.appendItem(path.createSVGPathSegClosePath());
svg-edit-2.6/browser.js:56: var seg = path.createSVGPathSegLinetoAbs(5,5);
svg-edit-2.6/browser.js:68: var seg = path.createSVGPathSegLinetoAbs(5,5);
svg-edit-2.6/svgcanvas.js:4141: var newseg = drawn_path.createSVGPathSegLinetoAbs(abs_x, abs_y);
svg-edit-2.6/svgcanvas.js:4143: var newseg = drawn_path.createSVGPathSegCurvetoCubicAbs(
svg-edit-2.6/svgcanvas.js:4153: var endseg = drawn_path.createSVGPathSegClosePath();
svg-edit-2.6/svgcanvas.js:4203: var newseg = drawn_path.createSVGPathSegLinetoAbs(round(x), round(y));
svg-edit-2.6/svgcanvas.js:4205: var newseg = drawn_path.createSVGPathSegCurvetoCubicAbs(
svg-edit-2.6/svgcanvas.js:4657: var newseg = elem.createSVGPathSegLinetoAbs(start_item.x, start_item.y);
svg-edit-2.6/svgcanvas.js:4659: var closer = elem.createSVGPathSegClosePath();
svg-edit-2.6/svgcanvas.js:4840: var newseg = elem.createSVGPathSegLinetoAbs(last_m.x, last_m.y);
svg-edit-2.6/svgcanvas.js:7548:// See http://www.w3.org/TR/SVG/paths.html#InterfaceSVGPathSeg for list

IOW, what is the suggested replacement API for these functions ?

Regards,
Sebastian

[jarek...@gmail.com]

@Sebastian SVG 2 introduces SVGPathElement.prototype.getPathData() and SVGPathElement.prototype.setPathData(pathData) methods which are more convenient that the verbose pathSegList API. The problem is that the new API is not implemented by any browser and it's hard to shim (in order to parse "d" attribute reliably you need a full-blown parser). 

Check following links to learn more:

- https://svgwg.org/specs/paths/#DOMInterfaces

- https://lists.w3.org/Archives/Public/www-svg/2015Feb/0036.html

- https://code.google.com/p/chromium/issues/detail?id=545467

It bothers me that this important (although rarely used) API has been removed without any prior deprecation warnings and without any simple migration path.

[Rick Byers]

It sounds like there's some non-trivial developer pain here.  In general I don't think we should be removing useful functionality from the platform that is being used by a non-trivial number of developers before the replacement is ready (especially when that functionality has been shipping for a long time).  As we've seen elsewhere, absolute usage isn't the only metric that matters for preserving developer confidence in the platform.

How much harm do we really think it would cause if we waited to remove this until the new API was shipping?  How quickly could you ship the new API? Even if usage goes up 10x I'd still support removal at that time when there is a better replacement.

Other data that could help make a decision here:

Httparchive search - how many of the top sites use this Api?

GitHub search - what projects use it?

Stackoverflow search - how widely recommended is it?

Rick

[Philip Rogers]

I'm happy we caught this early. I think we can investigate writing a simple polyfill and working with authors instead of adding this feature back for a handful of pages. If that sounds reasonable, I'll start a thread off-list. Removing SVGPathSeg deleted over 3,000 lines of C++ without considering generated code which is on the order of 1% of the blink codebase.

Other data that could help make a decision here:

Httparchive search - I get 4 unique results for "createSVGPathSeg*", 7 for "pathSegList", and 0 for "getPathSegAtLength"

GitHub search - svgedit's path.js looks to be the top user, though there are many smaller projects that do use path segs.

Stackoverflow search - crickets.

[Rick Byers]

Thanks Philip.  11 hits in httparchive (top 200k sites) is indeed pretty tiny.  Working directly with svgedit to give them a JS alternative (which you could point other concerned developers to if necessary) sounds like a good compromise to me (assuming you're comfortable committing to having that done before this removal hits stable).

Anyone else have opinions here?  It's hard to know what the right trade off is.  To me this removal is different than most we've dealt with in that it's taking away functionality some developers want, which has long been available in all browsers, without a good replacement.  showModalDialog may be closest, but at least there we had some pretty strong arguments for why the API was bad for the platform (though it was, of course, not as niche usage as this case). 

Any signal from the other vendors on their plans to remove this too?  It would be easier to defend if we weren't the only ones removing it now.

Rick

[seb....@gmail.com]

Is there any procedure of deprecating functions ? This could immediately limit the number of new people / projects using the old/"bad" functons.
However it does appear strange in any case to remove the old functions BEFORE any replacement is ready.
If you don't want to wait for the upcoming
SVGPathElement.prototype.getPathData() and SVGPathElement.prototype.setPathData(pathData) methods

then at least I would ask to hold this commit back until projects like SVGedit do not rely on them anymore.
Help from your side in form of a simple substitute API would be greatly appreciated - even though funny in itself since these also would get removed in the long run - or not?

Sebastian

[PhistucK]

A deprecated method would emit a console warning.

The intent to remove these methods came about because of their very low usage. Web platform features usually enjoy a deprecation period, unless they are hardly used, which is the case here.

A temporary simple substitute API is out of the question.

getPathData is the substitute API (and not a temporary one), at least as it currently stands. If this is the consensus, the methods will be deprecated until (or once) getPathData is implemented.

☆PhistucK

Sebastian

[jarek...@gmail.com]

I have just finished writing a polyfill for the the new API: https://github.com/jarek-foksa/path-data-polyfill.js

It's not clear to me whether I should strip redundant segs such as multiple subsequent "M" segs from normalised path data. Also, should I insert explicit "M" seg at the beginning of each normalized subpath? The spec is not clear about it.

Besides SVG Edit, the pathSegList API is also used by Boxy SVG editor (https://chrome.google.com/webstore/detail/boxy-svg/gaoogdonmngmdlbinmiclicjpbjhgomg) and probably by few other apps that implement on-canvas SVG path editing functionality.

[jarek...@gmail.com]

Is there a comprehensive list of other SVG DOM APIs that might be removed from Chrome and therefore should be avoided by developers?

[Fredrik Söderquist]

On Fri, Oct 30, 2015 at 12:54 PM, <jarek...@gmail.com> wrote:

I have just finished writing a polyfill the the new API: https://github.com/jarek-foksa/path-data-polyfill.js

These are good questions, and AFAIK not specified. Here are my suggestions (based on Presto and Blink impls.)

 

It's not clear to me whether I should strip redundant segs such as multiple subsequent "M" segs from normalised path data.

If you're referring to cases like: "... M 10 10 M 20 20 ...", then I'd say you should keep the segment.

 

Also, should I insert explicit "M" seg at the beginning of each normalized subpath?

I'd say that you should not insert one.

Hope that helps,

/fs

[Fredrik Söderquist]

On Fri, Oct 30, 2015 at 1:22 PM, <jarek...@gmail.com> wrote:

Is there a comprehensive list of other SVG DOM APIs that might be removed from Chrome and therefore should be avoided by developers?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

I'm not aware of any such list. Looking at what SVG-prefixed counters there are (https://www.chromestatus.com/metrics/feature/popularity) might give a hint though.

Things to watch out for though would be usage of animVal (see http://www.w3.org/2015/06/11-svg-minutes.html#item07 ; http://www.w3.org/Graphics/SVG/WG/track/actions/3804), but in browsers not supporting SMIL, that's already a reality.

/fs

[jarek...@gmail.com]

In my opinion normalised path data should not contain segs that are redundant and therefore don't contribute to the rendering.

I would propose to define the normalised path as a path that consists from zero or more subpaths where each subpath must start with "M" segment, followed by one or more "C" or "L" segments, optionally followed by "Z" segment.

Paths normalized to this subset are the easiest to work with in apps that perform advanced path manipulations.

[Fredrik Söderquist]

On Fri, Oct 30, 2015 at 2:37 PM, <jarek...@gmail.com> wrote:

In my opinion normalised path data should not contain segs that are redundant and therefore don't contribute to the rendering.

I would propose to define the normalised path as a path that consists from zero or more subpaths where each subpath must start with "M" segment, followed by one or more "C" or "L" segments, optionally followed by "Z" segment.

Paths normalized to this subset are the easiest to work with in apps that perform advanced path manipulations.

I'd suggest that you provide this feedback to the SVG WG (which may or may not be reading this). https://svgwg.org/specs/paths/ has a "Feedback" link at the top.

/fs

 

On Friday, October 30, 2015 at 1:35:53 PM UTC+1, Fredrik Söderquist wrote:

On Fri, Oct 30, 2015 at 12:54 PM, <jarek...@gmail.com> wrote:

I have just finished writing a polyfill the the new API: https://github.com/jarek-foksa/path-data-polyfill.js

These are good questions, and AFAIK not specified. Here are my suggestions (based on Presto and Blink impls.)

 

It's not clear to me whether I should strip redundant segs such as multiple subsequent "M" segs from normalised path data.

If you're referring to cases like: "... M 10 10 M 20 20 ...", then I'd say you should keep the segment.

 

Also, should I insert explicit "M" seg at the beginning of each normalized subpath?

I'd say that you should not insert one.

Hope that helps,

/fs

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[seb....@gmail.com]

I was thinking about this again - there should be a transition solution that works on both the nighly builds and stable versions. And I think until this is ready I would kindly ask to undo this commit !!

A console warning would suffice the long term intent.

Thanks,

Sebastian

[Jarek Foksa]

The polyfill should work on both stable and nightly builds of Chrome.

[Sebastian Haase]

Thanks for the info.

So what does this mean for SVGedit?  An extra dependency ? And then, with what would I have to replace each of those createSVGPathSeg* calls ?

Sorry that I appear to be such a noob...

Sebastian 

[Jarek Foksa]

You can create new segs using plain object and array literals, e.g.

let pathData = [
{type: "M", values: [0, 0]},
{type: "L", values: [10, 10]},
{type: "C", values: [10, 10, 20, 20, 20, 20]}
];

Then you apply them on path with:

path.setPathData(pathData);

[Philip Rogers]

I've written a polyfill for existing users of the SVGPathSeg APIs: https://github.com/progers/pathseg

The polyfill passes all tests that were removed from blink when the path seg code was removed.

I've also submitted a pull request to use this polyfill in svg-edit.

[Rick Byers]

Awesome, thank you very much!

Writing a polyfill based on the blink code and making sure it passes all the tests removed from blink is the perfect way to approach this.  We should consider following this pattern in future removals (where possible)!

Rick

[emil...@gmail.com]

Hi guys,

We were recently noticed by our users that Moqups is broken in Chrome (https://moqups.com and the new version at https://app.moqups.com) . After digging up, we've found out that this is because of Canary and because of the deprecated SVG APIs. This kind of caught us of guard and we need some time to adjust and implement the proper polyfills and test/fix functional and performance regressions. Can you please reconsider these decisions and delay the changes for a few months? (same with getTransformToElements). 

Moqups is used by more than 500,000 users so it's likely something that would put our small company down its knees. 

Thanks for considering our appeal.

[Philip Rogers]

Emiltamas,

I added the pathseg.js polyfill to your page (<script src="pathseg.js"></script>, where pathseg.js is from https://github.com/progers/pathseg/blob/master/pathseg.js) and verified it fixes your site. Would you be willing to add the polyfill to your page? This has a side benefit of also future-proofing your site as other browsers remove this api.

[con...@moqups.com]

Thanks for the prompt reply Philip - I also tried the polyfill on the Moqups 2 earlier today and another polyfill dealing with getTransformToElement and things look alright. However, we're still concerned by performance, since our users have projects with hundreds of pages and tens of thousands of elements. 

Do you have any benchmarks available? Do you notice any performance degradation? I'll create some perf tests myself tomorrow but I'm curious about your opinion.

Many thanks,

Emil

[Philip Jägenstedt]

I don't know which getTransformToElement's there are, but this is
equivalent to what was previously implemented:

SVGGraphicsElement.prototype.getTransformToElement = function(target) {
return target.getCTM().inverse().multiply(this.getCTM());
}

It seems to give the same result in some simple ad-hoc tests at least.

> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.

[emil...@gmail.com]

Yes - that one. BTW - is there a way to keep up to date with these SVG related API breaking changes apart from hunting changelogs on mailing lists and bug trackers? Killing the API altogether without a warning period seems like a new, aggressive policy. There has to be a way this can be done in a less risk prone way. To be really honest, we're getting a little bit anxious over here, just imagine that all of the sudden a new Chrome is released and most of our staff is having their winter holiday vacation.

[emil...@gmail.com]

I did some basic performance tests with the polyfill and I'm noticing an average of 30x performance degradation in Canary Version 49.0.2572.0 canary (64-bit)
 vs Version 46.0.2490.86 (64-bit) in our particular context. This is really significant and the user experience will be affected considerably. I'm sure we can't easily match the native implementation without significant work (if at all), which could take us months of development time. I haven't ran any tests on the getTransformToElement yet, but I'm guessing there will be some penalty in there too, since the polyfill wraps two consuming getScreenCTM calls now. I'm also certain that apps using libs like Raphael.js or Snap.js might be impacted as well, since they now have to fall back on the non-native implementation. Is there any plan to offer a modern, equivalent native SVG2 API?

What is your recommendation at this point? 

[Philip Rogers]

Emil,

You can follow https://www.chromestatus.com/features for updates on major changes in platform APIs. We probably should have also issued a warning in the console for one release in this case. Fortunately, large libraries like D3, Raphael, and Snap are not affected. The performance issue you mentioned is out of scope for this thread but I'll shoot you an email off the list.

There is a new API in development, http://www.w3.org/TR/svg-paths, and Jarek has written a polyfill so you can play with it today: https://github.com/jarek-foksa/path-data-polyfill.js

[Philip Jägenstedt]

For getTransformToElement, the Intent to Deprecate and Remove is here:

https://groups.google.com/a/chromium.org/d/msg/blink-dev/SeGqJ2YZSnk/FxAmGvymDAAJ

It was removed without a deprecation period in part because the usage is extremely low:

https://www.chromestatus.com/metrics/feature/timeline/popularity/692

Just to understand whether a deprecation period would have helped, do you run through your site in devtools at least once every six weeks, so that you would have seen a deprecation message if there was one?

[Domenic Denicola]

It’s also important to note that there is a 12-16 week “warning period” during which the API is removed in Chrome Canary releases, before those changes make their way to the stable version that consumers use. If you’re interested in keeping up to date with such changes, I’d highly suggest developing using Canary, as that will give you plenty of time to notice such issues.

[PhistucK]

Eh, expecting all of the developers to use the canary is a bit harsh (and also, not stable sometimes and you may end up wasting your time working around problems that never make it to stable). Blink should make sure those removals are appropriately communicated to developers. Other than through blog posts (along with intents), a console warning for a single release is a fair way of doing so. It generally does not hurt development badly, since the code was there for a long while anyway...

If a developer does not look at their console while developing, you cannot do much to make sure they are aware of such changes. And if the feature is relatively obscure that the developer does not test it and therefore does not see the warning, you cannot do much either.

Google has its internal index search (to detect uses) and Webmaster Tools (to notify owners), perhaps leverage them on a regular basis instead of mostly relying on use counters and the HTTP Archive or GitHub. Yes, locked websites will not benefit from those, but it will increase your coverage.

☆PhistucK

[Rick Byers]

Regarding the process for removals: I definitely agree there's more we can do here.  And no, removal without a deprecation period is NOT going to become a common occurrence.  This was a special case where prompt removal was desirable AND our usage metrics indicated would have very little impact.  In retrospect I personally think it was probably a mistake to remove without a deprecation period. This is good feedback that we need to be more careful of this going forward.

If you're particularly invested in the future of SVG, then another good option is to follow along with the major changes to the SVG spec and give the editors feedback on the list. These APIs were removed from the spec back in June.

A sorted summary w/links for the blink API changes ("intents") is also available at bit.ly/blinkintents. And non-trivial changes (like this) should be mentioned in the chromium blog around the time of beta.

But I agree the urgent question here is what to do about the performance impact.  pdr@/fs@ what is your advice?

Rick

[emil...@gmail.com]

Thanks for your awesome responsiveness, guys. As a small business it definitely feels good to be listened in such an important community. Philip R. was kind enough to bounce a few polyfill performance ideas with me on a private thread, although our team ended up with a refactoring strategy that slowly eliminates the SVG 1.1 APIs in favor of pure JS/DOM agnostic implementations. We have deployed the polyfills on both versions of the app to avoid any kind of disruption to our users meanwhile.

There seems to be a good consensus that future breaking changes will be properly announced so we're less concerned about this now.

Best regards,

Emil

[Rick Byers]

Awesome, I'm very glad to hear it Emil!  Philip, thanks (again) for your help here.  

I'm still a little worried that other developers will be surprised by this removal (if two have contacted us here on this thread, then I'm sure at least a couple more are out there and still unaware of the change).  Here's a (possibly crazy) idea we probably should have considered sooner: can we land a deprecation warning on the M47 branch?  We still have a little time before M47 goes stable, if it's super low risk (console warning only) then perhaps the TPMs would still allow it?  That would still get us ~6 weeks where the current stable build was outputting a deprecation warning before the API is actually gone from stable.

Rick

[Chris Harrelson]

This is a good idea, let's try it. I'll follow up with the TPMs.

[siu...@gmail.com]

Yes, you found here a third complaint.

I noted this issue because I see the warning with Chrome 47.0.2526.80 (after upgraded from 47.0.2526.73). I think it is very irresponsible on Chromium's part to remove a SVG 1.1 feature with only one month of notice (to most of us who don't run Canary or beta).

While one month of notice might be good enough for a startup, larger companies have more procedure when updating a production system. I might need to talk to legal for new open source software. I might need to schedule out-of-band QA time for an emergency hotfix. We might end up with a week or two where our app will be broken for Chrome users who keep their browsers up-to-date.

Only 0.001% of the world uses the feature, but can you guess how worried those admins of the dozen of affected websites are?

"SVG WG decided it was best to remove it before usage grows", but you already added a deprecation warning, so how much more harm if you allow the feature to stay for one or two more releases?

The to-be-removed-feature is available in all other major browsers and the shiny-new-SVG2-feature is currently Chrome-specific. How do people who don't use Chrome for development know their app will be broken soon?

Am I being unreasonable?

On Wednesday, November 25, 2015 at 4:14:50 AM UTC+8, Rick Byers wrote:

Awesome, I'm very glad to hear it Emil!  Philip, thanks (again) for your help here.  

I'm still a little worried that other developers will be surprised by this removal (if two have contacted us here on this thread, then I'm sure at least a couple more are out there and still unaware of the change).  Here's a (possibly crazy) idea we probably should have considered sooner: can we land a deprecation warning on the M47 branch?  We still have a little time before M47 goes stable, if it's super low risk (console warning only) then perhaps the TPMs would still allow it?  That would still get us ~6 weeks where the current stable build was outputting a deprecation warning before the API is actually gone from stable.

Rick

[...]

[Domenic Denicola]

From: blin...@chromium.org [mailto:blin...@chromium.org] On Behalf Of siu...@gmail.com

> I noted this issue because I see the warning with Chrome 47.0.2526.80 (after upgraded from 47.0.2526.73). I think it is very irresponsible on Chromium's part to remove a SVG 1.1 feature with only one month of notice (to most of us who don't run Canary or beta).

> Am I being unreasonable?

Others on the list may disagree, and I am not representing the Chromium project when I say this, but as a former web developer at several large companies I think it is unreasonable to be a practicing web developer and not run Canary, dev, or beta. They are specifically designed mechanisms for getting the word out to developers early about changes in Chrome, giving you between 18 and 24 weeks of notice in general.

I would highly suggest your development team start incorporating them into their workflow, alongside other early releases like Firefox developer edition or Edge preview.

[james...@draganddrop.co.uk]

Thank you for this, your patch quickly solved my problem after Chrome updated.

Regards

James.

[sdu...@gmail.com]

On Monday, October 19, 2015 at 6:26:46 AM UTC-6, Fredrik Söderquist wrote:

Primary eng (and PM) emails

f...@opera.com

Compatibility Risk

Low, this feature is relatively obscure and didn’t gain much usage

In some frustration after Chrome 48 dropped, I suspect you are incorrect about how widely used this is (see below).  Parsing the grammar of polylines across browsers and frameworks (e.g. D3, etc) is involved.  A native API existed, codified in an a decades-old standard, used by likely more folks than any WG is going to accurately credit.  This ought to be measurable, at least across public repositories.  SVG 1.1 is not a working draft, so folks actually use it.
 

so the SVG WG decided it was best to remove it before usage grows. This feature has been in Chrome for a long time and is implemented in all browsers

It is impolite at best to deprecate a widely-used API without a native replacement.  A 6k (gizpped) polyfill obligation as the only way to fix this is quite frustrating.  It's not beyond scope of imagination to see some few thousands of developers needing to make this their problem.  The Internet mourns those 10,000 hours of lost productivity; hasty deprecation choices have consequences.  And the polyfill route without native SVGPathData only means that this effort will have to be repeated once it is time to use the SVG2 interface.
 

Usage information from UseCounter

https://www.chromestatus.com/metrics/feature/timeline/popularity/568 (around 0.001%)

Percent of pages is a poor metric for this.  I spend a lot of time thinking about denominators -- this one is artificially high.   Limit this to a sub-population of pages actively using SVG DOM, and it is possible that one may interpret the raw information differently. 

OWP launch tracking bug

This feature is fairly obscure so it is felt that we don’t need an official launch tracking bug.

If it is in fact, so obscure?

I realize this is done, but it would be nice to have SVGPathData interface per current draft implemented ASAP so we can feature-detect and avoid a 6k (at best) polyfill.

Thank you,
Sean

[sam.m...@gmail.com]

The responses I've seen here from Domenic and chrome team are very worrying. 

To remove a SVG 1.1 method with no native replacement only a 6kb polyfil to a chrome specific svg draft with little notice based on poor usage data is one thing. But to justify this because the developers should have been using chrome canary and opening the developer console every 4 weeks is ridiculous to check if any native method has been removed is ridiculous. 

 | "I think it is unreasonable to be a practicing web developer and not run Canary, dev, or beta" 

 ^ @domenic Why is it unreasonable that someone might use other browsers for development? I'm a not a practicing web developer because I use firefox developer edition? I have tried to use chrome canary but its often so buggy or memory consuming I can't open it without it crashing my computer.

I guess google is the new 90s microsoft.  

On Monday, 19 October 2015 22:26:46 UTC+10, Fredrik Söderquist wrote:

Primary eng (and PM) emails

f...@opera.com

Summary

The SVGPathSeg interface [1][2] was used to individually manipulate a path’s components. One use case was to modify any given component (e.g., a cubic arc command in the center of a path) without explicitly re-creating the path from a string.

[1] http://www.w3.org/TR/SVG11/single-page.html#paths-InterfaceSVGPathSeg

[2] http://www.w3.org/TR/SVG11/paths.html#InterfaceSVGPathElement

Motivation

This interface was difficult to use and has been removed from the SVG spec in favor of a new, awesomer API in the Paths module (https://lists.w3.org/Archives/Public/www-svg/2015Jun/0044.html).

Compatibility Risk

Low, this feature is relatively obscure and didn’t gain much usage so the SVG WG decided it was best to remove it before usage grows. This feature has been in Chrome for a long time and is implemented in all browsers.

Usage information from UseCounter

https://www.chromestatus.com/metrics/feature/timeline/popularity/568 (around 0.001%)

OWP launch tracking bug

This feature is fairly obscure so it is felt that we don’t need an official launch tracking bug. The actual removal is being tracked at http://crbug.com/539385.

Entry on the feature dashboard

https://www.chromestatus.com/features/5708851034718208

Requesting approval to remove too?
Yes.

[Philip Jägenstedt]

Hi Sam,

This removal happened with a shorter than usual deprecation period and with the benefit of hindsight that wasn't great. Currently there are a few ways of noticing that something will break:

• Seeing the deprecation message in Chrome DevTools
• Seeing it break in Beta/Dev/Canary
• Finding the entry on chromestatus.com
• Finding the blog post

There's certainly room to improve here. Given that we will remove some things from Blink and the web platform as a whole, is there a way to keep track of these changes that would work better for you?

[sdu...@gmail.com]

On Friday, August 12, 2016 at 10:42:17 AM UTC-6, Philip Jägenstedt wrote:

There's certainly room to improve here. Given that we will remove some things from Blink and the web platform as a whole, is there a way to keep track of these changes that would work better for you?

My sense is that this is not as much about communication as it is about the expectation that deprecation process should allow new standards to be implemented before removing old interface -- esp. an interface that is part of the current ratified standard.

And when using analytics to justify removal of a feature, be sure to get the denominator right: while not popular among web pages generally, this was popular among SVG developers.  In effect, Blink broke *current* SVG standard with an IOU for a future interface.

Now, the horse is out of the barn, we are saddled with the 6k minified/gzipped polyfill, I am resigned to that.

Sean

[Rick Byers]

Hey Fredrik/Philip,

Now that this has been removed from blink (and the specs) for a year, should we perhaps do some outreach to other browsers to see if they're interested in removing it as well (eg. at least file bugs)?

In a predictability effort to "measure" the API surface area difference between browsers, this shows up as the majority of APIs that are in all 3 other engines but not Chrome (111 of 170 - where "counting" an API is obviously an imperfect heuristic).  Given the complexity and removal from the specs, I imagine other engines may be interested to remove as well if we asked them?

[Fredrik Söderquist]

On Fri, Feb 17, 2017 at 5:44 AM, Rick Byers <rby...@chromium.org> wrote:

Hey Fredrik/Philip,

Now that this has been removed from blink (and the specs) for a year, should we perhaps do some outreach to other browsers to see if they're interested in removing it as well (eg. at least file bugs)?

In a predictability effort to "measure" the API surface area difference between browsers, this shows up as the majority of APIs that are in all 3 other engines but not Chrome (111 of 170 - where "counting" an API is obviously an imperfect heuristic).  Given the complexity and removal from the specs, I imagine other engines may be interested to remove as well if we asked them?

Filed:

https://bugzilla.mozilla.org/show_bug.cgi?id=1340572

https://bugs.webkit.org/show_bug.cgi?id=168519

(Had some auth trouble with the MS issue tracker, so if someone could file that, it'd be great...)

/fs

[PhistucK]

Filed.

By the way, you can also file issues using Twitter. :)

https://blogs.windows.com/msedgedev/2016/08/11/edgebug-twitter/#KSYpvDDzyFMwXVvB.97

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Sean Upton]

On Thu, Feb 16, 2017 at 9:44 PM, Rick Byers <rby...@chromium.org> wrote:

Hey Fredrik/Philip,

Now that this has been removed from blink (and the specs) for a year, should we perhaps do some outreach to other browsers to see if they're interested in removing it as well (eg. at least file bugs)?

In a predictability effort to "measure" the API surface area difference between browsers, this shows up as the majority of APIs that are in all 3 other engines but not Chrome (111 of 170 - where "counting" an API is obviously an imperfect heuristic).  Given the complexity and removal from the specs, I imagine other engines may be interested to remove as well if we asked them?

You are jumping precipitously until SVGGeometryElement and all other SVG 2 DOM interfaces are implemented by all of Blink, Gecko, Edge, and Webkit.  It is definition "impolite" (that's about the nicest way I can put it) to remove support for SVG 1.1 (in whole or part) until you actually have a spec that is widely implemented to replace it.  Removal from Blink in the first place was rude deviation from sane deprecation practice WRT long-standing web standards.

I do not think asking other engines to cargo-cult this hurried mistake is productive.

Sean

[itsu...@struddys.com.au]

So it's been several years. How's that replacement going? Or do I need to use the polyfill if I need to get pathSegLists in Chrome?

Does Chrome often remove features that all other browsers support in order to save on lines of code?

BMW could remove turn indicators to save weight, as only a tiny percentage of BMW drivers use them, but it doesn't mean they should.

[sdu...@gmail.com]

This analogy wins the Internet for the day!

SVG 2 SVGGeometryElement has landed in blink, so that may alleviate need for polyfill by... making you write a wrapper.

Still, SVG 1.1 is still the only current standard (and possibly for a good while), and Blink fails to conform:

"Google has a habit of unilaterally removing features it doesn't like from Blink, basically dictating that those features are removed from specifications." [via "SVG 2 Status: SVG 2 is on Life Support"].