Re: Another view (sorry) on XBL and behaviours

Hixie wrote:

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

No, I can see exactly how much they do. For exactly that reason, their
complexity, I feel opposed to their being a 'standard'. They're a great
feature for Mozilla, which is after all more than a web browser, but not
something that all UAs should be compelled to implement IMO.

The ability to bind code to elements through selectors is the one
'capability' I see in XBL/HTC; the rest is 'architecture'.

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

I agree that this is desirable, but I don't think XBL as is stands is really
capable of this. Unless I am mistaken and there is some special mechanism for
this, the binding property is not additive, so if the user specifies:

  input[type=submit] { binding: url(mySubmitButtons.xbl) !important; }

this will override any other value of the binding property specified by
authors on any submit input. And this will more likely than not break
web pages, for example form validation actions based on button presses.[1]

We see minor problems like this with CSS already, where user and author
stylesheets clash to make some pages hard to read; the problem can only
be amplified when scripts are involved, as interaction between programmatical
elements is naturally more complicated than declarative ones.

My preferred solution would be to allow user scripts as well as user
stylesheets. A user could specify that all pages with [X]HTML doctypes
have a script called, that might attach the necessary event handlers to
make buttons respond to keyboard access.

> 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

As far as I can see the only reason this would be difficult would be that
a script cannot generally be told when an element matching a selector has
entered or left the document (or has been mutated). An approach such as
the addSelectorListener method I proposed in the previous post would make
this reasonably easy. I've certainly written document-folding scripts that
do almost exactly what you mention before, just with the limitation that
extra elements added to the page after the script has been initialised
are not bound.

I believe it would be possible for a script to monitor document changes
like this to provoke bind/unbind requests using standard DOM Mutation
Events. But performance would be terrible and one would still have to
write a CSS selector matcher in JS... it would make more sense to give
scripts access to a browser's own CSS selector implementation.

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

Fully quoted because I fully agree! :-) I have been trying to move all
my code towards strictly separated content, styling and optional behaviour
for a long time and find this approach very much beneficial. DOM Events,
with their allowance of multiple event handlers, was the biggest step
towards allowing all different aspects of behaviour to be encapsulated
in separate .js files; the only obstacle that remains to getting rid of
inline event handlers for me is the binding of elements to script, when
those elements are dynamic or have not yet been loaded into the page.
My own event.js script[2] provides a jerry-rigged solution to the latter
problem, but it would be much better if browsers could simply tell scripts
when elements they are interested in are added/removed/mutated.

I disagree with the implication, though, that behaviour is purely
presentational. It's active, scripting content, which is something
different. Some uses of behaviour might only be presentational, but
not all are, just as not all <script>s are presentational.

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

This is a useful idea, and one that has been suggested in a number of
forms in www-html in the past. There are practical considerations...
for example, an attacker could attempt to put a close-tag in the submitted
content to end the no-scripting tag early and proceed to insert malicious
code. It is easier to sneak tags through content filters than most
authors think.[3]

There are ways to stop this of course, but nothing suggested so far looks
really elegant. I would prefer to reduce the number of in-roads for
scripting content, by deprecation. Ideally, we should only be left with
<link rel="script">, which is easy to filter, particularly since it is
only valid in <head>. Or some equivalent in non-HTML XML doctypes.[4]
If an external script can easily bind to document elements, there is
no need for any other method of scripting injection.

> However, the fact of the matter is that sites _already_ have to deal
> with this problem

True, and very annoying. I've got a huge list of script injection
techniques and the vast majority of sites I've tested have been
vulnerable to cross-site scripting in some way. However there is a
difference between the positions -

 1. script filtering is a very difficult and complicated problem,
    due to non-standard browser extensions and parsing errors

 2. script filtering is essentially impossible for all but the
    most rigidly limited forms of HTML due to design decisions
    made at W3C

Maybe it is just the idealist geek in me speaking, but conceptually I
prefer option 1.

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

Yes, however in this case the SVG script will have no access to the
object model of the parent document. (I *hope* this is actually
true, anyway, or users are in trouble...)

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

Do you think it would be worth making a more concrete proposal? I've
been wanting functionality like this for a long time.

Mind you, I'm still waiting for IE to implement DOM 2 Events...

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

I don't believe so... because J.*Script is a full scripting language
there's nothing to stop you doing:

  bindings= {
    'input[type=submit]': {
      'click': myclickfn,
      'keypress': mykeypressfn,
    'select': {
      'click': myselectclickfn,

With suitable read-and-call-binding loop. Or some other less CSS-like
strategy involving objects or whatever. This is an architectural
decision; I prefer architecture to be left to authors.

[1] We all know form validation should happen through <form onsubmit> of
    course, but many authors apparently don't. ;-)


[3] The UTF-8 illegal-character-encoding bug allows one to slip an angle
    bracket through to IE and Opera 6 at least, and has received very
    little coverage on the usual security fora.

[4] In particular, javascript: pseudo-URLs are a disaster in every way
    and should be deprecated *right now*. They offer no functionality over
    event handlers and serious usability disadvantages, not to mention the
    innumerable browser security holes they have caused. Whoever @Netscape
    invented these little blighters ought to be publically custard pied.

[5] Damn it, I've ended up waffling on for just as long as some of the
    impenetrable messages in the first thread...

Andrew Clover

Received on Tuesday, 7 January 2003 12:13:44 UTC