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: Shelby Moore <shelby@coolpage.com>
Date: Sat, 28 Dec 2002 17:17:23 -0600
Message-Id: <4.1.20021228160658.018adca0(null)>
To: rayw@netscape.com (Ray Whitmer)
Cc: www-style@w3.org


Imho, extremely well stated overview.  I respect and appreciate your views
because you do seem to think on a global scale, yet with attention to the
many possible permutations.  For example, I credit you for visualizing
presentation possibilities, which I did not, (such as multiple instance of
rendering a single <H1> tag) that require a Segment model for DOM Views And
Formatting.  Whereas for DOM Views and Formatting, I also visualized
possibilities you did not, such as correspondence through union or
intersection transformation.

I will try my best to make some useful responses below at an equal level of
broad thinking...

Fundamentally, until we make specific examples, I think the comparison
between XBL and XSLT approach is too abstracted to be nothing more than
limits of each of our understandings of technologies and their uses.  I
started this thread with a hypothesis based on reasoned analysis, and still
hoping the XBL experts will come here and give compelling examples of
things that can be done in XBL which should or can not be done in XSLT.  By
analyzing such examples, then we can truely all merge our understandings,
rather than giving opinions with different basis of understanding of
possible permutations.

My understanding of the standards process is that since XBL was proposed
externally, then it is primarily up to the submitters to prove it is not
W3C redundant.  Of course, if they do not wish it to be a W3C standard,
then they may ignore the technical challenge.

I am still willing to be swayed to use XBL if that is the correct way.  At
this point, I believe that those who have commented, do not understand the
example ways I envision using this, and thus they do not yet fully envision
why I see a problem with XBL.  It is up to me to try to communicate my
understanding and see if it can stand up to (civil and factual) scrutiny.

More below...

At 06:34 AM 12/28/2002 -0800, Ray Whitmer wrote:


>There are alternative media, accessibility, and other situations where 
>the usual CSS interpretation does not necessarily apply even in HTML, 
>and to a much greater degree in custom markup tag sets, such as those 
>mappable by XBL or XSL.

Agreed.  And if I may elaborate, Ray is imo saying here that "<widget>"
(custom tag) may or may not have a useful meaning in a particular
presentation or situation.

>  Permitting presentation -- and anything that is 
>likely to vary from one use to the next -- to be as modular as possible 
>within specifications is a good thing.  That leaves it up to the 
>discretion of the web author who knows his requirements.


>That does not make XSL the silver bullet, IMO, when creating interactive 
>web applications, as much as we would all like to have something that is 
>a standard.

And that logic alone does not exclude XSLT...

>  Long before I represented Netscape, I wanted to make the 
>case that I thought XSL (or something else) should provide this sort of 

We must have similar philosophy to some extent...

>  I do not understand as much as I should about XSL or XSLT 
>as it stands today and have little experience designing transforms using 
>it (largely because it seemed to be ignoring my use cases).  But my 
>opinion follows anyway :-)

I assume that Ray means here that he is more interested in semantic uses at
this time?

He uses are irrelevant, except to understand *IF* Ray is probably not
focused (expert) on for exampe browser presentation implementation detail
uses such as XBL.

>1.  Back in that time, I was told that the XSL group was far more 
>concerned with processing to a final form than to a more interactive 
>form.  At least they seemed to me to be rejecting such requirements.  I 
>do not think I was the only one asking for them (although I did not 
>understand the formal process of requesting them at that time).

I am not sure if I understand "final form" and "interactive form" in this
context.  Please correct me if I am way off.  Assuming that I do, then I
would agree that final form (one way transformation, no interactive
dependencies) is cleaner more limited focus.  I prefer to keep layers as
narrow of possible.  It is one of the principles of good OO design.  It is
fundamentally why I think XBL "all-in-one" approach is inferior OO design.
It is why I have proposed removing the Match portion of model from the
Segment model for DOM Views and Formatting.

>2.  I do not recall seeing any W3C specification dealing with the use of 
>XSLT as browser vendors have deployed it to create presentational HTML 
>from XML.  The more-formally-endorsed approach would be perhaps be to 
>have the browser use the defined XSL set of formatting objects, but 
>these seem unsuited to web applications so you are unlikely to see that 
>happen, nor have I heard of a proposal to formally permit arbitrary 
>presentational widgets to be dropped in, other than as markup.

My understanding is that XSLT (not XSL) exists on it's own W3C approved
specification.  And the specification defines the limits of what is
formally specified.  So I must disagree.

Does the specification allow for XSLT to be used in ways the designers did
not intend?  Perhaps.  Is that bad?  Let's analyze examples.

>3.  XSL deals best with markup, whereas the output of a transform to 
>glue interactive web applications together would likely rely on CSS + 
>Javascript, for which XSLT does not seem to be the best tool (and XBL's 
>approach seems more direct and appropriate).

I think you've missed my main point.

The first objective is to bind anonymous content (abstract custom markup
tags) to implementation in swappable mechanism.  No assumption about the
types of semantics of those custom markup tags.  It seems to me that you
would be in favor of abstracting semantics away from implementation?

The details of implementation are abstracted from the markup using XSLT.

As for what is used (CSS, HTML, XHTML, XEvent, HTML events, etc) for
implementation, that can be swapped by any implementation.

That *IS* the beauty of being truely orthogonal, versus being "all-in-one"
solution for a particular class of semantics.

>4.  XSL intentionally refuses to maintain any link between original DOM 
>elements and the presentation objects of the transformed result. 

I do not see how this relates to what I was envisioning?

If (as in example I gave) "<widget>" is transformed to an XHTML or HTML
content tree, then XHTML DOM or HTML DOM models the transformed result.

Again the implementation content tree is orthogonally swappable by XSLT.

> Although it could be accomplished in a limited fashion via an 
>additional standard on top of XSLT, that new thing cannot just appear 
>out of thin air and without significant support by the creators of that 
>standard.  I believe that the XSL group was opposed to this aspect of 
>the proposed DOM Views and Formatting Model (that is no longer being 
>actively developed now).  If you really want to have an environment 
>where XML represents more-abstract data that can be reused more widely, 
>you also want the ability to have the presentation modify the source 
>data so that it can be saved either by an authoring environment or as 
>application data.  To my thinking, this seems to be to be much easier 
>via XBL.

I think what you are saying (correct me if I am way off) is that *IF* it is
desired that the presentation have knowledge about the abstract markup,
then XSLT (unless we define a new standard) explicity does not provide
such.  I admitted this in my very first post.  And I said that the
separation of presentation from markup might be desireable.

Let me elaborate now.

Definitely presentation can be knowledgeable about DOM if the implemention
desires, because DOM is a standard.  I assume we agree that XSLT can
transform <widget> to DOM.  Thus no generality has been lost as compared to
the knowledge presentation has today about the markup structure.

However, I assume you are saying that it might be desireable for
presentation to know about <widget> instead of only it's transformed
content.  In that case, you've just created a new standard as you point out.

Both ways have their pluses and minuses.  And we can explore those if
someone asks me to.

I've been down this thought process and my conclusion was that "it is
impossible to define semantic standards for everything people want to do".
Thus we are much better off to get transformations to a base standard.
Much better presentation UAs only have to model DOM (and DOM Views and
Formatting) and not an infinite set of semantics (via XPCOM or whatever).

XBL does nothing to solve the problem of a need for infinite semantics.  I
am very surprised because with your focus on semantic web, I am surprised
you would say that XBL is a general solution.  Or maybe you are saying it
is better to build an infinite set of semantic standards incrementally?
(which would be mathematically impossible)

Truely the only logical conclusion I could make is that we need layers for
people to build infinite semantics on top of.

That is why the DOM Views And Formatting must happen.  It will happen, if I
have to do it all by myself.  Eventually people will realize if they walked
themselves into a way that is limited and will have to start over again.  I
will already be several years ahead by the time.

Hopefully you can either point out where I am way off, or we can realize
that we need this.

>The whole issue XSL versus XBL would seem to call for a demonstration of 
>the practicality of one versus the other. 


> Since either allows you to 
>operate on arbitrary markup tags, it would seem to me that one could be 
>substituted for the other quite easily in concept.

Good point!  Perhaps one could code in XBL today and use XSLT tomorrow.  Or
vice versa.  Very good point!

Except if the design relies on idiosyncracies of XUL base widgets, etc..

>  If key pieces are 
>somehow missing from the browser XSLT implementation that have actually 
>been standardized, it would be interesting for me to hear, because I 
>have not heard of such standards for easily building interactive web 
>applications using XSL that might have been ignored.

Not following you on this point?

>>Also note that HTML DOM is a legacy markup, which will be maintained.
>>However, it should not exclude options for more abstract content markup.  I
>>had a discussion with  Ray Whitmer of Netscape (the DOM Chair) which
>>clarified this for me (Ray please correct me if I have misstated).  In
>>other words, we should not design ourselves into a corner (what I referred
>>to as "Bataan march") by merging layers.  Keeping layers orthogonal allows
>>the author to choose his abstraction level.
>I referred to legacy browsers support for HTML only in the same sense I 
>would talk about legacy desktop PCs when comparing them to palmtops, 
>cell phones, set top boxes, etc.  We worked hard and very recently for 
>the DOM HTML standard, just as others have for the HTML standard.  It is 
>good in the vast domain where it applies and significant parts of it can 
>be applied beyond.  There are other domains that are thought of as 
>domains of the future simply because they did not exist in the past. 
> Many hope to more-fully address these in the future with a more-modular 
>XHTML and CSS approach rather than requiring the full set supported by 
>HTML or discarding and starting from scratch.

Agreed and I want to emphasize the last sentence you wrote and what I wrote
"it should not exclude options for more abstract content markup".

>The keepers of the specific standards must define the separation based 
>upon experience, the requirements of the particular domain, and expected 
>reuse of the standard and content.  How can I say, for example, "keep 
>all presentation out of SVG markup" when SVG, as a natural extension to 
>XHTML, is entirely about describing a visual model.

Agreed.  Except note that SVG is orthogonal and not required in XHTML.

For example, with XBL, CSS (or similar construct) is required.  DOM is
required.  It is not an orthogonal way to bind custom markup to anything
else.  However, as you cleverly point out, it may be swappable with other
bindings (such as XSLT) which do not have such dependencies.  So in that
respect, it may be orthogonal when you do not use it.

 > Another natural 
>extension, MathML, cleanly separated the semantic tags from 
>presentational tags, but is unable to express the required the 
>sophistication of structured display using CSS, so, again, there is 
>markup that applies to display.  The line is also fuzzy in XHTML core 
>modules as well, I suspect.  

Your point being choose the best tool for the job.  Okay that agree with.
As long as I do not end up with code that is too dependent on too many layers.

>One application's view is another application's model.  Still, we need 
>to try to maintain useful separations at the specification level where 
>we can.

Agree on alternative perspectives, as long as we are well aware of
implications of the layer dependencies we get stuck in.

>>Agreed.  However, consider that if we keep layers orthogonal, then the
>>author can program his behaviors at the behavior layer, and reuse them
>>semantically at the abstract content markup layer.  It is just a way of
>>separating things, such that they are more interchangeable "black boxes",
>>i.e. OO design.
>Some people might expect to have completely different standards and sets 
>of content when addressing different media or use cases, but I believe 
>that permitting reuse of standards and abstract content is a good thing 
>where practical, and that is possible to some degree through the 
>independence of CSS and XHTML modules and even more using abstract XML 
>transformed by XBL, for example.

XBL requires (or at least encourages) for example that events be embedded
in the binding.  This is one of many examples I gave where what one really
wants generally is to make the binding one layer and the implementation
choices from other layers.

This is imo advantage of XSLT approach.

Also XBL is designed more for XUL type widgets than as a general binding
approach (as apparent with it's "all-in-one" mechanism).

>  Separation into orthogonal parts is 
>essential, as I see it, at the specification level, but we should make 
>it easy for web authors to mingle these parts if they see fit when 
>creating content for their target platforms and requirements.  If they 
>have requirements that seem to naturally call for orthogonality of 
>presentation they will solve them as they see fit, we should try to give 
>them tools to do it as we see fit and see how they are or are not useful 
>to them, etc.

I have no problem with people that think XUL + XBL is faster way to reach a

I prefer to use W3C standards and make code that will be more OO and more

>These are my opinion, but Netscape, Mozilla, AOL, W3C, and the community 
>it represents, are each well served by a multiplicity of views held by 
>individuals of each organization.

Thanks for your input.  Thanks for being neutral in a logical manner.
Please do not take my responses as against any of these organizations (even
it is true I may not like the way I am talked to by some people at them).

I do genuinely want to explore the best solutions to building applications
on top of standards.

No one may care, but FYI I am beginning to tire of rehashing theory and
opinions.  I am getting impatient to enter implementation mode.  So please
if any one is going to change my mind, please write something factual and
compelling now.

-Shelby Moore
Received on Sunday, 29 December 2002 03:32:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:18 GMT