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

Before I leave this thread, a practical conceptual example.

Consider a new tag <slideshow>:

<slideshow>
   <img src="img1.gif"/>
   <img src="img2.gif"/>
   <img src="img3.gif"/>
<slideshow/>

XSLT can transform this to:

<applet ...>
  <param...img1.gif>
  <param...img2.gif>
  <param...img3.gif>
<applet/>

Nevermind the syntax errors and whether <applet> is deprecated.  The
conceptual point is that XSLT can transform a new useful tag to an
implementation of it's semantics.  I call this "semantic binding".  Call it
what ever you want, as long as you understand what it is doing.

Also note that any one (author, UA, visitor, etc) can substitute a
different XSLT transform to change this to any other way of implementing a
slide show.  An example would be to use scripting to change one img
element's src attribute using a timer.

If you do not believe that XSLT can make these sort of transformations,
then I ask you to trust me that it can, or go attempt it and you will find
out it can.

Okay so we have established that XSLT can do the following things:

1. Implement the semantics of new tags by transforming a new tag into an
implementation of supported tags.  I call this transformation "semantic
binding".  Call it what you want, as long as you understand what it does.

2. Swap the implementation of those semantics, simply by swapping the XSLT
transform.

3. Notice that the binding (transformation) has absolutely no dependence on
DOM or CSS.  There doesn't even need to exist a DOM or even a parser.  Thus
note that the swapping of transforms can be done without any changes needed
to CSS stylesheets and without concern for UA's DOM.


Now consider this same example in XBL.  In order for XBL to bind the new
tag <slideshow> to an implementation, then it will use either CSS binding
or DOM binding:

For the CSS binding:

http://www.w3.org/TR/xbl/#attach-css

The new <slideshow> tag is bound according to CSS selectors, which means
that it is possible that not all <slideshow> will be bound to same semantic
implementation.  It is entirely possible to have some instances of
<slideshow> do one kind of meaning and other instances of <slideshow> do
another kind of meaning.  Although this is possible in XSLT also, it is
kind of odd to be binding semantics using CSS selectors, which are designed
to NOT consider semantics [1].

Also note that if bound via CSS, then it means that the swapping to other
implementations will require and involve CSS.  This a blatant change in CSS
from one of non-semantic style layer [1], to merging semantic and style
dependencies.


For the DOM binding:

http://www.w3.org/TR/xbl/#attach-dom

The new <slideshow> tag is bound using new DOM methods.  Thus this means
you can't bind unless you have a DOM.  You can't swap semantic
implementations unless you have a DOM.

Read on...because it gets much worse for XBL...

Now if those CSS and DOM dependences are bad enough, XBL will make the
content that is bound anonymous:

http://www.w3.org/TR/xbl/#anonymous-dom


This means that what ever _semantic_ markup is used to implement the new
tag <slideshow> will not appear in the DOM.  Only <slideshow> and any
exposed methods and properties will appear in the DOM.  This is apparently
by design so that the semantic markup data is encapsulated (similar to OO
classes).  That sounds like it should be a good thing for design.

Well if you think a little deeper about it, you realize that _semantic_
markup is being obscured from the DOM.  But the new tag is not part of a
specification that is widely understood by UAs.  It is a custom new tag.
Thus the part of the content which _IS_ understood by most UAs and other
layers is now obscured.

This means that if we want to debug it, or do any of the other things we
are normally used to do on supported markup tags, we can not.  It also
means that only layers which understand our prioritary custom semantics
will be able to use our DOM.  Because all DOM will have in it is a Node for
<slideshow>.  The <applet> content will be obscured and not accessible in DOM.


Thus XBL:

1. Binds semantic implementation of a new tag only if DOM or CSS are available.

2. Can only swap implementations if CSS or DOM is available.  You have to
swap the CSS style sheet to change the semantic implementation.  Or you
have to wait until document is loaded in  DOM, then dynamically swap it
with calls to the DOM.

3. Other layers can not access the implementation of the new tag, even if
that *IS* the semantic markup they will understand.


It actually gets much worse when we analyze dependences on events,
semantics, CSS, and DOM together.  And there are many other points I made
in this thread.  If you add them all up, XBL is a mess.  But I think that
is sufficient to make my point.

You guys (are there any women on this list?) can argue it as much as you
want.  I'm done.  I'm confident that XBL is not the best way to enable
custom markup at W3C.

[1] http://lists.w3.org/Archives/Public/www-style/2003Jan/0042.html


-Shelby Moore

Received on Friday, 3 January 2003 05:32:11 UTC