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

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 21:55:37 UTC