Another view (sorry) on XBL and behaviours

I've quite given up trying to follow the main thread on XBL, which seems to
have descended into meta-argument, recrimination and irrelevance. However,
I would nonetheless like to air my opinions on XBL and the idea of behaviours
in general, if anyone is still listening.

XBL files (as HTCs in IE) provide a layer of encapsulation that may be
useful to some programmers. However, they do not themselves provide any
real extra functionality; everything that can be done with them could be
done with a little extra inconvenience using plain [Java|J|ECMA]Script,
coupled with DOM Level 2 Events.

In my opinion, this sort of architectural helping hand does not need to be
a web standard. Requiring added complexity of all WWW user agents in order
to make authors' lives slightly easier does not make sense. I'm not
criticising Mozilla here: XBL is a fine feature for a browser to have,
and a great way to implement internal browser features. But does that mean
the W3C should call it a standard and ask other implementors to support it?
I don't believe so.

There is one other facet to behaviours which is actually a bit of a
separate issue, but tends to be taken as read when discussing them: the
binding of XBL (or HTC) files to elements using CSS selectors. This is the
one feature of the XBL and BeCSS standards that can't be done using standard
scripting and event handling methods, and it's very useful.

However, the current way CSS selectors are leveraged is through adding an
extra property to standard CSS stylesheets (-moz-binding in Mozilla,
behavior in IE). This is very easy, very practical, and architecturally
absolutely terrible. Behavioural/scripting information is about much more
than style, and should not be mixed with styling.

>From a security point of view, allowing links to active content in styles is 
dangerous. Stylesheets are expected by many to be free of active content,
and are allowed in places such as user-submitted content, HTML e-mail etc.
where active content is unacceptable. Many applications may wish to allow
styling through, but not scripting; expecting them to include a full CSS
parser, as well as understand the browser quirks in CSS parsing, to be
able to filter out the scripting information, is unrealistic.

IE's dreadful "property: expression(alert('scripting!'));" extension to CSS
has already caused hundreds of cross-site scripting bugs in real web
applications; the 'behavior' and 'binding' properties threaten to create
even more. Please do not provide more new places to hide scripting in
non-script content.

So what is the alternative? Simple, just provide a way CSS selectors (or
similar - XPath selectors would be just as good) to be leveraged from script,
that does not involve actual CSS stylesheets. An example way this could be
done:

  function myclick(e) {
    alert('You clicked on a <div class="foo">!');
  }

  function binder(e) {
    if (e.type=='bind')
      e.target.addEventListener('click', myclick, false);
    if (e.type=='unbind')
      e.target.removeEventListener('click', myclick);
  }

  document.addSelectorListener('div.foo', binder);

In this example, the function binder would be called every time an element
matches the selector 'div.foo'. So on calling addSelectorListener, binder
will be called once for each existing <div> element with class="foo", and
it'll be called again if a new <div class="foo"> is loaded, or a <div> has
its class changed to include "foo", and so on.

Using a method something like this, multiple behaviours could be bound to
elements easily by encapsulated scripts, with no need for further formats or
encroachment onto styling.

-- 
Andrew Clover
mailto:and@doxdesk.com
http://www.doxdesk.com/

Received on Monday, 6 January 2003 09:21:52 UTC