- From: <bugzilla@jessica.w3.org>
- Date: Wed, 30 Jan 2013 23:46:55 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20487 --- Comment #13 from Dimitri Glazkov <dglazkov@chromium.org> --- (In reply to comment #12) > > As spec'd now, you can build a non-HTML/SVG Element and get away with > > instantiating it in any namespace. Which seems fine. > > I think if you try to instantiate an element not in the HTML namespace which > has HTMLElement.prototype on the proto chain we should consider making that > not work. Just my 2 cents. Good point. > > > No, as spec'd now, it will throw a NamespaceError > > Why? Because of this line: "If INTERFACE inherits from SVGElement and NAMESPACE is not SVG namespace, throw a NamespaceError and stop." I am not sure if that's the right behavior, though. > > >var s = document.createElement('svg') > >WebKit simply creates an HTMLUnknownElement. > > I think so does everyone else. Certainly Gecko does (in an HTML document). WDYT, should we keep the same lackadaisical behavior for custom elements? For example, for a custom element "super-svg", that extends SVGSVGElement: var superSvg1 = document.createElement('super-svg'); Should it: a) throw NamespaceError b) returns HTMLUnknownElement c) returns the instance of "super-svg" custom element? -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Wednesday, 30 January 2013 23:46:56 UTC