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: Ray Whitmer <rayw@netscape.com>
Date: Mon, 30 Dec 2002 10:22:16 +0100
To: www-style@w3.org
Message-Id: <200212301022.16269.rayw@netscape.com>

Just a few clarifications of my own views.  I have edited the original
severely and not directly addressed its points.

Shelby Moore wrote:


>Agreed that not all properties of those elements are exposed in CSS.
>However, many CSS properties do often apply such as font, border,
> etc..
>Remember that CSS is an optional layer that should not be relied upon,
>unless one wants to be presentation (browser and browser
> configuration) dependent.

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.  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.  Long before I represented Netscape, I
 wanted to make the case that I thought XSL (or something else) should
 provide this sort of capability.  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 :-)

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).

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

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).

4.  XSL intentionally refuses to maintain any link between original DOM
elements and the presentation objects of the transformed result.
 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.

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.  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.


>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.

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.  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.

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.


>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.  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.

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.

Ray Whitmer
Received on Monday, 30 December 2002 04:22:22 UTC

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