Re: Minimum viable custom elements

On Wed, Jan 14, 2015 at 9:52 PM, Dimitri Glazkov <dglazkov@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/

Received on Thursday, 15 January 2015 16:03:29 UTC