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].

 : 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.

 : 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 

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.


[1]: https://lists.w3.org/Archives/Public/public-webapps/2015JulSep/0159.html
[2]: https://lists.w3.org/Archives/Public/public-webapps/2015JulSep/0162.html

Reply via email to