Re: Another view (sorry) on XBL and behaviours

On Mon, 6 Jan 2003, Shelby Moore wrote:
>> Unfortunately, XSLT cannot (to my knowledge):
>>
>>   * Allow the user to individually override bindings without
>>     completely overriding the author bindings.
> 
> There is no reason the UA couldn't provide this capability, as you are
> asking it to do for XBL.

I cannot see any way in which XSLT could be extended in this way. It
would be a major architectural change.

In addition, it seems silly to add to XSLT something which already
exists in CSS: After all, as you have yourself argued, it is important
to keep the specifications orthogonal.

This is something XBL does well: It leverages the existing
specifications, such as CSS and DOM, while only introducing the new
features which are needed to glue them together. (Much like HTML only
leverages CSS and DOM, while gluing them together with <style> and
<script>.)


> CSS author sheets can be overridden.  Similar mechanisms can be
> created if desired.

CSS author sheets can be overridden because the cascade is built into the
language (it's what the "C" in "CSS" stands for, after all).


>>   * Allow dynamic changes to the DOM to be reflected by the binding
>>     dynamically. 
> 
> This is undesireable.

It isn't so much undesirable as critical. Many Web pages depend on dynamic
changes of the content in order to provide their interface, e.g.
populating <select> elements through the DOM. If the binding technology
does not inherently support this, then authors will look to a technology
that can.


>>   * Bind event handlers and styles to an element without affecting
>>     the original DOM.
> 
> Having the compliant markup in the DOM instead of anonymous is
> desireable.

Again, this is an unrealistic expectation.

Content authors do not want to have to deal with knowing what bindings
will be applied to their markup when writing dynamic code.

If the content author wants to dynamically add <option> elements to a
<select> element, then he will not want to know that the style and
behaviour team of his group is planning on turning each <select> into a
deep nest of <div> elements in order to change the style.


>>   * Allow individual elements to have bindings changed dynamically. 
> 
> You are referring to the DOM extensions of XBL.

Not necessarily:

   code { binding: url(code.xml#brief); }
   code:hover { binding: url(code.xml#details); }

This is a powerful aspect of the integration of CSS (or any binding
language) and XBL.


The ability to dynamically change the binding itself is also important,
since it allows you to change the bindings of entire documents with only a
few DOM calls.


XSLT cannot do either of these things.


>>   * Allow multiple bindings to be added to the same element
>>     simultaneously.
>  
> Yeah like multiple XSLT transforms casacaded.

If one of the transforms changes the element to a tag name, for instance,
a later stylesheet would be unable to apply itself. The order of bindings
should not matter, whereas with XSLT it does.


>>   * Allow new functions to be defined in the scope of the bindings
>>     without _any_ pollution of the document namespace.
>  
> I already covered this in the long thread.  Functions are not need because
> of XEvents and use of non-named scoping blocks of Javascript.

This is unrealistic in the face of complex projects. Programmers should
not have to restrict their coding style merely to satisfy this
requirement.


>>   * Bind stylesheets to subtrees of the document without affecting
>>     any other elements. 
> 
> CSS has selectors for that.

CSS does not have selectors able to do this.

For example, there is no way to select only <p> elements that are
anonymous children of bindings.

XSLT makes it even harder to do this as it can remove the element being
bound altogether.


>>   * Bind event handlers and styles to an element from the style
>>     layer.
>  
> I also proposed that XEvents should have a CSS-selector like capability.

Why do you wish XEvents to have selector based bindings, but not XBL?
Their event handling aspects, with a few irrelevant syntactic differences,
are almost indistiguishable.

-- 
Ian Hickson                                      )\._.,--....,'``.    fL
"meow"                                          /,   _.. \   _\  ;`._ ,.
http://index.hixie.ch/                         `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 6 January 2003 15:02:18 UTC