- From: <bugzilla@jessica.w3.org>
- Date: Fri, 01 Feb 2013 23:35:10 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20487 Dimitri Glazkov <dglazkov@chromium.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |annevk@annevk.nl --- Comment #15 from Dimitri Glazkov <dglazkov@chromium.org> --- (In reply to comment #14) > > "If INTERFACE inherits from SVGElement and NAMESPACE is not SVG namespace, > > throw a NamespaceError and stop." > > Oh, that part is just fine. The problem is that in the very next step > NAMESPACE is completely ignored and the element is created in the HTML > namespace no matter what NAMESPACE was. So if the incoming NAMESPACE is SVG > and the interface inherits from SVGElement we'll get to step 5 and happily > create ... an HTML element. I am terrible. Thank you for pointing this out. https://dvcs.w3.org/hg/webcomponents/rev/c417c040987a > > > 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 > > I would probably be OK with this. I sort of prefer this one, since it's very likely the user is unintentionally making a mistake by attempting to create a custom element in the wrong namespace. > > > b) returns HTMLUnknownElement > > I would be OK with this as long as the super-svg custom stuff is not applied > to it... > > > c) returns the instance of "super-svg" custom element? > > I would probably be OK with this one too. > > Worth roping in Anne to see what his thoughts are on createElement here. Anne, WDTY? -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Friday, 1 February 2013 23:35:12 UTC