search

laaglu / lib-gwt-svg

a general purpose SVG library for GWT. The goal is to make it easy to do SVG graphics in a GWT application
http://www.vectomatic.org/libs/lib-gwt-svg
39 stars 23 forks source link

SVGPathSeg is deprecated and will be removed in Chrome 48 #18

Closed apprme closed 8 years ago

apprme commented 8 years ago

See https://www.chromestatus.com/feature/5708851034718208.

To reproduce, you can open lib-gwt-svg demo in the latest stable chrome (47.0.2526.106 at the moment) and see warning in chrome developer console.

apprme commented 8 years ago

As far as I understand this discussion they recommend to operate the content of d attribute directly.

laaglu commented 8 years ago

Hi. Thanks for reporting that. Indeed this is quite a change. The interface has been removed from the SVG2 spec, though the spec is still in draft stage and not yet a recommendation. I will see what I can do to address that.

kevinsmit commented 8 years ago

I've also run into this issue. I attempted to use this JS polyfil, but no dice. https://github.com/progers/pathseg

laaglu commented 8 years ago

I think the chrome developers have really jumped the gun by removing the SVGPathSeg APIs from chrome 48, with no warning or deprecation and without even having a working replacement to offer.

Here is the current situation (unless I have misunderstood something)

Chome49

Firefox46

IE11/Edge

Same status as FF46, except there is even less info about MS plans, IE&Edge being proprietary.

The specs are still in a rather early stage, this is probably why most vendors do not seem in a hurry to implement them.

From the lib-gwt-svg point of view, some possible action could be:

  1. mark SVGPathSegList/SVGPathSeg as deprecated (short term)
  2. provide SVGPathData/SVGPathSegment with implementation based on the polyfill (short term)
  3. Once chrome finishes their implementation, migrate to it
  4. If enough time, provide an implementation of the new API based on the old API rather than the polyfill or work on the polyfill to make it support write access too

Anyway, the chrome code is going to be broken for quite some time at it will be a while until they provide the level of functionality they had with the old API and everybody agrees on the final API to implement

kevinsmit commented 8 years ago

I agree. I think removing the API before a replacement was ready is very irresponsible of the Chrome devs. I've got an app that isn't under active development anymore, and this change will break the app for 66% of my users. Hopefully I can divert some time to figure out a workaround before Chrome 48 is released. I definitely post back here if I figure something out.

laaglu commented 8 years ago

I have been able to put together a quick and dirty fix based on this polyfill https://github.com/progers/pathseg/blob/master/pathseg.js It seems to at least repair lib-gwt-svg-samples. I need to make more tests to see what other apps in my collection got broken by Chome48 and if this fix addresses them. Let me know if it works for you too.

apprme commented 8 years ago

@laaglu will you deploy new version to maven central or is there already snapshot version we can try?

laaglu commented 8 years ago

I have uploaded the snapshot version to my site http://www.vectomatic.org/mvn/org/vectomatic/lib-gwt-svg/0.5.11-SNAPSHOT/ if you do not want to rebuild it yourself. I want to do some more testing and possibly improve the fix if required, then publish 0.5.11 to maven central (hopefully before Chrome 48 is switched on january 28th, 2016)

kevinsmit commented 8 years ago

@laaglu It works great for me. I owe you drinks if you're ever in Salt Lake!

kevinsmit commented 8 years ago

It appears I may have spoken too soon. On Safari (and only Safai) it looks like OMSVGDocument.createSVGGElement is returning null.

laaglu commented 8 years ago

Hi. Is the problem related to the recent changes to Chrome 48+ (can be reproduced on Chrome 48+) ? If not it would be better to open another issue to track that separately