Primary eng (and PM) emails
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.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
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?
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
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
Sebastian
I have just finished writing a polyfill 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?
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 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.
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.
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.jsThese 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.
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.
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
[...]
Primary eng (and PM) emails
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.
Primary eng (and PM) emails
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.
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?
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 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.
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?