[w3c/webcomponents] customElements.define should throw on registration of definitions that shadow built-in properties / methods. (#583)

At some point in the future, it would be nice to allow custom elements to override methods and properties used as part of APIs that are currently defined natively. However, it is currently possible to override these methods on a custom element, but these methods aren't actually be used by the native code when performing those operations. I think the custom elements registry should throw when custom element authors register definitions that shadow these APIs so that they could one day be opened up as real extension points without worrying about breaking existing code.

For example, take Element's `setAttribute` method. A custom element without the above restriction can override this method and provide their own behavior. Typical non-native code will automatically use the custom element author's version of `setAttribute`. However, without the internals also calling this extension for every `setAttribute` operation, the internal implementation has to be rationalized by the custom elements author as calling something like `Element.prototype.setAttribute.apply(node, [name, value])` rather than `node.setAttribute(name, value)`, which is really odd.

I'm under the impression that making these properties real extension points is very challenging from an architectural standpoint in any given browser, but I think it's the ideal. Enforcing this restriction would at least prevent custom element authors and consumers from starting to use non-native extensions to these methods before the browser implementors could use them and, in particular, prevents authors from *relying* on browser not using them.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/583