- From: Dimitri Glazkov <dglazkov@chromium.org>
- Date: Tue, 7 Feb 2012 11:41:24 -0800
- 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 UTC