W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

[webcomponents] Considering declarative event handlers

From: Dimitri Glazkov <dglazkov@chromium.org>
Date: Tue, 7 Feb 2012 11:41:24 -0800
Message-ID: <CADh5Ky06zDko=vNPxoNadKi=eTCFt1oKL-KKrXicWhFED=CbPA@mail.gmail.com>
To: public-webapps <public-webapps@w3.org>
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>

...

</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<
Received on Tuesday, 7 February 2012 19:45:40 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:50 GMT