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

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

From: Blake Kaplan <mrbkap@gmail.com>
Date: Wed, 6 Mar 2013 16:26:54 -0800
Message-ID: <CANTSQ3FW+Vpi-ni-VU3kFwMxKkc53BwNb1jh6ebe7y1qhtLYEA@mail.gmail.com>
To: Dimitri Glazkov <dglazkov@google.com>
Cc: public-webapps <public-webapps@w3.org>, Scott Miles <sjmiles@google.com>, 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>
On Wed, Mar 6, 2013 at 1:55 PM, Dimitri Glazkov <dglazkov@google.com> wrote:
> 1) Somehow magically chain "create" callbacks. In Lucy's case,
> <foo-lucy> will call both Raj's and Lucy's 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)

> I am leaning toward the second solution, but wanted to get your opinions.

I also like the second solution, but Hajime's point about the
mutability and general exposure of the lifecycle methods is a good
one. Is there a motivation for having the lifecycle objects on the
prototype as opposed to being passed in as an "ancestor" parameter?
XBL1, as I understand it, automatically calls the
constructor/destructor of "extended" bindings, but given the ad hoc
nature of web components' inheritance, it seems like it would be much
less surprising to make this stuff explicit *somewhere* (i.e. in the
actual components rather than in the engine).
-- 
Blake Kaplan
Received on Thursday, 7 March 2013 00:27:22 GMT

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