If the main draw of wanting custom constructors is to be able to interface with other custom elements that may not have been upgraded, maybe we could skip the custom constructor and all of its attached concerns altogether by adding some sort of 'elementUpgraded' event to the document that is fired as each custom element's createdCallback returns. Then custom elements could make use of any already upgraded elements during the createdCallback, and get notified as other elements become upgraded so they can respond appropriately.
I don't know if that had been pitched already or not but there it is. It might be simpler to implement than all of the constructor-related stuff. - Derek Gray > On Jul 17, 2015, at 1:38 PM, Domenic Denicola <d...@domenic.me> wrote: > > Hi all, > > Over the last few days I’ve worked on two new potential ideas for custom > elements, hoping to shake things up with new possibilities. These are both > largely geared around how we react to the key custom elements question [1]. > > https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Optional-Upgrades-Optional-Constructors.md > : this proposal assumes we come out in favor of running author code during > parsing/cloning/editing/etc. It allows component authors to choose between > using constructors, thus disallowing their components to be used with > server-side rendering/progressive enhancement, and using a > createdCallback-style two-stage initialization, which will then allow > progressive enhancement. It is meant explicitly as a compromise proposal, > similar in spirit to the { mode: "open"/"closed" } proposal, since we know > different parties have different values and the way forward may be to simply > accommodate both value systems and let developers light a path. > > https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Parser-Created-Constructors.md > : this proposal assumes we do not achieve consensus to run author code > during parsing/cloning/editing/etc. It recognizes that, if we disallow this, > we cannot allow custom constructors, and then tries to make the best of that > world. In particular, it is an alternative to the “Dmitry” proposal, designed > to entirely avoid the dreaded proto-swizzling, while still having many of the > same benefits. If you scroll to the bottom, you note how it also leaves the > door open for future custom constructors, if we decide that it's something > that we want in the future, but simply cannot afford to specify or implement > right now due to how hard that is. In this sense it's meant somewhat as a > bridging proposal, similar in spirit to the slots proposal, which falls short > of the ideal imperative distribution API but will probably work for most > developers anyway. > > These are largely meant to get ideas moving, and to avoid polarizing the > discussion into two camps. As I noted in [2], there are several degrees of > freedom here; the key custom elements question is distinct from upgrades, > which is distinct from ES2015 class syntax, which is distinct from > constructor vs. created lifecycle hook, etc. The possibility space is pretty > varied, and we have multiple tools in our toolbox to help arrive at a > resolution that everyone finds agreeable. > > Comments are of course welcome, and if you have time to read these before the > F2F that would be really appreciated. > > Thanks, > -Domenic > > [1]: https://lists.w3.org/Archives/Public/public-webapps/2015JulSep/0159.html > [2]: https://lists.w3.org/Archives/Public/public-webapps/2015JulSep/0162.html >
