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

On Friday 2002-12-27 00:24 -0600, Shelby Moore wrote:
> "Because this content is not visible to its parent element, it is said to be
> anonymous content."
> "this content" refers to the implementation that is bound to the markup
> element.
> Again I will re-iterate that afaics, XSLT can make the necessary
> tranformations to substitute a "content tree" in place of an
> extensible abstract markup element.  Instead of placing the binding at
> the CSS layer, it places the binding at the XSLT layer which sits on
> top of XHTML DOM layer.  So thus XHTML DOM does not depend on CSS, as
> it does in the XBL - CSS binding model.  Instead of swapping bindings
> by swapping CSS (and XBL), one swaps at XSLT layer.  Thus semantic
> abstraction binding is at higher level of abstraction than (layer on
> top of) XHTML and CSS.  XHTML are the basic building blocks of content
> markup.  CSS layer is even less abstract and getting closer to
> presentation layer.

A number of markup languages have elements whose expected rendering is
far too complicated to be described by CSS at present.  The best example
of such elements at present is form controls (both in HTML and XForms).
People who use these markup languages often want to do DOM manipulation.
This is commonly used on the web.  (I claim, based only on experience
looking at web sites, that a significant percentage of the uses of
scripting on the web involve forms.)  There is also significant demand
from web authors for the ability to style form controls.  Since form
controls can't currently be defined in terms of the CSS formatting model
the effects of many (or all, I claim) properties are undefined.
Interoperable stylability of form controls requires either listing the
meaning of every CSS property for every form control or a general
mechanism to reduce the form controls to simpler components.  I prefer
the second approach.

XSLT is not appropriate for the description of form controls because it
is too powerful.  I don't know of any implementation of XSLT in a web
browser that allows manipulation of the *source* document's DOM
(Mozilla, I am told, gives access to the result document's DOM) [1].  I
have been told by one of the people involved in implementing XSLT in
Mozilla that implementing XSLT incrementally, i.e., in a way that
updates to the result document corresponding to small changes in the
source document can be made far more efficiently than the original
transformation of the entire document, is very difficult or perhaps even
impossible due to the power of XSLT.  (I may be slightly misremembering
what he said.  However, I think the burden should be on the advocates of
XSLT to show that it is implementable.  I admit that I'm not familiar
with existing XSLT implementations other than Mozilla's.)

XBL is less powerful.  This is a requirement for any transformation
mechanism used to describe form controls, since efficient DOM
manipulation of the source document is a requirement.  Rather than
creating an entire result document, it creates a subtree of anonymous
content, attached to the XBL binding, so that the rendering and behavior
of the element with complex semantics can be reduced to a tree of
elements with simpler semantics.  The DOM of the source document can
thus be manipulated efficiently.


[1] Please don't underestimate the need for real implementation
    experience in web browsers.  They already have many components that
    fit together, and adding support for new standards may not fit with
    the existing components even if those new standards are easily
    implementable on their own.

L. David Baron        <URL: >

Received on Friday, 27 December 2002 10:25:30 UTC