Open arv opened 10 years ago
Also, constructor makes no sense in the context of these funky elements.
This seems like a bug in custom elements. Can we fix that? Or is there a reason for this restriction?
The idea was to treat this ambiguity as a bug in prior design: there should be a 1:1 relationship between a tag and an element constructor. But that was a while back, when we wanted to kill document.createElement and replace it with just constructors. If we no longer want this, we can definitely revisit this.
You could imagine HTMLQuoteElement allowing new HTMLQuoteElement("q") and HTMLQuoteElement("blockquote"). Seems brittle though if we later need an actual interface for <q>
or some such (this has happened, element starts out as HTMLElement, needs its own class later).
Hmm. I think that HTML has good reasons for allowing multiple tag names to share the same class: different default styling; different semantics; different ARIA roles (#14). I am surprised custom elements do not allow such things.
On the other hand I can see the argument that it was a legacy mistake, and that today all new elements should have their own classes, even if those classes are just empty extensions of HTMLElement
.
How are those good reasons for sharing the class?
Because none of them require their own API, and this you can get all those differences while still sharing a single API thar can be consulted, extended, and generically used.
What happens the moment you decide to add an attribute?
I don't understand the problem. The attribute gets added?
You have SharedElement for E and E'. Now you add an attribute to E which also requires a dedicated API. Now SharedElement can no longer be used for E. It will need to extend it. But the original constructor has no knowledge of this.
blockquote and q both use HTMLQuoteElement.
Custom elements do not all a prototype to be reused for multiple tag names.