- 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