W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2015

Re: Minimum viable custom elements

From: Kenneth Rohde Christiansen <kenneth.christiansen@gmail.com>
Date: Thu, 15 Jan 2015 16:12:39 +0000
Message-ID: <CAEC208t2gWq6v3UMtTX9Z-81FXmZh7XTDoTC7=FaERhCWBG6EQ@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>, Dimitri Glazkov <dglazkov@google.com>
Cc: Domenic Denicola <d@domenic.me>, Erik Arvidsson <arv@google.com>, Boris Zbarsky <bzbarsky@mit.edu>, public-webapps <public-webapps@w3.org>
Anne, maybe you could write on the wiki what the current Web Components
implementation in Chrome is using. That would make it a bit easier to
follow for people who didn't follow all of the discussion so far.

Kenneth

On Thu Jan 15 2015 at 5:05:35 PM Anne van Kesteren <annevk@annevk.nl> wrote:

> 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:13:08 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:25 UTC