Give each element a distinct, usable constructor

[jarek-foksa]

The spec already defines constructor on e.g. HTMLOptionElement interface. Also, standard elements should be constructable with new if the same will be possible with custom elements.

Update: I just realized that the spec defines HTMLOptionElement constructor as NamedConstructor with name Option, which means let option = new Option() is allowed, but you can't do let option = new HTMLOptionElement(). I guess it's defined this way for compatibility with some legacy implementations, so it was not really a good argument.

[domenic]

The problem is the elements whose constructor does not clearly specify a tag name. E.g. new HTMLQuoteElement() could either be a <q> or a <blockquote>.

I think at the last custom elements F2F a lot of people agreed that the best way to fix this is to just create separate interfaces for everything (so in this case HTMLBlockquoteElement and HTMLQElement, both deriving from HTMLQuoteElement). But I didn't quite get the sense any implementers were exciting about taking on that potential compat risk, even if we went to the trouble of speccing it. @rniwa @smaug---- @esprehn thoughts?

[foolip]

There's also base interfaces like HTMLMediaElement which would have to be left without constructors. Not sure if anyone would find that surprising, or if it's a non-issue.

[tabatkins]

That sort of thing is fine, it's just an "abstract class" that cant' be directly constructed. Not unusual.

Separately: I don't think making these constructable is very useful. The names are very long, and the signatures are anemic. I'd much rather have a good element-creation API that handles attr/property setting and children assigning, like every DOM library has.

[esprehn]

I suspect the compat risk of introducing a separate interface for all elements with a different tag name is really low. You'd only really notice if you looked at proto on an element. Things were so broken there in WebKit and Blink for so long I've not really seen anyone depend on what's on the instance vs the prototype though. I think we should try it. It also explains what's going on with custom elements better too.

I do think Tab is right that the constructor ergonomics are pretty gross, but it's not clear to me we're going to provide something much better than a 10 line micro library would.

Do we have an idea for what the arguments would be though? Once we decide on them we're pretty much stuck forever since they're passed into custom elements too. So we couldn't ship new Element(attributes) today and then decide on new Element(attributes, children) tomorrow.

[annevk]

@esprehn, if we give each element its own class there's no need for arguments for v1 of this feature. But perhaps we could even do a v0 first, where we just give each element its own class and see what happens with that. Lots of new classes, by the way (some names can probably be improved a bit):

• HTMLAbbrElement
• HTMLAddressElement
• HTMLArticleElement
• HTMLAsideElement
• HTMLBElement
• HTMLBDIElement
• HTMLBDOElement
• HTMLBlockquoteElement
• HTMLCiteElement
• HTMLCodeElement
• HTMLDDElement
• HTMLDelElement
• HTMLDFNElement
• HTMLDTElement
• HTMLEmElement
• HTMLFigcaptionElement
• HTMLFigureElement
• HTMLFooterElement
• HTML[H1-H6]Element
• HTMLHeaderElement
• HTMLHgroupElement
• HTMLIElement
• HTMLInsElement
• HTMLKBDElement
• HTMLMainElement
• HTMLMarkElement
• HTMLNavElement
• HTMLNoscriptElement
• HTMLQElement
• HTMLRPElement
• HTMLRTElement
• HTMLRubyElement
• HTMLSElement
• HTMLSampElement
• HTMLSectionElement
• HTMLSmallElement
• HTMLStrongElement
• HTMLSubElement
• HTMLSummaryElement
• HTMLSupElement
• HTMLTableBodyElement
• HTMLTableFooterElement
• HTMLTableHeaderElement
• HTMLUElement
• HTMLVarElement
• HTMLWBRElement

[tabatkins]

@esprehn The issue is, you're proposing we add code to the browser to give every tagname its own interface, and make all those interfaces have a useful constructor. Is this substantially different than not doing that, and instead making a single decent element-creation function? If the code weight is anywhere near similar, the latter is way more useful for authors; do you really still think we should do the former?