Re: Another view (sorry) on XBL and behaviours

I had signed off the list, but Ian cc:ed his post to me.  Initially I thought I
would just reply privately, but then I realized it would be construed as me
admitting I agreed with his points below.

I am going to refute Ian succinctly below.  I have no doubt that he will reply
and "ask for examples" and otherwise try to encourage extended, detailed debate
on each point.  However, the list has spoken and told me that they do not want
me making so many details posts.  So this is REALLY my final response on this
issue.  I hope people will evaluate my points on their own merits and not just
because I do not answer every point of Ians.

Fundamentally, the issue is not about details.  It is about overall design
philosophies for the web and standards.  Please see instead my Shelby's Final
Position Paper on XBL:

http://lists.w3.org/Archives/Public/www-style/2003Jan/0147.html

That paper and the main point of Andrew Clover initial post of this thread are
the crux of what people need to think about when they decide whether to support
or protest XBL as a standard.

No matter what is the response to this post, I will be unsubscribed and please
do NOT cc me.  I wish every one good luck in reaching the optimal designs.


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

CSS author sheets can be overridden because of cascade.  Similar mechanisms can
be created if desired for substituting XSLT transformations. 

I envision libraries of XSLT transformations produced not by a "few"
programmers at Mozilla (UA) but by the world of programmers.


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


This is undesireable.

See the long thread for my reasoning.

This is a very philosophical point, so I do not think it can be debate in
linear nature of email.  Save it for a conference to explore fully.


>   * Bind event handlers and styles to an element without affecting
>     the original DOM.


See my Shelby's Final Proposal on XBL.  Having the compliant markup in the DOM
instead of anonymous is desireable.



>   * Allow individual elements to have bindings changed dynamically.


You are referring mainly to the DOM extensions of XBL.  Or to the merging of
CSS selection or pseudo states with XBL.  Again I am against merging standards.


>   * Allow multiple bindings to be added to the same element
>     simultaneously.


Yeah like multiple XSLT transforms casacaded.



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


>   * Bind stylesheets to subtrees of the document without affecting
>     any other elements.


CSS has selectors for selecting the transformed document.


>   * Bind event handlers and styles to an element from the style
>     layer.


I also proposed that XEvents should have a CSS-selector like capability. 
XEvents is not merged with the other aspects of XBL.


-Shelby Moore

Received on Monday, 6 January 2003 14:02:29 UTC