Bug 20382 – Support svg elements inside plain HTML content

• Status: RESOLVED
• Resolution: WORKSFORME
• Component: SVG

[Henri Sivonen]

Build: WebKit-SVN-r35752

Steps to reproduce:
 1) Load http://livedom.validator.nu/?%3Ch1%3Efoo%3C%2Fh1%3E%0A%3Csvg%20%20viewBox%3D'0%200%20100%20100'%3E%0A%20%20%20%20%3Ccircle%20fill%3D'green'%20cx%3D'0'%20cy%3D'0'%20r%3D'20'%2F%3E%0A%3C%2Fsvg%3E

Actual results:
Expected to see the lower right quarter of a green circle in the Rendered View after the heading "foo".

Actual results:
The <h1> element renders but <svg> not.

Additional info:
The document object in the iframe is an HTML DOM. The elements (both HTML and SVG) are created with createElementNS. It works in Firefox 3 and Opera 9.5.

[Eric Seidel (no email)]

Really?  This is effectively flattening the svg namespace into HTML.  Opera and FF really do this?

[Henri Sivonen]

It's not supposed to flatten the namespace. It's supposed to insert the SVG stuff in the SVG namespace. Firebug in Firefox shows that the SVG nodes end up in the SVG namespace. Web Inspector in WebKit shows that the SVG nodes implmement SVG-specific interfaces.

[Eric Seidel (no email)]

We just have to decide if we want to do this or not.  This content is not valid SVG, certainly not valid XHTML but obviously FireFox has chosen to add this support (which I don't blame them, it sure makes things easier for authors).

[Henri Sivonen]

Note that SVG-in-text/html support will mean that SVG subtrees (nodes in the SVG namespace with a subtree root whose local name is svg) need to be painted when inserted in an HTML-mode DOM.

[Joel Parks]

see BR-6699

[Henri Sivonen]

This has been fixed at some point.