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

Thanks for a civil debate of technical issues.  I will respond...


At 10:25 AM 12/27/2002 -0500, L. David Baron 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).


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.

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.


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


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.


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


This is also what I was proposing.  With XSLT the abstract widget gets
transformed into a content tree of normal XHTML elements which can then be
styled with existing CSS properties.  We can do this today and work with
all major browsers!


>XSLT is not appropriate for the description of form controls because it
>is too powerful.


Could you please elaborate on this and also to compare to XBL?  Agreed that
XForms is a tighter solution to "forms".  XBL and my proposal for XSLT is
imo more general than just forms.  It is a way to bind extensible abstract
markup to a content tree implementation in an orthogonal (interchangeable,
OO) way.

Given that XSLT is already a W3C standard, we already have that power.  It
is too late to remove the power.  If you are saying it is too powerful to
use for abstracting anonymous content, then I am curious how (if at all)
you feel XBL is less 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.)


I have also not worked with implementing XSLT.  However, XSLT is already
available as a library (widely implemented from many sources) in which you
input the source markup and transformed markup is output.  Afaik, it is an
orthogonal layer that is entirely transparent to the XHTML DOM.  Should be
trivial to implement (discounting any resource usage issue).

In order words, you should be able to test by running your files thru an
XSLT transformation, then using the output in the browser.  This could be
done server side.  That is one of the main benefits over XBL.  There is no
browser dependency and you could use it today and work with existing browsers.

In addition to this, it should be fairly easy to incorporate XSLT into
"applications" (the original intent of XBL).  For example, XSLT is standard
in PHP (and easily in Java and C++).



>XBL is less powerful.


I would agree that XUL is less powerful because you are limited to Mozilla
widgets (unless you want to dig into XPCOM). Getting consistent
implementations of widgets across browsers will be another war we best avoid.

XBL seems to me (and as commented by W3C Team) to be very 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.


So your point is that with XBL the DOM manipulation is at the source
abstract markup level, instead of at the transformed layer??

If true, then I think that is a major design flaw of XBL.  The programming
should not be at the abstract level.  Go back above regarding the benefits
of keeping layers orthogonal.  You may not realize how important this is,
until you want to do something totally new and have to throw away (or
rewrite) several years of work.


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


That is precisely why making good orthogonal design decisions is so
crucial.  As I explained above, XSLT is browser independent because it is
based on orthogonal design.  XBL and XUL is imo "spagetti" (non-orthogonal,
merging of layers) design which will delay wide implementation forever
(unless of course you believe that you only need Mozilla).

-Shelby Moore

Received on Friday, 27 December 2002 16:07:59 UTC