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: L. David Baron <dbaron@fas.harvard.edu>
Date: Fri, 27 Dec 2002 16:40:47 -0500
To: Shelby Moore <shelby@coolpage.com>
Cc: "L. David Baron" <dbaron@fas.harvard.edu>, www-style@w3.org, Ray Whitmer <rayw@netscape.com>
Message-ID: <20021227164047.A8849@is03.fas.harvard.edu>

On Friday 2002-12-27 15:08 -0600, Shelby Moore wrote:
> At 10:25 AM 12/27/2002 -0500, L. David Baron wrote:
> >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..

I can think of three different ways the 'border' property might apply to
an INPUT with type=button (outside the normal input control, as a
substitute for the edge of the button that gives it the raised look, or
around the text of the button).  Applying 'width' to SELECT is worse.

> Remember that CSS is an optional layer that should not be relied upon,
> unless one wants to be presentation (browser and browser configuration)
> dependent.

True.  CSS may not be the best way of binding XBL, at least for some

> Also note that HTML DOM is a legacy markup, which will be maintained.

I have no idea what you mean here or what it has to do with anything I

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

This (and the comments before it, which I cut) are missing the point of
my previous message.  Believing that things will work adequately (i.e.,
be fast enough for real users to use) if you use general solutions at
every layer is not realistic.  One of the reasons Mozilla is/was slow is
that it has done things exactly as you suggest, and used general,
available solutions to problems rather than coming up with specific
solutions more tailored to its needs.

While it is a good idea to begin with general solutions when they might
be adequate rather than prematurely optimizing, I find it hard to
believe that retransforming an entire document and redoing the layout of
the entire result document (something that is already known to take a
few seconds or more for complex pages) for any DOM manipulation would
have acceptable performance for some of the more complex pages on the
web today.


L. David Baron        <URL: http://www.people.fas.harvard.edu/~dbaron/ >
Received on Friday, 27 December 2002 16:40:51 UTC

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