Intent to Deprecate and Remove: SVGGraphicsElement.getTransformToElement

[Shanmuga]

Primary eng (and PM) emails

shanm...@samsung.com

Summary

Remove SVGGraphicsElement.getTransformToElement

 

Motivation

There were some open issues about how that method is supposed to behave and it was decided to remove this on SVG WG F2F (https://lists.w3.org/Archives/Public/www-svg/2015Aug/att-0009/SVGWG-F2F-minutes-20150824.html#item02)

 

Compatibility Risk

Low, this feature usage is very low and so the SVG WG decided it was best to remove it before usage grows.

 

Usage information from UseCounter

https://www.chromestatus.com/metrics/feature/popularity#SVGGraphicsElementGetTransformToElement (around 0.0001%)

 

Alternative implementation suggestion for web developers

It is possible to use getCTM() of current element and target element to calculate the transformation matrix().

 

OWP launch tracking bug

The actual removal is being tracked at http://crbug.com/524432.

Requesting approval to remove too?
Yes.

[PhistucK]

​Please, either create an entry for this in chromestatus.com, or add it to an existing, recently deprecated​ and removed method entry (see the recent intents for one).

☆PhistucK

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

[Philip Jägenstedt]

The implementation of this is actually quite trivial in Blink, and looks trivial in Gecko as well. It's supported in Edge, although Edge doesn't have the SVGGraphicsElement interface.

When something trivial is already interoperably supported, I think we should be quite conservative about removing it. What was the actual spec issue here?

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

[Fredrik Söderquist]

On Mon, Oct 26, 2015 at 1:30 PM, Philip Jägenstedt <phi...@opera.com> wrote:

The implementation of this is actually quite trivial in Blink, and looks trivial in Gecko as well. It's supported in Edge, although Edge doesn't have the SVGGraphicsElement interface.

When something trivial is already interoperably supported, I think we should be quite conservative about removing it. What was the actual spec issue here?

The link below under "Motivation" shows some of the reasoning and issues. I think the primary reason - and the reason the implementation is trivial - is that cases where 'this' and 'target' are in different SVG fragments is not handled (and will give nonsensical results.)

/fs

[Philip Jägenstedt]

On Mon, Oct 26, 2015 at 1:53 PM, Fredrik Söderquist <f...@opera.com> wrote:

On Mon, Oct 26, 2015 at 1:30 PM, Philip Jägenstedt <phi...@opera.com> wrote:

The implementation of this is actually quite trivial in Blink, and looks trivial in Gecko as well. It's supported in Edge, although Edge doesn't have the SVGGraphicsElement interface.

When something trivial is already interoperably supported, I think we should be quite conservative about removing it. What was the actual spec issue here?

The link below under "Motivation" shows some of the reasoning and issues. I think the primary reason - and the reason the implementation is trivial - is that cases where 'this' and 'target' are in different SVG fragments is not handled (and will give nonsensical results.)

OK, now I see what "the tricky cases that the method needs to address are dealing with multiple fragments" means.

Just spec'ing the implemented nonsensical behavior seems like an option, but admittedly not a great one.

It's really not the existing usage that's a problem here, it's that over the course of at least a few years, web developers will have the opportunity to waste time if they find this function and first test it in a browser that still hasn't removed it. It's a bit like node.isSameNode() in this regard.

What do you think should be done? ed@ and pdr@?

Philip

[Fredrik Söderquist]

Personally I think I'd favor a removal. No really strong reasoning around that though.

I looked at the Blink and Gecko implementations, and "interoperably supported" isn't quite true [1] even of these ~10LoC implementations. If we don't drop it, then maybe we should see what Edge does and then align with one or the other (the Gecko impl. ought to "work" in a few more cases.)

/fs

[1] Gecko implements using getScreenCTM while Blink uses getCTM, so don't go nesting your <svg>s...

[Philip Jägenstedt]

Oh, I didn't spot the difference.

LGTM1 to remove without deprecation period given the very low usage and the fact that doing nothing at all with existing implementations doesn't look like an option.

Philip

[Chris Harrelson]

LGTM2

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

[Dimitri Glazkov]

LGTM3333

[Joe Medley]

Now that it has its three LGTM's, yes, please.

[Shanmuga]

I did not have the edit access on chromestatus.com..
I will create an entry once I get. Thank you.

[PhistucK]

Did you request it via the bottom link on chromestatus.com?

☆PhistucK

[Shanmuga]

yes. I requested via bottom link.

[Shanmuga Pandi M]

Entry on the feature dashboard :
https://www.chromestatus.com/feature/5736166087196672

[Philip Jägenstedt]

Thanks, Shanmuga! I edited it to say that it will be removed in M48, so please go ahead and make a red diff :)