- 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