-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Comments
The problem is the elements whose constructor does not clearly specify a tag name. E.g. 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 |
There's also base interfaces like |
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. |
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. |
@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):
|
@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? |
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 nameOption
, which meanslet option = new Option()
is allowed, but you can't dolet option = new HTMLOptionElement()
. I guess it's defined this way for compatibility with some legacy implementations, so it was not really a good argument.The text was updated successfully, but these errors were encountered: