Re: [webcomponents]: Moving custom element callbacks to prototype/instance
To close the loop: A bunch of Mozilla/Google peeps got together on Friday and discussed this. We came away with the conclusion that moving callbacks to the custom element prototype looks like the right thing. It's not without warts, but who is, amirite? I'll give spec'ing this out a shot and then we can iterate on this. :DG
Re: [webcomponents]: Moving custom element callbacks to prototype/instance
On Wed, Mar 6, 2013 at 1:55 PM, Dimitri Glazkov dglaz...@google.com wrote: Cons: * The callbacks now hang out in the wind as prototype members. Foolish people can invoke them, inspectors show them, etc. This con could get uncomfortably exciting if we try building HTML elements with custom elements. For example, today all WebKit forms controls use the equivalent of the insertedCallback to hook up with the form element. We could make these callbacks non-configurable so that enthusiastic authors don't get any ideas, but these same authors could still call them and wreak all kinds of havoc. :DG
Re: [webcomponents]: Moving custom element callbacks to prototype/instance
On Wed, Mar 6, 2013 at 4:26 PM, Blake Kaplan mrb...@gmail.com wrote: On Wed, Mar 6, 2013 at 1:55 PM, Dimitri Glazkov dglaz...@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). I think the idea of placing callbacks on the prototype was the simplest to do, given that prototype inheritance provides all the right machinery. If we deem this being a terrible idea, we'll need to fallback to something like passing ancestor. But then we'll be going against the grain of JS. :DG
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 dglaz...@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
Re: [webcomponents]: Moving custom element callbacks to prototype/instance
On Wed, Mar 6, 2013 at 2:20 PM, Scott Miles sjmi...@google.com wrote: That's the ultimate goal IMO, and when I channel Alex Russell (without permission). =P Don't we already have Fake Alex for that (https://twitter.com/FakeAlexRussell)? :DG
Re: [webcomponents]: Moving custom element callbacks to prototype/instance
From an implementors perspective: Putting such callbacks on the prototype object means that it can be changed, or even can be added after the element registration. This is different from a function parameter, which we can consider as a snapshot. One consequence is that it will become harder to cache (including negative cache) these values. We need to traverse the prototype chain in C++, which is typically slower than doing it in JS, on every lifecycle event. Or we need to invent something cool to make it fast. On Thu, Mar 7, 2013 at 7:29 AM, Dimitri Glazkov dglaz...@google.com wrote: On Wed, Mar 6, 2013 at 2:20 PM, Scott Miles sjmi...@google.com wrote: That's the ultimate goal IMO, and when I channel Alex Russell (without permission). =P Don't we already have Fake Alex for that ( https://twitter.com/FakeAlexRussell)? :DG -- morrita
Re: [webcomponents]: Moving custom element callbacks to prototype/instance
Inline On Wed, Mar 6, 2013 at 7:03 PM, Hajime Morrita morr...@google.com wrote: One consequence is that it will become harder to cache (including negative cache) these values. We need to traverse the prototype chain in C++, which is typically slower than doing it in JS, on every lifecycle event. Or we need to invent something cool to make it fast. There is no reason to walk the prototype chain from C++ (speaking from WebCore+V8/JS experience). You can invoke the method using the V8/JSC APIs. -- erik
Re: [webcomponents]: Moving custom element callbacks to prototype/instance
On Wed, Mar 6, 2013 at 1:55 PM, Dimitri Glazkov dglaz...@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
Re: [webcomponents]: Moving custom element callbacks to prototype/instance
On Thu, Mar 7, 2013 at 9:13 AM, Erik Arvidsson a...@chromium.org wrote: Inline On Wed, Mar 6, 2013 at 7:03 PM, Hajime Morrita morr...@google.com wrote: One consequence is that it will become harder to cache (including negative cache) these values. We need to traverse the prototype chain in C++, which is typically slower than doing it in JS, on every lifecycle event. Or we need to invent something cool to make it fast. There is no reason to walk the prototype chain from C++ (speaking from WebCore+V8/JS experience). You can invoke the method using the V8/JSC APIs. Right. We can just Get() can Call() it. Possible saving by caching these functions in C++ side is the Get() call then. -- erik -- morrita
Re: [webcomponents]: Moving custom element callbacks to prototype/instance
On 3/6/13 7:13 PM, Erik Arvidsson wrote: There is no reason to walk the prototype chain from C++ (speaking from WebCore+V8/JS experience). You can invoke the method using the V8/JSC APIs. This is just as slow as walking the proto chain, in the end, because it can't benefit from the various optimizations JITs do to not make this sort of thing slow. -Boris
