Re: XBL is (mostly) W3C redundant, and CSS is wrong W3C layer for semantic behavior *markup*

On Monday 2002-12-30 03:11 -0600, Shelby Moore wrote:
> >From private discussion, I generated the following XSLT snippet which is
> concise example of XSLT's powerful capabilities to make general transforms
> from abstract markup to any desired implementation.  This translates a
> <select> into radio buttons.  I think that is fairly impressive for such a
> concise snippet.  Imagine the possibilites with only a few more lines!

I chose combobox intentionally because I think it's hard to do (well) in
XSLT.

> Remember that XSLT is Turning complete, so in theory *ANY* type of
> transformation is possible.  It is silly exercise to ask me to write
> complex transformations just to prove that XSLT is Turing complete.  That
> has already been proved.  Besides then we would argue over complexities
> which could make this the longest thread ever.

However, Turing completeness does not imply efficiency or ease of use.

> Also remember that we are comparing XSLT and XBL, not XUL.  Any XBL example
> that inherits from XUL is going to be more concise because XBL has been
> narrowly designed (optimized) for XUL extensions.  XUL could be used with
> XSLT transformations also.  XSLT is more general.

The reasons for using XUL in this case are that the boxes that have more
useful sizing rules and the popups are allowed to extend outside the
window in which the document is displayed.


An XSLT+DOM solution would have a number of problems that using this
extremely simple example rather than the combobox avoids:

 1. As I stated in [1], I have been told that it is difficult or
    impossible to update the results of XSLT transformations
    incrementally.  This means that *if* we were to use XSLT to handle
    the case where the user drops down the combobox and selects another
    item, the time taken would be O(N) in the length of the document.
    Users find performance like this unacceptable.

 2. We can't use scripting to handle the case of dropping down a
    combobox and selecting a different item (certainly not elegantly or
    in any human-readable manner) since insertion of any script into the
    document by the transformation would add script that is in the same
    namespace as any other script already in the document.  Additional
    namespace collisions (with non-standardized functions, anyway, where
    we don't have a good reason) break existing web pages that use
    functions with those names.

These two points say that it's unacceptable to use either XSLT or
scripting of the DOM to do the retransformation necessary to handle a
change in which item is selected (which involves placing a copy of the
selected item in the "window" next to the dropdown that shows the entire
list).  So how is it done?

Likewise, without the use of functions in script that would appear in
the global namespace, how would you handle all the key events in a way
that allows the necessary movement in the dropped-down list (up and down
arrows, and pressing the first letters of items to jump to those items)?

In other words, the key advantages of XBL over your proposed solution
(as I understand it, although you haven't described how you would
implement the parts of the combobox widget that I described problems
with) are:
 1. The ability to do partial retransformation efficiently when needed
    for incremental updating.
 2. The provision of a private namespace for scripts.

XSLT allows any initial transformation on the document.  However, we're
talking about widgets that involve user interaction, and we need a way
to define that interaction in a compartmentalized way -- without
affecting the rest of the document, and without requiring
retransformation of the entire document.  Otherwise we end up with a
tangle of scripts that can't use any of the same function names.

-David

[1] http://lists.w3.org/Archives/Public/www-style/2002Dec/0192.html

-- 
L. David Baron        <URL: http://www.people.fas.harvard.edu/~dbaron/ >

Received on Monday, 30 December 2002 10:07:03 UTC