W3C home > Mailing lists > Public > www-style@w3.org > December 2002

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

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 31 Dec 2002 21:20:48 +0000 (GMT)
To: Shelby Moore <shelby@coolpage.com>
Cc: "www-style@w3.org" <www-style@w3.org>
Message-ID: <Pine.LNX.4.21.0212311920480.9121-100000@dhalsim.dreamhost.com>

On Tue, 31 Dec 2002, Shelby Moore wrote:
> [ a lot of stuff that had been said before ]

It appears you misunderstand what XBL's problem space is.

XBL is a way for authors to provide complex presentations and
behaviours at the user interface level, without changing the document,
much as CSS does with providing stylistic effects at the user level.

For example, if you want to add some decorative text to a document,
you can do so using CSS generated content:

   input::after { content: "Default: " attr(value) }

However, if you need to make an element have a complex shading effect,
e.g. fading in and out with mouse-enter and mouse-exit events, then
you would use XBL instead.

Just as with CSS, the bindings should be optional: the document should
not lose meaning when stylesheets are disabled. This means that it
should not change the DOM of the document, as seen by other documents.

Bindings should be dynamic: it should be possible to change to an
alternate stylesheet, and have the new bindings take effect without
having to reload the document or even lose any DOM modifications.

It is not a transformation language.

It is not a "semantic binding" language.

There is a strong demand for such a technology; this is why over the
last six years first Microsoft, then Netscape, then Mozilla have all
come up with proposals to address this problem.

Whether the demand _should_ exist is not really something I,
personally, can do much about.

Addressing XBL's possible dependencies on other technologies:

XBL depends on XML and the DOM in much the way that all XML-based
technologies do. (Some technologies depend on the infoset instead of
the DOM, but the idea is the same.)

XBL does not depend on particular interfaces of the DOM. XBL does not
depend on CSS. XBL does not rely on a particular scripting language.
XBL does not depend on a particular event set.

One of XBL's other strengths is that it can be introduced at the user
stylesheet level, where it affects every document the user reads.

> The "meaning" of a <select> is to be able to select from a list.

Exactly. What it does not say, is how to present the list; how the
list should react to clicks, how ctrl + left-arrow should affect the
selection, etc.

This is what XBL is designed to do.

>>>>>> Turing complete does _not_ mean it can do anything -- XSLT
>>>>>> cannot, for instance, add a new DOM interface to an element.
> [...]
> Javascript can add new properties and methods to existing objects. I
> am confident you know the syntax.

I didn't ask how you added properties and methods to existing objects.
I asked about adding new DOM interfaces to a DOM Element.

The difference is what happens in cross-language environments, and
what happens to objects that are garbage collected.

e.g.: take an object wrapped around an Element interface. Add a new

That method is not accessible outside JS (e.g. from VBScript or

Now let the object go out of scope, and get an object wrapping the
same Element interface.

The method will have disappeared. (Actually there is typicially as
race condition here, you have to wait long enough (a few seconds is
usually all that is needed) for the out of scope objects to be garbage
collected, otherwise the same object will be used.)

XBL, however, lets you define new methods and properties on the
Element itself, cross-language, without any persistency problems.

> I have said at least twice that I do not want XSLT to be
> interactive.

You may not need a dynamic transformation language, but there is
demand for it.

Take this real world example:

A <select> element that has two <option> elements is bound to XBL to
give it presentation and event handlers that do selection, etc.

Using the DOM, some script inserts new <option> elements into the
<select> element.

Those <option> elements have to be rendered as part of the page
immediately, with all the style and behaviour that the binding confers
on those elements.

XBL can do this.

> CSS was not designed to be required layer of DOM or markup.

Neither is XBL. There is nothing about CSS or XBL that make them
_required_. They are at the presentation layer.

The original document has all the semantics, and could be rendered in
a language-specific UA, e.g. an XHTML+XForms document could be
rendered without XBL in an XHTML+XForms UA. But with XBL and CSS
enabled, then you could have the same document, in the same UA, withe
the XForms controls looking different, e.g. replacing a <select> of
country names with an interactive map of the world.

None of the semantics change: it's still "pick a country from this
list". Only the presentation changes (from "combo box" to "map",
although of course the difference is more complex at the code level).


> You've been doing "commercial" development with XBL for apparently
> some months now.

I have never done any commercial work with XBL.

> The examples I am being asked to rewrite in XSLT have some years of
> development behind them.

I came up with the "simple" demo in 30 minutes. The others did not
take more than an hour or two each.

> I did not submit XBL to W3C.

Neither did I, although I am indeed one of its more vocal proponents
in the CSS working group.

> I am just provided a logical reasoning as to why it is W3C
> redundant. It is up to the submitter to prove it is not, with
> compelling use examples. It is up to you to work thru XSLT and prove
> it can't be done.

Actually it is common logical curtesey for the person making the
positive assertion to back up that assertion:

| The burden of proof is always on the person asserting something.
| Shifting the burden of proof, a special case of Argumentum ad
| Ignorantiam, is the fallacy of putting the burden of proof on the
| person who denies or questions the assertion. The source of the
| fallacy is the assumption that something is true unless proven
| otherwise.
 -- http://www.infidels.org/news/atheism/logic.html#shifting

> I will share my work as I do it. But I will not be forced to play
> useless mind games with no $ compensation.

For the record, I am not paid for my W3C involvement. (Indeed I
contribute at a quite significant financial cost to myself.)

> You aren't paying me. I did not submit XBL to W3C.

Nobody is paying me either. I did not submit XBL to the W3C either.

>> You are the first person I have seen claim that XSLT is able to
>> solve this problem.
> The W3C Team said if before me. Apparently you did not read their
> comments about the XBL submission:
> http://www.w3.org/Submission/2001/05/Comment
> "An alternative approach might be to use XSLT to transform a source
> document to one that includes the fragments, although the disadvantage will
> be that the DOM contains the expanded document and no longer only the
> original. Also, this approach does not really reduce the number of
> different technologies involved."

The two disadvantages listed are pretty serious disadvantages, and the
first is great enough to make this alternate approach unsuitable in
the real world.

>>> 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.
> Okay.  I thought it had been submitted to W3C.

Submission of a NOTE does not imply anything about contributions of
W3C resources.

>>>> 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.
> How about not using propoganda.

This isn't propaganda. You said it did not work in IE, I explained
why. It _is_ a bug, and not a lack of support, for what it's worth.

Anyway, that's not really relevant.

> Or use XSLT, then it will run every where. I have made this point
> about 4 times already in this thread.

Claiming a technology is technically superior merely because it is
standardised and widely implemented is a form of argumentum ad
numerum. The technology should be reviewed on its own merits.

>>>> 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?
> I'd rather not.  The point was quicly refuted

Actually, it wasn't, as seen in the very next comment:

>>> 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 cannot bind
>> individual elements to CSS,
> I do not want them to!

Which I think was my point. XSLT cannot do it. There is a demand for a
technology that can.

You might not want it.

But many people do.

> This is the semantic binding layer, not the style layer.

XBL is at the style layer.

This is important.

>> Arbitrary XML and CDATA (which is just a particular part of XML, so
>> I'm not sure why you bring it out separately)
> CDATA to emphasize scripting capabilities

Eh? What has CDATA to do with scripting?

>> nor can [XSLT] extend the interface of individual DOM nodes without
>> polluting the window's namespace.
> I refuted that already.  See replies to Baron.

Actually, you didn't. You simply said that a little pollution was ok:


...(search for "collision").

>> In practice, it's not even clear what the processing model for XSLT
>> is: does it replace the original DOM
> It has nothing to do with DOM.

XSLT has _everything_ to do with the DOM.

Given one DOM and an XSLT transformation, XSLT produces a new DOM.

That is the whole point of XSLT!

>>> You can have behavior without DOM or CSS.
>> I have yet to see this.
> My simple example with XSLT <select> was an example.

<select> has no defined behaviour.

It has defined semantics, but UAs are free to implement those
semantics however they like (a combo box, a map).

XBL is a way of adding (optional) stylistic hints that say how to
render the element and how it should behave.

> XUL is an example. XUL doesn't require DOM does it?

XUL, like HTML, does not require DOM, CSS, nor XBL. You could write a
XUL UA that did not use any of those technologies.

Of course to make it _do_ anything, just as with HTML, then you'll
need to script the document (using the DOM), or else it will just be a
non-interactive static document (like most HTML documents).

If you also want to control the rendering at a stylistic level, then
you would use CSS and XBL. You don't want to use anything which changes
the DOM, since that would break the aforementioned scripts. (You cannot
transform the scripts; they might not even be in the same document.)

> You've just pretty much insured I have won the debate.

I'm not particulary worried about anyone "winning". I'm only
interested in finding the truth: is XBL redundant, or not?

Ian Hickson                                      )\._.,--....,'``.    fL
"meow"                                          /,   _.. \   _\  ;`._ ,.
http://index.hixie.ch/                         `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 31 December 2002 16:20:51 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:05 UTC