You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In #405@annevk suggested changing the proposed signature of createElement from (localName, typeExtension) to (localName, options) so that we don't keep piling parameters onto it. This makes sense to me. I think a dictionary containing "is" is pretty reasonable.
This would impact Blink negatively since they are already shipping the string-taking version. I guess maybe they could use an overload for the transition period? Dictionaries and strings are distinguishable, right? I should really memorize that table.
This is all operating under the assumption that we don't just completely remove type extensions from v1. My understanding of the F2F was that we were going to leave them in and see if they got 2 shipping implementations.
The text was updated successfully, but these errors were encountered:
Right, we're not going to implement it (is/extends) in WebKit, and we're not going to have this additional argument on createElement as a result. But the rough consensus at F2F was indeed to leave it in the spec and see what happens in the implementations.
Dictionaries and strings are distinguishable, yes (the only problem would be with existing code relying on stringification of some object).
The main reason I want to make this change is that we might extend createElement() further. I sort of thought at some point it was going away in favor of constructors, but that does not seem to be happening anytime soon, so we might add other features here, just like custom elements is trying.
In #405 @annevk suggested changing the proposed signature of createElement from (localName, typeExtension) to (localName, options) so that we don't keep piling parameters onto it. This makes sense to me. I think a dictionary containing "is" is pretty reasonable.
This would impact Blink negatively since they are already shipping the string-taking version. I guess maybe they could use an overload for the transition period? Dictionaries and strings are distinguishable, right? I should really memorize that table.
This is all operating under the assumption that we don't just completely remove type extensions from v1. My understanding of the F2F was that we were going to leave them in and see if they got 2 shipping implementations.
The text was updated successfully, but these errors were encountered: