Re: [webcomponents] Considering declarative event handlers

On Tue, Feb 7, 2012 at 12:05 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 2/7/12 2:41 PM, Dimitri Glazkov wrote:
>>
>> <div class="overflow">
>>     <script event="click">
>>         // "this" is the parent div element.
>>         // "event" is the current event object.
>>         if (event.target.className != 'more')
>>             return;
>>         if (this.moreOpened)
>>             this.closeMore();
>>        ...
>>     </script>
>> </div>
>
>
> This looks an awful lot like what XBL does (it uses <handler> elements for
> this).
>
> People had some issues with this, which is why XBL2 had moved to a single
> script blob that just set things like the onclick attribute.
>
> I assume you've looked into what these issues were?  At least ask hyatt and
> hixie, please.

That's what I was hoping to do by posting :)

>
>
>> * It's declarative and intuitively logical
>> * The script does not have to run (or even compile) until event fires
>> * The author does not need to imperatively go find the element in the
>> tree to attach an event handler to it
>
>
> #3 is achievable with other approaches (e.g. just having a <script> that
> runs with "this" set to the element in question or something).

Oh, like <script scoped> or something?

>
> #2 is true, but would be equally true with:
>
>  this.onclick = function() { .... }
>
> I think.  The only thing the UA would have to do there is syntax-check the
> function, which I think is desirable to do anyway for error reporting
> purposes.

I am pretty sure we'd have to run script there.

>
> -Boris
>

Received on Tuesday, 7 February 2012 20:29:33 UTC