- From: Domenic Denicola <d@domenic.me>
- Date: Fri, 17 Jul 2015 18:35:38 +0000
- To: public-webapps <public-webapps@w3.org>
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
Received on Friday, 17 July 2015 18:36:08 UTC