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

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