Refactor SVG inlining from md-icon into cdk-svg

[jelbourn]

The SVG inlining features of md-icon are more generally useful than for just displaying icons. We should refactor the code such that:

• The SVG portions of MdIconRegistry are moved to IconRegistry in the cdk, with MdIconRegistry then extending IconRegistry
• The SVG inlining code in md-icon is moved into cdk-svg with md-icon then consuming cdk-svg.

This will enable us to add additional APIs to cdk-svg around customizing viewBox and preserveAspectRatio (see https://css-tricks.com/scale-svg)

Notes:

• Part of this should be moving SVG parsing (i.e. string -> SVGElement) into its own utility that can be mocked. This will be useful when ensuring that parsing only happens when expected (since it can have performance impacts if overdone).

[m98]

@jelbourn Maybe first we can list few methods/functions we want to have in cdk-svg that we need for customizing viewBox

[jandsu]

I am transitioning from using <use xlink:href="..."> to inline icons in my SVG icon set and was hit by #5488 (where the viewBox attribute is not preserved).
Given that the above issue was closed, I guess it is not worth providing a PR for it.

Meanwhile, I came with a (very nasty - but temporary) workaround:

const proto = Object.getPrototypeOf(iconRegistry);
const original : ((e:Element)=>Element) = proto._toSvgElement;
proto._toSvgElement = (element: Element) => {
    let svg = original.call(iconRegistry, element);
    const viewBox = element.getAttribute('viewBox');
    if (viewBox) {
        svg.setAttribute('viewBox', viewBox);
    }
    return svg;
}

Do you recommend that I do a PR with the above 3 lines or do you plan the CDK refactoring to land soon enough for this PR to be worthless?

In any case, if this nasty workaround can help anyone stumbling over this issue...

[jelbourn]

We probably wouldn't get to making cdk-svg within the next month, at least. We don't want to make it such that md-icon always takes the viewbox from the original asset, since it's meant to capture the specific Material Design icon use-case (rather than the general inline-svg case that cdk-svg would do)

[jandsu]

OK thanks for this clarification. So a PR would make no sense... I'll have to live with my hacky workaround meanwhile :)

[josh18]

Out of curiosity, why wouldn't you want to copy viewbox when using MD icons?

[leosvelperez]

@jelbourn is there any timeline for this?

[jelbourn]

As with many other things, it's something we want to do but don't have scheduled yet.

[josh18]

Would you accept a PR to make some current methods protected instead of private so that it is easier to extend?

[jelbourn]

Probably not since we plan on doing a larger refactoring, at which point changing those protected methods would be a breaking change