Re: [webcomponents]: Of weird script elements and Benadryl

>> The callbacks are convenient because (1) there is no question of 'who
registers a listener' (2) I can simply call my 'super' callback (or not) to
get inherited behavior.<<

One minute later, these seem like bad reasons. I shouldn't have shot from
the hip, let me do some research.


On Mon, Apr 15, 2013 at 9:44 AM, Scott Miles <sjmiles@google.com> wrote:

> >> Why do the constructors of component instances run during component
> loading?
>
> I'm not sure what you are referring to. What does 'component loading' mean?
>
> >> Why not use standard events rather than callbacks?
>
> This was discussed quite a bit, here is my off-the-cuff response. I may
> have to do archaeology to get a better one.
>
> Custom elements can inherit from custom elements. The callbacks are
> convenient because (1) there is no question of 'who registers a listener'
> (2) I can simply call my 'super' callback (or not) to get inherited
> behavior.
>
> IIRC, it is also advantageous for performance and for having control over
> the timing these calls.
>
> Scott
>
>
> On Mon, Apr 15, 2013 at 9:37 AM, John J Barton <
> johnjbarton@johnjbarton.com> wrote:
>
>> Why do the constructors of component instances run during component
>> loading?
>>
>> Why not use standard events rather than callbacks?
>>
>> Thanks,
>> jjb
>> On Apr 15, 2013 9:04 AM, "Scott Miles" <sjmiles@google.com> wrote:
>>
>>> Again, 'readyCallback' exists because it's a Bad Idea to run user code
>>> during parsing (tree construction). Ready-time is not the same as
>>> construct-time.
>>>
>>> This is the Pinocchio problem:
>>> http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0728.html
>>>
>>> Scott
>>>
>>>
>>> On Mon, Apr 15, 2013 at 7:45 AM, Rick Waldron <waldron.rick@gmail.com>wrote:
>>>
>>>>
>>>>
>>>>
>>>> On Mon, Apr 15, 2013 at 8:57 AM, Boris Zbarsky <bzbarsky@mit.edu>wrote:
>>>>
>>>>> On 4/14/13 5:35 PM, Rick Waldron wrote:
>>>>>
>>>>>> I have a better understanding of problem caused by these generated
>>>>>> HTML*Element constructors: they aren't constructable.
>>>>>>
>>>>>
>>>>> I'd like to understand what's meant here.  I have a good understanding
>>>>> of how these constructors work in Gecko+SpiderMonkey, but I'm not sure what
>>>>> the lacking bit is, other than the fact that they have to create JS objects
>>>>> that have special state associated with them, so can't work with an object
>>>>> created by the [[Construct]] of a typical function.
>>>>>
>>>>> Is that what you're referring to, or something else?
>>>>
>>>>
>>>> Sorry, I should've been more specific. What I meant was that:
>>>>
>>>> new HTMLButtonElement();
>>>>
>>>> Doesn't construct an HTMLButtonElement, it throws with an "illegal
>>>> constructor" in Chrome and "HTMLButtonElement is not a constructor" in
>>>> Firefox (I'm sure this is the same across other browsers)
>>>>
>>>> Which of course means that this is not possible even today:
>>>>
>>>> function Smile() {
>>>>   HTMLButtonElement.call(this);
>>>>   this.textContent = ":)";
>>>> }
>>>>
>>>> Smile.prototype = Object.create(HTMLButtonElement.prototype);
>>>>
>>>>
>>>> Since this doesn't work, the prototype method named "readyCallback" was
>>>> invented as a bolt-on stand-in for the actual [[Construct]]
>>>>
>>>> Hopefully that clarifies?
>>>>
>>>> Rick
>>>>
>>>>
>>>> PS. A bit of trivial... A long time ago some users requested that
>>>> jQuery facilitate a custom constructor; to make this work, John put the
>>>> actual constructor code in a prototype method called "init" and set that
>>>> method's prototype to jQuery's own prototype. The thing called
>>>> "readyCallback" is similar. For those that are interested, I created a gist
>>>> with a minimal illustration here:
>>>> https://gist.github.com/rwldrn/5388544
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>> -Boris
>>>>>
>>>>
>>>>
>>>
>