Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Give each element a distinct, usable constructor #896

Open
jarek-foksa opened this issue Mar 17, 2016 · 6 comments

Comments

@jarek-foksa
Copy link

commented Mar 17, 2016

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

This comment has been minimized.

Copy link
Member

commented Mar 17, 2016

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

This comment has been minimized.

Copy link
Member

commented Mar 22, 2016

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

This comment has been minimized.

Copy link
Collaborator

commented Mar 22, 2016

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

This comment has been minimized.

Copy link

commented Mar 24, 2016

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

This comment has been minimized.

Copy link
Member

commented Mar 24, 2016

@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

This comment has been minimized.

Copy link
Collaborator

commented Mar 24, 2016

@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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
6 participants
You can’t perform that action at this time.