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
On Wed, Mar 6, 2013 at 4:26 PM, Blake Kaplan wrote:
> On Wed, Mar 6, 2013 at 1:55 PM, Dimitri Glazkov wrote:
>> 1) Somehow magically chain "create" callbacks. In Lucy's case,
>> will call both Raj's and Lucy's callbacks.
>> 2) Get rid of a separate lifecycle object and just put the callbacks
>>
On Wed, Mar 6, 2013 at 1:55 PM, Dimitri Glazkov 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 exampl
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 opt
On Thu, Mar 7, 2013 at 9:13 AM, Erik Arvidsson wrote:
> Inline
>
> On Wed, Mar 6, 2013 at 7:03 PM, Hajime Morrita 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 s
On Wed, Mar 6, 2013 at 1:55 PM, Dimitri Glazkov wrote:
> 1) Somehow magically chain "create" callbacks. In Lucy's case,
> 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:/
Inline
On Wed, Mar 6, 2013 at 7:03 PM, Hajime Morrita 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
>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 c
On Wed, Mar 6, 2013 at 2:20 PM, Scott Miles 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<
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, D
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
element, and Lucy la
11 matches
Mail list logo
