On Fri, 16 Jan 2015 20:08:30 +0100, Domenic Denicola <d...@domenic.me> wrote:
From: Anne van Kesteren [mailto:ann...@annevk.nl]
How can that work if the custom element constructor needs to look in
the registry to find its name? Pick a name at random?
Nah, it just automatically starts acting like HTMLQuoteElement: the
localName option becomes required. See
https://github.com/domenic/element-constructors/blob/5e6e00bb2bb525f04c8c796e467f103c8aa0bcf7/element-constructors.js#L229-L233
https://github.com/domenic/element-constructors/blob/5e6e00bb2bb525f04c8c796e467f103c8aa0bcf7/element-constructors.js#L51-L54
Consider if HTML adds a new element that uses the same interface as
another element, let's say <foobar>, so that both <foobar> and <data> use
HTMLDataElement. When this happens, new HTMLDataElement() starts throwing?
Similarly, if HTML is changed such that an element changes to use a more
specific interface, e.g. <ruby> changes from HTMLElement to
HTMLRubyElement, then new HTMLElement('ruby') will start throwing?
If so, it seems it removes some flexibility with how HTML uses interfaces.
In particular many elements use HTMLElement and it should be possible to
change them to use a more specific interface. How do you envision to solve
this? Should we assign element-specific interfaces to all post-HTML4
elements now, just in case? Or make new HTMLElement('ruby') create an
HTMLRubyElement? Something else?
--
Simon Pieters
Opera Software
