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

Re: [webcomponents]: Moving custom element callbacks to prototype/instance

From: Scott Miles <sjmiles@google.com>
Date: Wed, 6 Mar 2013 14:20:35 -0800
Message-ID: <CAHbmOLYTvu56mEgWvRHD2UMcK5WuaPTAZXRott2+S3KMUJSaUw@mail.gmail.com>
To: Dimitri Glazkov <dglazkov@google.com>
Cc: public-webapps <public-webapps@w3.org>, Elliott Sprehn <esprehn@google.com>, Steve Orvell <sorvell@google.com>, Daniel Buchner <daniel@mozilla.com>, Adam Klein <adamk@google.com>, Hajime Morrita <morrita@google.com>, Blake Kaplan <mrbkap@mozilla.com>, William Chen <wchen@mozilla.com>
I favor #2. It's much simpler. Simple is good.

Fwiw, I'm filtering these things through the idea that someday we will be
able to do:

document.register("x-foo", XFoo);

That's the ultimate goal IMO, and when I channel Alex Russell (without
permission). =P

Scott


On Wed, Mar 6, 2013 at 1:55 PM, Dimitri Glazkov <dglazkov@google.com> wrote:

> A few of browser/webdev folks got together and went (again!) over the
> custom elements design. One problem stuck out: handling of "created"
> callbacks (and other future callbacks, by induction) for derived
> custom elements.
>
> For example, if Raj defined a "create" callback for his <foo-raj>
> element, and Lucy later extended <foo-raj> to make a <foo-lucy>
> element. As spec'd today, Lucy has no obvious way of invoking Raj's
> "create" callback, other than Raj and Lucy coming up with some
> convention on how to collect and pass these callbacks.
>
> Rather than watch developers come up with multiple, subtly different
> such conventions, how can we, the browserfolk help? A couple of ideas:
>
> 1) Somehow magically chain "create" callbacks. In Lucy's case,
> <foo-lucy> will call both Raj's and Lucy's callbacks.
>
> Pros:
> * Magic is exciting
> * Callbacks are tucked away safely in their own object, unexposed to
> the consumer of custom elements.
>
> Cons:
> * Magic of calling callbacks can't be controlled by the author. If
> Lucy wants to override Raj's callback (or call it in the middle of her
> callback), she can't.
> * We're somewhat reinventing either prototype inheritance or event
> listener model just for these callbacks.
>
> 2) Get rid of a separate lifecycle object and just put the callbacks
> on the prototype object, similar to printCallback
> (
> http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jan/0259.html
> )
>
> Pros:
> * We make prototype inheritance do the work for us. Lucy can do
> whatevs with Raj's callback.
> * No magic, no special callback interface.
>
> Cons:
> * The callbacks now hang out in the wind as prototype members. Foolish
> people can invoke them, inspectors show them, etc.
>
> I am leaning toward the second solution, but wanted to get your opinions.
>
> :DG<
>
Received on Wednesday, 6 March 2013 22:21:03 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:57 GMT