Re: Another view (sorry) on XBL and behaviours

On Mon, 6 Jan 2003, Andrew Clover wrote:
> 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.

XBL and HTCs actually provide a solid basis for increasing accessibility,
because of their unique ability to bind behavioural abilities at the user
stylesheet level.

For example, a user could bind all buttons to a binding that was carefully
designed to provide keyboard access (or whatever the user needs), and then
specifically override any author bindings that try to change the behaviour
of buttons.

Or, to take an example from the other thread, if authors start using
bindings to override <select> elements to submit on a "change" event
(something I think many authors would be eager to do), then users can
override this behaviour with their own binding that doesn't submit until
the user presses the submit button.

Naturally, most users would not be expected to write their own bindings
and user stylesheets; this is where user agents are expected to innovate
exciting new interfaces to provide the ability without explaining how it
works at the CSS and XBL level.

> Requiring added complexity of all WWW user agents in order to make
> authors' lives slightly easier does not make sense.

I think you underestimate the amount of help XBL and HTCs can provide.

Many of the abilities that DOM3 is introducing can be implemented in terms
of the DOM2 or even DOM1 APIs, but they are still worth developing because
ideally the amount of scripting on the Web should be kept to a strict

The same applies to XBL: I have written, using a few lines of XBL, things
that if they required pure scripting would have taken me hundreds of lines
(and would therefore not have been done).

Also, note that some aspects of XBL are distinctly non-trivial to
implement at the top level using script. For example, adding an <li>
element dynamically to an <nl> element may need quite significant code to
deal with if the binding involves lots of anonymous content. However, with
XBL, that is completely handled by the technology.

> 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.

Note that I don't suggest that the W3C take XBL as is and stamp it with
the "W3C approved" label. XBL is, in my opinion, a great technology, but
it can be improved.

> 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.

Bindings are very much designed to be a stylistic layer. For example, the
XHTML2 <nl> element is an ideal candididate for XBL. There are multiple
ways to implement it, and each one differs only in its style and
behaviour, while all being dynamic navigation lists.

On large sites, it is hoped that it will become typical to find the
presentation aspect controlled by one person or team, and the content by a
separate person or team. In this scenario, it is important that changing
the behaviour of <nl> elements, or other interactive but purely
presentational aspects of the site, only require changes to the
stylesheet(s) and not the content.

Some XBL is completely script-free, some consist of only scripting. I
think it would be rather unfortunate to have to add a layer of scripting
purely in order to bind a script-free binding.

> 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.

This is a very valid concern, and is very much of interest to me.

There are several possible solutions.

One is to suggest to the XML team that a new attribute be introduced,
xml:scripting or some such, which could indicate that everything from that
element and deeper should be unable to execute associated script.

For example:

   <object xml:scripting="disable" data="e-mail"/>

It could also be called xml:tainting, or xml:contenttrusted, or something.
The idea is that the scripting would require that everything up to its top
level parent be marked as scripting enabled in order for some script to

Another possible solution is to introduce some way of overriding style at
a higher level, so that embedding content could force 'binding' to 'none'
on the element and all its children.

However, the fact of the matter is that sites _already_ have to deal with
this problem, first because of IE's various (IMHO quite intruiging)
features, second because of Mozilla's '-moz-binding' property, and thirdly
because of the ability to do things like:

   p { background: url('data:text/html,<script> ... </script>'); }

...or including SVG as background images (SVG images can be scripted).

I don't see XBL as introducing a larger security hole -- in fact I see its
standardisation as bringing to the table a problem which has been ignored
for too long.

> 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')
>'click', myclick, false);
>     if (e.type=='unbind')
>'click', myclick);
>   }
>   document.addSelectorListener('', binder);

This is a very interesting idea, and definitely one worth persuing in the
context of DOM3 CSS.

> 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.

If you extend your example to what you'd have to do when binding a complex
one, the one line of CSS vs the dozens if not hundreds of lines of JS
becomes quite a convincing argument.

Ian Hickson                                      )\._.,--....,'``.    fL
"meow"                                          /,   _.. \   _\  ;`._ ,.                         `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 6 January 2003 11:26:19 UTC