Intent to Implement and Ship: SVGImageElement as CanvasImageSource

[Fernando Serboncini]

Contact emails

fs...@chromium.org, ju...@chromium.org

Spec

https://html.spec.whatwg.org/multipage/scripting.html#image-sources-for-2d-rendering-contexts:htmlorsvgimageelement

Summary

The union type CanvasImageSource (used for DrawImage and CreateTexture) doesn't include SVGImageElement on Chrome. We are including it.

Motivation

It's part of the spec and it's a convenience feature: SVG images are very similar to HTML images, so it's good that they both have the same behaviour.

Interoperability & compatibility risk

Other browsers haven't implemented this yet.

Edge: No signals

Firefox: No signals

Safari: No signals

Web developers: No signals

Ongoing technical constraints

None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux,

Chrome OS, Android, and Android WebView)? Yes or no.

Yes

OWP launch tracking bug

http://crbug.com/695662

Requesting approval to ship?

Yes

[Ian Kilpatrick]

What is the behaviour if it includes a <foreignObject>?

--
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.

[Justin Novosad]

On Wed, Mar 1, 2017 at 5:49 PM, Ian Kilpatrick <ikilp...@chromium.org> wrote:

What is the behaviour if it includes a <foreignObject>?

Same as with an HTMLImageElement that loads an svg file that includes a <foreignObject>.

Therefore, this will currently taint the canvas, which is a bug that will be addressed separately. (Covered by "Intent to Implement and Ship: Stop tainting canvases when drawing SVG with <foreignObject>")

[Justin Novosad]

To be clear: Adding SVGImageElement as CanvasImageSource implies adding SVGImageElement to ImageBitmapSource since ImageBitmapSource is defined as a union typedef that includes CanvasImageSource.

[Ian Kilpatrick]

And I assume this won't render cross-origin iframes and visited-links etc inside the foreign object? (just checking).

[Justin Novosad]

On Wed, Mar 1, 2017 at 6:09 PM, Ian Kilpatrick <ikilp...@chromium.org> wrote:

And I assume this won't render cross-origin iframes and visited-links etc inside the foreign object? (just checking).

Correct. In fact, since the svg resource is rendered synchronously so all loadable resources are ignored (because resource loading is async), so we don't even need to worry about checking for cross-origin resources inside the <foreignObject>.  Hyperlink text is rendered without the application of the visited/not visited styles.

[Fredrik Söderquist]

On Thu, Mar 2, 2017 at 12:09 AM, Ian Kilpatrick <ikilp...@chromium.org> wrote:

And I assume this won't render cross-origin iframes and visited-links etc inside the foreign object? (just checking).

All the restrictions that generally apply to SVG's in an image context will apply here as well.

/fs

[Fredrik Söderquist]

On Thu, Mar 2, 2017 at 12:18 AM, Justin Novosad <ju...@chromium.org> wrote:

On Wed, Mar 1, 2017 at 6:09 PM, Ian Kilpatrick <ikilp...@chromium.org> wrote:

And I assume this won't render cross-origin iframes and visited-links etc inside the foreign object? (just checking).

Correct.

 

In fact, since the svg resource is rendered synchronously so all loadable resources are ignored (because resource loading is async), so we don't even need to worry about checking for cross-origin resources inside the <foreignObject>.

Technically speaking this is a bug though ('complete' being tied to resource download rather than something more encompassing - in this case think 'load' on the image document.) All non-data URL resources are explicitly blocked during fetch though.

/fs

[TAMURA, Kent]

LGTM1.  This looks a straight-forward feature.

--

TAMURA Kent
Software Engineer, Google

[Philip Jägenstedt]

LGTM2. Makes good sense, and it should hopefully be possible to write web-platform-tests for this while implementing, if they don't exist already.

[Chris Harrelson]

LGTM3