Make the HTML parser put audio/video/source/iframe/canvas-in-svg into the HTML namespace

[tabatkins]

The SVG2 spec defines that the HTML audio/video/iframe/canvas elements should work in SVG. That's a little bit inconvenient in SVG's XML serialization, as you have to include another namespace, but it's actually impossible currently in embedded SVG, as you don't use namespaces manually at all.

The parser, when it switches into parsing SVG, should have a list of elements that are put into the HTML namespace automatically. At minimum, this should be audio/video/iframe/canvas, + picture. Child elements should also automatically be in the HTML namespace (unless you hit an subtree, obviously).

[annevk]

@tabatkins will you try to make a patch or is this for us to figure out?

Also, is there a public discussion somewhere where the SVG community says they want to change the HTML parser to this effect?

[tabatkins]

I'm willing to write a patch if you want.

Also, is there a public discussion somewhere where the SVG community says they want to change the HTML parser to this effect?

I'm not sure what you mean. The SVGWG is only marginally concerned with embedded SVG - the parser for that is HTML's responsibility. (That said, there has been discussion about defining a way to do standalone SVG by just jumping straight into HTML's foreign-content parser. But that's a different issue.)

[annevk]

I'm curious whether this is your idea, or whether this is something that multiple implementers and developers want.

[tabatkins]

The first part (making some HTML elements work in SVG) is an SVGWG-approved thing, with implementor approval.

Altering embedded-SVG parsing hasn't been explicitly discussed much, but it's an obvious outgrowth, given that it's impossible to do html-namespace elements in embedded SVG currently.

(In particular, wanting <picture>/srcset in SVG is something I've heard from authors, for obvious reasons.)

[annevk]

I guess we should also do this for all custom elements?

[tabatkins]

Are custom elements automatically in the HTML namespace when you register them? If so, then definitely yes. (Same with <template> too then, I guess?)

[domenic]

Are custom elements automatically in the HTML namespace when you register them?

Yep

[AmeliaBR]

For cross-reference, the issue on the SVG WG spec tracking this: w3c/svgwg#240

I would definitely agree with @tabatkins that SVG's adoption of iframe, canvas, video, and audio is of limited use without HTML parser recognition.

I would be more cautious about picture (which SVG doesn't yet recognize) and custom elements (since SVG would like to eventually be able to define our own custom elements, which can be created as extensions of SVGElement, not HTMLElement).

[birtles]

For reference, we've discussed the possibilities for better integrating HTML and SVG many times in the past including a few members of the SVG WG meeting up with Hixie over lunch a few years back to discuss this (notes). I I think this has had pretty significant discussion and the proposal here is fairly conservative but still very useful. (Not sure about <picture> or custom elements, but we need to do something about <template> too.)

An external contributor is interested in implementing this in Gecko so I'd like to resolve this issue.

[annevk]

@birtles changing the HTML parser will require support from at least two implenters (ideally all), tests, and a PR for the HTML Standard. Implementing before those are in place would be premature.

[birtles]

I'm pretty sure tests would be included in the PR Tab is offering to write 😉

@hsivonen, @rniwa, @zcorpan, @pmeenan, @sideshowbarker, @jacobrossi any concerns about making the HTML parser put a limited whitelist of HTML elements (iframe/video/audio/canvas) in an SVG subtree in the HTML namespace? (None of the elements in the list trigger HTML's "escape foreign content mode" behavior.)