- From: Domenic Denicola <notifications@github.com>
- Date: Thu, 10 Mar 2016 16:42:08 -0800
- To: w3c/webcomponents <webcomponents@noreply.github.com>
Received on Friday, 11 March 2016 00:42:44 UTC
Given the variety of proposals for new custom element related methods that are starting to fly around (e.g. #419 and #427 talk about upgrade-related helpers, plus there's always our plans for a registry API #154), we should start considering changes to the top-level API shape, and decide on something ASAP. I can imagine three possibilities: 1. `document.customElements.define`. Everything goes on that object. `document.customElements` is null for documents without a browsing context. 2. `HTMLElement.define`. This makes it a bit clearer things are tied to the browsing context instead of the document. Other things can go there too. Right now the only things on there are a bunch of Node SHOUTY_CONSTANTS. 3. Punt on the problem: stick with `document.defineElement`, and just be sure to block future proposals on accepting one of the above two, at which point `document.defineElement` becomes an alias for one of those. This might not be feasible depending on how #419 goes. @annevk @rniwa @travisleithead thoughts? --- Reply to this email directly or view it on GitHub: https://github.com/w3c/webcomponents/issues/431
Received on Friday, 11 March 2016 00:42:44 UTC