Re: Another view (sorry) on XBL and behaviours

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

This is not quite true.  One difference that Ian has pointed out, for example,
is the ability for the user to override specific behaviors.  This ability is
provided by the encapsulation of behaviors into an external resource (an XBL
binding, eg) which is then somehow attached to an element.  This means that
overriding the behavior merely involves severing that attachment.

I do not see a good way for the user to override a web page's scripting of
<select> elements and nothing else if the script is just dumped into a <script>
tag on the page -- there is no way to tell which parts of the script are
relevant to <select> elements and which are not.

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

Sure it does.  That's been the trend for what? 10 years now?  Witness most of
the CSS selectors module.  All of that _could_ be done using the DOM and inline
style (eg treewalker).  Why is it not?  Convenience, imo ("separation of
content and presentation does not cut it; it would have been easy to just havea
simple syntax for "presentational script inclusion" or something like that).

> But does that mean the W3C should call it a standard and ask other
> implementors to support it?

That depends on how much need there is of such a feature... the fact that IE
and Mozilla have both felt they needed to implement something like it means
there must be _some_ demand.  The question is, how much.

(All these argument could also be made about <img> tags, and I would not be
surprised if they were made at some point in the past.  Ultimately, what
settled the inclusion of <img> in the standards was that it was 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.

So we should remove :hover and :active selectors from CSS?  (I'm not saying we
should not; just trying to clarify your position.)

The security issue you raise with bindings being allowed by things that want to
treat CSS as a black box is a good one, however...

Boris
-- 
Isn't it interesting that the same people who laugh at
science fiction listen to weather forecasts and
economists?
                          -- Kelvin Throop III

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