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

At 05:50 PM 12/30/2002 +0000, Ian Hicksonwrote:
>> 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.
>
>No offense but that _completely_ misses the point.


Which point is that exactly?


>Here you have a document fragment:
>
>   <foo size="1">
>    <bar> baz </bar>
>    <bar> quux </bar>
>   </foo>
>
>Make it so that when that document fragment appears in a graphical Web
>browser, it renders as a horizontal box with the width "quux", the height
>of one line, so that when you click on it you get a drop down box with
>the two items on it, so that when you hover over an item you get a hover
>effect, so that when you click on an item the value of the box changes and
>so that form submission and session history take this value into account.

I am very sure the above example can be done with a simply XSLT transformation.

You have done a good job in presenting a complex enough example, that I do
not have time to implement it right this minute.

I will be doing complex implementations, hopefully in January or February,
and I will come back here post some examples then.

At that time, you will eat your words.



>> Remember that XSLT is Turning complete [...]
>
>So is the brainfuck programming language [1], but that doesn't tell you
>ANYTHING about how useful the language is.


Being obscene is certainly dramatic, but it doesn't prove any thing
regarding whether the Turing complete capabilities can perform complex
examples such as the one you present above.

I doubt you've ever tried to implement the above example in XSLT.


>Turing complete does _not_ mean it can do anything -- XSLT cannot, for
>instance, add a new DOM interface to an element.


Of course it can.  It just won't be a W3C standard DOM.  Neither are the
XBL extensions.

Making extensions to DOM to accomplish binding is silly non-orthogonal design.


>And nor should it, because XSLT and XBL solve different problems.


What specifically is the problem solved by XBL, which is not also solved by
XSLT??

Remember we are not talking about XUL.   Be careful with your answer.

I am still waiting for someone to show me something that XBL can do that
XSLT can not do.



>Here are a couple of other problems that XBL can do but which XSLT cannot,


False.  See below.


>or cannot do as neatly:


Ah so there is the main point.  One person's opinion of "neat" (I used that
exact word in previous post), is another person's opinion of
non-orthogonal, dead-end design.

This point does not refute my original assertions that "XBL is (mostly) W3C
redundant" and "CSS is wrong layer for semantic (binding)".

I have no problem with people that want to use XBL because they thing is
more "neat".  At their own peril for future interoperability...



>   1. The header on http://www.hixie.ch/, in Mozilla, drops down a menu
>      when you click on it, without affecting the document's DOM.



XSLT can make transformations to accomplish this abstract markup of <H?> tags.


>      Can you do this in XSLT in a ways that is as understandable and
>      simple?


Folly to debate personal preference.  One thing to note is that personal
preference is enabled by orthogonal layers, and *NOT* mutually excluded.
However, non-orthogonal layers (even if they may be "neat") do exclude
personal preference some where down the line.



> Can you do it without requiring me to change every page on
>      my entire domain? (The binding [2] is linked in using a single rule
>      in a site stylesheet. This is appropriate, because the menu is
>      purely stylistic and adds nothing of value to the document.)


Yes.  You need to study XSLT spec.


>   2. The times next to the posts on http://ln.hixie.ch/ are, in the
>      markup, served as times in UTC. Using XBL [3], the times are
>      displayed in the local time zone.
>
>      Can you do this is XSLT at all?


Of course this is very easy.  You would just enclose the time content in
custom tag of name yuo choose such as <timezone>2002-12-27 23:21 UTC</timezone>

The similar transformation to what you have in your binding.

And then your page would run on ALL browsers.  I can't believe that you
would make your web page only run properly on Mozilla with it's miniscule
usage.  I guess you only expect visitors from your Mozilla friends.  It is
a small world after all.



>> Also remember that we are comparing XSLT and XBL, not XUL. 
>
>XSLT, XBL and XUL are three, IMHO, totally orthogonal languages.


Agreed as set.

But XBL is not orthogonal to DOM and CSS as explained in previous posts.
You can't have XBL unless you have those.  XSLT does not have this
weakness.  And XSLT runs on ALL browsers (server-side sniff for the 1%
Mozilla users).



>XUL is simple a markup language like CSS; it doesn't require any other
>language, but typically CSS and XBL are used to specify the rendering.


XUL mainly adds menubars and other predefined widgets.  I have not making
any points about XUL.  It is orthogonal to this discussion.


>XBL is an extension to the DOM and to CSS.


*THAT* is the main point.  *THAT* is the main problem with XBL.  And we
already have XSLT so we don't need XBL.



> These are two separate roles.
>In its role as an extension to the DOM, it allows individual elements to
>be extended to support new interfaces.


This is not entirely complete.  And I do not have time to debate it.  For
sure you can't separate XBL from DOM.  You need both in a UA that supports XBL.


> In its role as an extension to CSS,
>it allows individual elements in the markup to have their children
>reordered and wrapped,


XSLT can reorder and wrap.  It is necessary for transformations of style to
XSL-FO.


> so that CSS has more elements to play with, and
>allows elements to have script associated with them to give dynamic
>behaviours to them.


You are taking CSS from an elegant, thin, orthogonal layer, and merging it
with things that are better left orthogonal so that we can mix and match.

From my very first post, I wrote that the issue of whether CSS style is
applied at the abstract markup level (XBL) or at the implementation level
(post XSLT transform) is a crucial distinction between XBL and XSLT methods.

When you merge CSS layer with the binding layer, then you loose orthogonality.

If you want a higher level abstraction of style than CSS for custom markup,
then use XSLT and define a new set of appropriate styles (such as XSL-FO).
CSS was not designed for high level abstraction.  You are going to
basterdize it and make it brittle and too broad and too complex.

Keep the layers thin and orthogonal.  That is proper OO design principle.



> Behaviours are not semantic --


EXACTLY!  That is why you don't want to merge binding and behaviors.  Have
you not read my previous posts (mentioned several times about handler being
concrete syntax of XBL)?


> a radio button need not
>change colour when it is being clicked, and it need not be a single round
>button, it could be toggle switch. XBL allows you to map the semantics
>(radio button) to a style and behaviour (animated push switch that
>requires you to double click it).


XSLT allows you to map also to swappable style and behavior.

The *KEY* difference that XSLT does not dictate what layer you used for
style and behavior (events).  You are not locked into a non-orthogonal
merged mix.  You are free to mix and adapt to changes in future.


>XSLT is a document tranformation language, designed to take an entire
>document and replace it with another.


That is what semantic binding is.  XSLT was created primary to map a
semantic document into a styled one (XSL-FO).


> It is not dynamic, and addresses a
>totally different problem space.


You are thinking non-orthogonally.  You assume that the binding layer must
dictate the style and handler (behavior) layer.  XSLT does not prevent
binding to style and behavior.  It also does not dictate it.  It does not
flatten 3 layers into one inseparable one.


-Shelby Moore


>-- References --
>[1] http://www.muppetlabs.com/~breadbox/bf/
>[2] http://www.hixie.ch/resources/bindings/sites.xml
>[3] http://ln.hixie.ch/resources/bindings/timezone.xml

Received on Monday, 30 December 2002 21:03:23 UTC