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

On Tue, 31 Dec 2002, Shelby Moore wrote:
> 
>> [ snip a very example of XBL and a request for an example of how to
>> do the same using existing W3C technologies to demonstrate that XBL
>> is "W3C redundant" ]
> 
> What is the compelling use of such an example?

There is no compelling use of such an example.

I gave you a complex example with a real use case and sample XBL code,
you said it was too complicated for you to show us how to write the
equivalent in XSLT.

I gave you a real use case that is implemented in XBL that I use on my
Web site, you said it was possible to do the same in XSLT but told me
to go read the spec instead of asking you for the equivalent in XSLT.

I gave you a trivial example that is also a real use case that is
implemented in XBL, you told be that I should (a) change my markup and
(b) not ask for the feature because it was "not orthogonal".

I gave you a very simple example that only took me 30 minutes to write
from scratch in XBL, you told me that the example was not compelling.

Are you actually able to give _any_ example of XSLT doing the
equivalent of XBL?

Even just one of the above four cases would be a wonderful start.


The only XSLT you have provided us does something that has nothing to
do with XBL: changing one semantic element for another, without
defining any of the behaviour.


> Doesn't this example basically prove that XBL is non-orthogonal to
> the DOM, which I have already argued is bad design.

XBL is not orthogonal to the DOM. Indeed it is (amongst other things)
a way of creating now DOM interfaces for elements. Would it make it
more acceptable to you if XBL was called "DOM Level 3 Bindings"?


> You can disagree with me that orthogonality of DOM and XBL is
> important.

The entire _point_ of XBL is that it be a way of extending the DOM,
binding elements in the document tree to stylesheets, event handlers,
properties, methods, and content nodes.

It allows you to take a document tree, and augment it with
presentational behaviours without polluting the document tree, without
exposing style rules to unrelated elements, and without any impact on
the window's scripting namespace (something which is vitally important
in the real world).


> I have not studied it. Your description of it's function does not
> inspire me. I think my example to convert <select> to radio buttons
> was more inspiring.

Converting <select>/<option> elements to <input type="radio"> elements
is exactly the kind of thing which XSLT is designed for. XBL does not
pretend to compete in that problem space.

XBL, on the other hand, was designed to take <select> elements and
imbue them with the dynamic behaviour required for the user to
actually be able to use them.

You are the first person I have seen claim that XSLT is able to solve
this problem.


> You've apparently proved that XBL is good at making inseparable
> dependencies between CSS, DOM, events, and XBL.

I have never claimed the opposite. Could you explain why this is a
problem? (Preferably without using the word "orthogonal", since I do
not really understand what you mean by it; and yes, I have looked it
up in a dictionary.)


 
>> I made a test driver app in HTML to test it:
>>
>>   HTML: http://www.hixie.ch/tests/adhoc/xbl/demos/simple-driver.html
> 
> I get an error when running Internet Explorer.  Unable to test.
> Line13: "undefined" is null or not an object

Ironically, that error message is unrelated to XBL -- it is a bug in
IE's XML DOM. That is to say, a bug with its W3C standards support.

In any case, XBL is a Mozilla proprietary technology. To show the
equivalent in IE, one would have to use HTCs, of which I have no
experience.


> Wait a couple of (maybe few) months,

If it takes that long to write XSLT equivalents of simple XBL demos,
then that would seem to be a hands-down argument against ever using
XSLT. I am sure it is not because you have no free time, since you
have spent much more time replying to www-style e-mails recently than
I did writing the "simple" XBL demo.


> then I will post some compelling complex examples.

Compelling simple examples would be even better.


> I assume the timeline for XBL standards consideration can tolerate a
> few months for competing examples.

I am not aware of any W3C-led project to standardise XBL.

 
>> My apologies, it was certainly not my intent to offend or be
>> obscene. Brainfuck is the name of the programming language, there
>> isn't much I can do about that.
> 
> And !@*%#$%^ is in the dictionary.

I am not aware of any string of punctuation marks found in any English
dictionary, nor do I see the relevance here.

How would you rather I refer to this programming language?


>> My point stands, though: that a language is turing complete does
>> not imply anything about its abilities in terms of the surrounding
>> environment.
>>
>> A better example than brainfuck is a Turing Machine. A Turing
>> Machine is Turing Complete, but it has no way to play music on a
>> sound card, since the Turing Machine specification doesn't include
>> an API for a sound device of any kind.
> 
> XSLT outputs XML and CDATA. That is about as general as you need to
> do any W3 content.

Actually, it is not sufficient. Arbitrary XML and CDATA (which is just
a particular part of XML, so I'm not sure why you bring it out
separately) cannot bind individual elements to CSS, nor can they
extend the interface of individual DOM nodes without polluting the
window's namespace. In practice, it's not even clear what the
processing model for XSLT is: does it replace the original DOM or is
it a dynamic layer above it (in practice only the first is feasible,
the second is a performance nightmare -- unfortunately, only the
second is acceptable from a binding point of view).


>>>> 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.
>>
>> How?
> 
> Afaik, using Javascript.

An example, please?


> People such as I, who have written huge projects with multiple year
> life spans, know something about the importance of OO design.

Then you are probably ideally suited to see the benefits of XBL: it is
an object-orientated language, it encapsulates data and code, and it
performs simple wrapping and reordering in a way that is insulated
from the main DOM.



> You can have behavior without DOM or CSS.

I have yet to see this.

Note that a transformation that someone includes DOM and CSS in its
output is still a transformation that depends on both DOM and CSS.


> More importantly, the highest layer is binding of semantic markup to
> swappable implementation (anonymous content). The next layer below
> that is DOM. The next layer below that is style and events.

In practice, behaviour is intimately linked to the content, the style,
and the events.

Take, for example, a text input box. When you focus (event) the
control, it should change colour (style) and select all the contents
(DOM). When you type (event) it should change the contents (content
model) and move the cursor (DOM).

XBL merges all the layers because that is what is required to solve
the problem of creating behavioural presentational bindings.


>>>>   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>
>>
>> Without changing my originial markup [1], how would you do it?
> 
> Now you change the challenge again. 

No I don't. The challenge was "do what XBL does in XSLT". The XBL
doesn't _touch_ the markup.


> Why is it important I not be able to use a tag to semantic identify
> where the time data is?

It's not. The tag, however, is an HTML element, already chosen, see
the site for the exact markup.


> I think the opposite. It is desireable to semantically markup the
> time. Imo that is the whole point of semantic binding...

Since there is no date or time element in HTML or XHTML, the point is
moot.


>> I would be very interested in seeing the actual XSLT you would use
>> to do this. My thorough examination of the XSLT spec did not find
>> any date or time manipulation routines.
> 
> Why do you want time or date functions in a binding layer?

So that I can show the date and time of my Web log posts in the
current time zone, as I do now, in XBL.


> Those are totally different things. You would advocate merging time
> and date libraries into binding layers?

I'm not advocating anything at this particular juncture; I am merely
asking you to do using existing W3C technologies, what I do now using
a few lines of XBL and JS.

Are you saying this isn't what XSLT is designed to do?

If so, I completely agree. But it _is_ what XBL is designed to do.


>> The binding is not essential to the page -- which is why it is
>> bound from the CSS level.
> 
> Non-compelling use example then?

How do you mean?


>>> But XBL is not orthogonal to DOM and CSS as explained in previous
>>> posts.
>>
>> Indeed. XBL is a glue language to combine DOM and CSS together for
>> behavioural styling.
> 
> Now we agree.  :-)

I have never disagreed with this statement.


> Except XBL also does semantic binding. 

What do you mean by semantic binding?


> I do not know how else to explain that if handler is in the syntax
> of XBL, then you won't be easily adapting your XBL code for XEvents
> or any other superior standard that comes along.

XEvents is (merely) a specification that describes how to capture DOM
events, something which XBL already does. Why would XBL need or want
to use XEvents?

In any case, if it was so desired, it would be trivial to adapt XBL to
use the XEvents module syntax rather than the existing XBL syntax.

I fail to see how this is a problem.


> And remember when XBL needs to be improved, you have to wait for all
> UA to upgrade.

Strangely enough, exactly the same applies to every single W3C
technology ever created as well.


> Whereas with XSLT, you just change a transformation.

You still have to wait for UAs to be upgraded before using new CSS,
DOM, XSLT, XML, XEvents, or other features.

Don't forget, XBL uses JS, which is turing complete, so by your logic,
it can do anything. Why can't you just change the XBL binding just
like you change the XSLT transformation?


> If you want to try out XEvents, or any other technology, then you
> can, because the semantic binding is orthogonal to all the other
> layers of implementation.

You still have to wait for XEvents to be implemented.


>>> You are thinking non-orthogonally. 
>>
>> Why thank you. I do believe that is one of the nicest compliments
>> I've been given recently.
> 
> Apologies I did not mean it as an insult.

There was no sacrasm intended. I did actually think you meant it as a
compliment.

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

Received on Tuesday, 31 December 2002 06:15:06 UTC