W3C home > Mailing lists > Public > www-html@w3.org > February 2009

[XMLEvents2] A scripting-only alternative to XBL2

From: Giovanni Campagna <scampa.giovanni@gmail.com>
Date: Mon, 2 Feb 2009 20:23:11 +0100
Message-ID: <65307430902021123p334ef309lc8fb9848fd72698@mail.gmail.com>
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.

Received on Monday, 2 February 2009 19:26:44 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:06:21 UTC