lib-gwt-svg 0.5.11 released to address dropped SVG1.1 features in Chome 48+

I am releasing a new version of lib-gwt-svg to preserve compatibility with Chrome 48+. Indeed Chrome 48+ has begun dropping compatibility with several SVG1.1 features in their quest to implement new SVG2.0 features. The sad thing is that they dropped SVG 1.1 features before they even provided a working SVG2.0 replacement !

You can get details on the removed APIs here:
SVGPathSeg interfaces (removed)
Deprecate/Remove SVGGraphicsElement.getTransformToElement (removed)

Luckily for us SVG1.1 users, I have been able to restore compatibility by leveraging the excellent polyfills developed by David Durman and Philip Rogers.

I have also noted another difference in the behavior of Chrome 48 which broke some of my HTML games. SVG elements with a width and height of 100% will not be sized correctly: they will scale to the greatest of the two dimensions and not fit into the viewport anymore. I do not think this can be addressed with a polyfill, but I was able to use the following workaround: make the SVG elements absolute and use absolute CSS positioning with width=100% and height=100% to restore the original behavior.

Darren Hurt

February 1, 2016 at 3:14 pm

When are you releasing this new version?

I’ve run into trouble with this when creating arrowheads for a graph via:
OMSVGPathElement path = doc.createSVGPathElement();
OMSVGPathSegList segList = path.getPathSegList();
segList.appendItem(path.createSVGPathSegMovetoAbs(2,2));
segList.appendItem(path.createSVGPathSegLinetoAbs(2,11));
segList.appendItem(path.createSVGPathSegLinetoAbs(10,6));
segList.appendItem(path.createSVGPathSegLinetoAbs(2,2));

I think the JavaScript methods behind methods like ‘createSVGPathSegMovetoAbs’ no longer exist for Chrome, and indeed the path object in this sample is now null, so I think I need your new library version when it becomes available!

Thanks,

Darren