Re: [webcomponents] Considering declarative event handlers

On Tue, Feb 7, 2012 at 2:41 PM, Dimitri Glazkov <dglazkov@chromium.org>wrote:

> Folks,
>
> To make Web Components more usable, I would like to consider providing
> a way to declare event handlers in markup. As I look over the use
> cases and try to implement them using the proposed syntax
> (http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html),
> a pattern emerges, where a bunch of event handlers is declared and
> registered early in the lifecycle of the custom elements
> (
> http://dvcs.w3.org/hg/webcomponents/raw-file/tip/samples/entry-helper.html
> ,
> http://dglazkov.github.com/Tabs/tabs-control.js as rough examples).
>
> Even thought it's a perfectly workable solution, it also implies that
> we must run script in order to just write up the events. However,
> given that the <template> element takes care of setting up the initial
> state of the shadow DOM subtree for the custom element, in many
> controls, the only script that runs during initialization will be just
> wiring up events.
>
> It seems that we can do better. Consider this inspirational example
> (loosely reimagines Internet Explorer's existing functionality
> http://msdn.microsoft.com/en-us/library/ms533746(v=vs.85).aspx):
>
> <element name="x-tab-manager">
> <template>
> <div class="container">
> ...
> <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 directly contradicts "separation of concern" and promotes coupling
logic with presentation. public-webapps should be defined way to avoid
those practices, not encourage them.

Rick








> ...
>
> </div>
> </template>
> </element>
>
> In other words, this imaginary new thing will operate similarly to the
> <style scoped>, where it registers an event handler on the parent
> element of its declaration.
>
> The pros are:
> * 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
>
> The cons are:
> * It's a new syntax
> * It doesn't allow to close over the event handler code, which is a
> common way to manage variable scoping in JS.
>
> I would appreciate any thoughts, ideas, or results of existing
> research on this. I am sure someone had thought about this harder and
> longer than I did.
>
> :DG<
>
>