- From: Giovanni Campagna <scampa.giovanni@gmail.com>
- Date: Mon, 2 Feb 2009 20:23:11 +0100
- To: www-html@w3.org
I, as a web developer, have faced many times a difficult problem: how to attach some events to a whole set of elements, to reproduce what the HTML working group calls "extensibility" using classes or complex selectors? This also concerns the so called widget libraries (eg the Yahoo! UI or the MooTools) I currently can use: 1) document.querySelectorAll or document.evaluate, then cycle all the nodes and apply addEventListener: but this has two problems: - it is JS, so it is optimizable but most of time it is amazingly slow - I need to rerun it every time some elements are inserted into the document 2) XBL2 but this is exactly the topic of my mail: XBL is too complex for the developer: the CSS inheritance system is difficult to understand, the process of building the resulting tree, with shadow trees applied, can be even worse. And since trees are fundamental in many situations (like the DOM event model) but it is definetely necessary to define a processing model that is understandable to the masses of web developers that will to use widgets. Yes, XBL2 is ideal for the widget user, but it is horrible for the developer. Not talking of implementors: having to deal with dynamic mutations of the document tree, outside of JS, can be horrible, also considering that these mutations affect the DOM event tree, but not the DOM traversal tree (that using for DOM2TR, DOM3Core, XPath and Selectors matching) Other proposals to address the widget use cases (Netscape Actionsheets, Microsoft HTML Components) never talked about shadow trees: is it possible to declaratively assign a set of event handlers, without having to deal with complex tree rearrangements? I think that it is possible with a simple modification: allow the <listener> element to accept any CSS selector or XPath expression in the "observer" attribute, so that every matching element gets that events applied. I would prefer the former syntax, it is easier for author and backward compatible with XMLEvents 1.0 syntax (all id selectors), but XPath is already used in the spec. Side note: I think that the resource identified by the "handler" should be either an <action> elements or something implementing the EventListener interface [DOM2Events], in a binding specific way, but we should not allow for everything to be an handler. Giovanni
Received on Monday, 2 February 2009 19:26:44 UTC