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 21:53:20 -0600
Message-Id: <4.1.20021228202203.018b8d40(null)>
Message-Id: <4.1.20021228202203.018b8d40(null)>
Message-Id: <4.1.20021228202203.018b8d40(null)>
Message-Id: <4.1.20021228202203.018b8d40(null)>
Message-Id: <4.1.20021228202203.018b8d40(null)>
Message-Id: <4.1.20021228202203.018b8d40(null)>
Message-Id: <4.1.20021228202203.018b8d40(null)>
Message-Id: <4.1.20021228202203.018b8d40(null)>
Message-Id: <4.1.20021228202203.018b8d40(null)>
To: www-style@w3.org
Cc: rayw@netscape.com (Ray Whitmer), jeremy@dunck.us (Jeremy Dunck), "L. David Baron" <dbaron@fas.harvard.edu>

Side Note: I think lists.w3.org has been down for 2 days, but I am saving all
my posts and will repost them if they are lost by w3.org.  So far none of my
emails have bounced, but also I have received no email from list for 2 days.  I
have emailed web-human@w3.org to no avail.  Thus realize you may not have seen
some of my posts and vice versa.

From some private emails, it is clear to me that imo many do not really
understand well all the issues.

I will summarize my understanding of discussion to date and make a few strong
points of *FACT*:

1. XSLT 1.0, a W3C recommendation, is apparently supported on IE6 *NOW*, and
can be supported on ANY browser *NOW* by doing a server-side UA sniff and run
XSLT server-side for browsers that do not understand XSLT 1.0.  Netscape 6
apparently does not fully support XSLT 1.0.  There are many, many
implementations of XSLT 1.0 for server-side:


2. XBL (and XUL) is only supported on Mozilla at this time.  XBL is not a W3C
recommendation or even a WG at this time.  Apparently the only source code
implementation of XBL is controlled by Mozilla, of which AOL has an
investment.  AOL (Netscape) has submitted XBL to W3C for consideration as a
future standard.

3. Both XSLT and XBL can replace a custom tag and custom attributes, e.g.
<mytag myattribute=...>, with any other markup.  They are roughly equivalent
mechanisms in terms of the narrow function of replacing a custom markup tag
(semantic markup) with specific implementation content (implementation
markup).  There has been some misunderstanding that assumed XSLT would
transform implementation details such as event handlers (in a complex way). 
That is not true.  Both mechanisms are equivalent in terms of the simple goal
of separating (replacing) a custom markup tag set from (with) the
implementation details of those tag sets.

4. There is divergence in the templating replacement mechanism, which is an
open debate.  For example, in XBL the event handlers are part of the XBL
syntax.  XSLT doesn't care what it is tranforming to, so any type of event
handling mechanism could be used and swapped now and in future, such as
XEvents, HTML events, or even XBL.

5. XBL binds at CSS-like or DOM layer level in a non-standard way (it will
require changes to existing standards).  XSLT binds before DOM and requires no
changes to existing standards.

6. Because XBL binds at DOM level, it is possible that a UA implementation
could have some knowledge about (or even expose thru non-standard extensions to
DOM) the custom markup tags.  Of course the same can be said about a UA will
support XSLT.  In both cases, the custom markup tags are "custom".  This means
the UA can not know apriori all possible custom markup tags.  In either case,
developing a standard set of new tags is orthogonal activity to the need for
infinite custom tags.  For example, one might confuse XUL with XBL.  XUL
provides custom tags (extensions to XHTML) for common controls needed by web
applications.  If XUL becomes a standard, then other UAs may (or may not)
support these extensions.  And these extensions could just as easily be used
with XSLT or XBL.  One can use XUL with XSLT *now*, instead of XBL.  Unless I
misunderstood his point, I think Ray Whitmer was mistaken to assert that XBL
(by itself) has any advantage in terms of UA knowledge of semantics of custom

7. XSLT models XML transformations, which is general enough to support "early"
binding.  XBL models "late" (at CSS or DOM time) binding.  XSLT doesn't care
what transforms are applied (they are generalized).  XBL defines syntax which
desires that event handlers be bound within XBL and not at some higher level of
abstraction (such as XEvents).  Ditto for templating concepts where XBL binding
(content tree substitution) is more narrowly focused on solving XUL
extensibility.  XBL's narrowness does not come at benefit of simpler syntax.  I
was able to understand XSLT spec in much shorter time than XBL.  I think it is
because XBL focuses on "details" of XUL extensibility.  My mind more rapidly
grasps the permuted uses of general rules, than for a larger set of specific
rules.  XBL is more "involved" to implement because it relies on a UA (needs
CSS, events, and DOM layers).  XSLT can be implemented as a stand alone module,
as it relies only on XML.  Note how XML is a thin layer.  And note how XSLT is
another thin layer on top of XML.

8. My assertion is that because of #7 above, then XBL will not be able to
handle future unforseen scenarios as well as code written with the XSLT
mechanism.  I also assert that thin layers are more quickly implemented
widely.  As evident by the wide implementation of XSLT 1.0 (except for Netscape
6).  And more importantly that when it comes time to morph XBL to handle new
scenarios, that is the time you will see history repeat itself.

9. Issues about comparative performance have been raised.  No one seems to know
the exact comparative answer until we try examples.  Let me state 2 facts.  I
once rewrote the base algorithms for Corel Painter in assembly.  Only up to 30%
improvement was attained.  Useful improvements come form better algorithms. 
Computer speed doubles every 1.5 years.  I am more worried about writing
applications in 2003 that will still run every where in 2010, because computers
will 1280% faster by then.  Ponder that 2 Ghz CPU is already so much faster
than most applications that Intel can't sell as many chips as it used to.  And
slowness in Mozilla (the often quoted example) is probably more related to
algorithms used.  Imo, wise programmers leverage (prioritize) algorithms over
other details.  They get rich.  Note that Microsoft has implemented XSLT.  Draw
your own conclusions.

10. Since Mozilla is obviously on a lot of commentors minds, I must fairly
address it.  First of all, I humbly admit that Mozilla has done a lot to
advance W3C standards.  Second, I think Mozilla prioritizes whether Mozilla
will run on every platform, over whether applications written for Mozilla will
run on every browser (UA).  Microsoft has it's own priorities with IE.  This is
why we should use W3C standards, especially thin layer orthogonal ones (see
#8).  W3C has powerful thin layer, orthogonal standards, such as DOM, HTML,
XHTML, XML, CSS, XSLT, etc..  I assert these are the wise mechanisms for

11. As alluded in #6, XUL is an orthogonal layer of extensions to XHTML.  I
have no problem with XUL.  It can be used with XSLT just as HTML forms can.  I
just think that it doesn't remove you from needing DOM Views and Formatting. 
And once you have DOM Views and Formatting, then XUL can be replaced with XHTML
and DOM Views and Formatting, such that XUL runs every where and is extensible
thru content, without needing XPCOM and other prioprietary implementation
methods in the UA.

Let me explain.  Even Daniel's XBL example (see prior post of resizeHandler)
requires presentation layer dependencies such as "event.ClientX" and in his
todo list at bugzilla is for scrolling support.  What Daniel illustrates is
that even with XBL (for making/extending screen widgets) you can not escape the
need to get at presentation layer properties.  There currently is no W3C
standard for presentation layer properties (such as scrolling model or screen
coordinates), thus XBL and XSLT extensions are forced to use the proprietay
legacy ones (most not W3C standards) which are some kind of "bastard mix" of
Netscape, IE extensions with HTML4.  By "bastard mix", I mean not by any
unified design or planned marriage, but just a result of how different
extensions got adopted.

So anyone who says we don't need DOM Views and Formatting standard is imo
saying they prefer the "bastard mix" of legacy properties for presentaton

Once you have DOM Views and Formatting as an implemented standard, then making
widgets is simply a matter of XHTML + presentation properties.  No C++ or UA
code (XPCOM) needed.

I urge everyone to go support this standard.  I willing to work to get it


(My) Proposal for Improved/Simplified ViewsAndFormatting Segment *abstract*

Exposing the critical ACTUAL style values?

11. I am still waiting to hear compelling use reasons for XBL.

-Shelby Moore
Received on Saturday, 28 December 2002 23:54:39 UTC

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