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.
Really? This is effectively flattening the svg namespace into HTML. Opera and FF really do this?
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.
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).
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.
see BR-6699
This has been fixed at some point.