On Wed, Jan 14, 2015 at 9:52 PM, Dimitri Glazkov <dglaz...@google.com> wrote: > FWIW, I think that element upgrade is sort of fundamental to the usefulness > of custom elements. In a world where most scripts are non-blocking (that's > hopefully the modern world we should aim for), I'll effectively expect to > walk the tree anyway. > > And if I walk the tree anyway, what's the point of custom elements in the > first place? One of the key features (at least, to me) of custom elements > was being able to harness the HTML Parser to instantiate your object tree. > If that's not going happen consistently, then I am not sure custom elements > are worth the trouble. IOW, if you're walking the tree, just do the work of > callbacks as you encounter dash-separated elements.
My rationale is this: * Unlike you I think lifecycle callbacks are the main selling point of a custom element. They give you access to hooks that normal elements have but are not otherwise exposed. * I think we could iterate towards a v2 that has an aspect of upgrading but perhaps works a bit differently from the current setup. E.g. a way to include an entire subtree of custom elements with a fallback mechanism of sorts. Or perhaps something inspired by JavaScript modules. * Upgrading can be added, but moving from Brain transplants to a more normal working constructor would be impossible after the fact. Now, given the discussion so far, it does seem that synchronous or almost-synchronous constructors have a number of hard issues and it's not entirely clear to me anymore those are worth pushing over Brain transplant or Dummy replacement, using the terminology from: https://wiki.whatwg.org/wiki/CustomElements#Upgrading -- https://annevankesteren.nl/