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

At 10:06 AM 12/30/2002 -0500, L. David Baronwrote:

[...]

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


I will disagree below...


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


Agreed in theory, but note specifically that XSLT was created to transform
semantic documents into styled (implementation specific) ones.

You are steering the debate into one of personal preference.  See my
previous post in response to Ian Hickson:

http://lists.w3.org/Archives/Public/www-style/2002Dec/0224.html

"Folly to debate personal preference. One thing to note is that personal
preference is enabled by orthogonal layers..."


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


I am not debating against XUL.  I am just not expert enough at XUL (yet) to
make fair comparison examples to ones that use XUL.

I want to consider XBL by itself (orthogonally).


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


I would never propose merging the binding (transformation) with the
behavior (events).  In fact, that is one of my criticisms against XBL (that
it merges layers and is thus not orthogonal).

Dynamic updating is either handled by UA (semantic extension) or thru
scripting of the transformed implementation tree.



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


False.  XSLT makes no additional limitations that aren't already in XML.
XSLT can map each instance into a different namespace, although that
wouldn't be the prefered solutions.  Instead, making scripting of events
orthogonal to markup is for example one of the goals of XEvents.

The beauty of XSLT is you can mix and match as the future unfolds.


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


Namespace issues have been addressed in XML and other standards coming such
as XEvents.


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


I refuted your 2 points above.  The CSS display property and other
scripting of DOM (CSS, HTML, XHTML, XUL, ...Views and Formatting,..) or any
swappable (orthogonal) improvement of future.

Note that XBL also relies on scripting.  If you are referring the handler
methods embedded in the syntax.  That is one of my criticisms of XBL.  It
merges the event layers with the binding layer.  XEvents (as one
possibility out of many) can accomplish similar modularity without
defeating the "mix and match" for future.



>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)?


Coding dynamic web page is a constantly changing art.  Zillions of ways to
do dynamic coding.  See the elegant Tree Menu I did (afaik the only one in
world that is 100% Search Engine compatible):

http://coolpagehelp.com


[...]

>XSLT allows any initial transformation on the document.  However, we're
>talking about widgets that involve user interaction,

Folly to merge binding with behavior layer.


> and we need a way
>to define that interaction in a compartmentalized way


XEvents.


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

-Shelby Moore

Received on Monday, 30 December 2002 21:28:54 UTC