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


Since you took the liberty with unsubstantiated and non-technical "snide"
remarks, such as "Thanks for that morning laugh", then I am at liberty to
respond with equally strong opinions.  If you'd prefer to return the discussion
to a higher degree of civility, then I'd be happy to reciprocate.

At 02:29 PM 12/26/2002 +0100, Daniel Glazman wrote:


> Please also note I work with
>XBL on a daily basis,

Thus you are biased.  There is a saying, "Too deep in the forest to see beyond
the trees...".

> used XSLT to produce the CSS 3 Selectors Test

Is this a narrow use of XSLT or one that explores *ALL* of it's possibilities?

>Last detail: I am the co-editor of the BECSS spec

Which per time line at above link, doesn't seem to have much momentum since
it's Aug 99 WD1, as compared to other CSS3 modules.

Note that I have proposed using CSS selector logic to style XEvents.  I try to
KISS while efficiently and incrementally building on existing standards work,
rather than "reinvent the wheel":

> that federated some 
>time ago the Action Sheets proposal from Netscape

Are you proud of how stable and successful Netscape products are, especially
Action Sheets and NS4.7?  I'd like to suggest a possible correlation between
"reinventing the wheel" (non-incremental, non-modular design) to how brittle
and buggy Netscape (and Mozilla) products have historically been (and perhaps
continue to be).  I am not just referring to the buggy and extremely late
implementation, or the market failure, but also to a possible "spagetti" 
philosophy of design.

Whereas, for example in comparison "uncorrupted" CSS is very, very successful
in implementation, market, and as an orthogonal layer.

I'd prefer to stick with W3C standards.

> and the HTC proposal 
>from Microsoft. I know quite well this subject.


>> XBL was submitted to W3C, by AOL on behalf of itself and
>> The W3C team, apparently with Bert Bos of CSS WG listed as editor, has 
>> commented that XBL is "complex", depends on many format layers (i.e. may
>So complex that we saw some months ago a young contributor to Mozilla, a 
>16 year old swede (Håkan Waara to name him), contibute a new binding for 
>spinbuttons in Mozilla.

The "W3C Team" wrote an opinion that it is "complex" at the link above.

One can take any complex platform, and find a young person who to hack together
something.  Let's instead compare specific examples with links to actual code,
to create useful comparisons about comparative complexity, W3C redundance,
principle of least power, orthogonality, etc.

> According to him, it was simple and fast.

And he has at most 16 years of design experience to compare to.  Sometimes the
easiest ways to hack, are the most dangerous from a design model.  For example,
orthogonality determines how easy it will be in future to extract the work for
reuse in future unknown layers and ways.  Interoperability and reuse of modular
standards is not necessarily a "pipe dream".

We will hopefully explore specific examples.

> I use
>his spinbuttons in my CSS Editor for Mozilla Composer. Trivial.

Whether is is "trivial" for you has no bearing on the issues I raised.

>> undermine layer modularity), "recursive" in yet not fully explored ways,
>Yeah, yeah, we end up with endless loops every second in Mozilla.

YOU DIGRESSED: "endless" no, but afaik "recursive-like" buggy behavior is quite
common in Mozilla.  The DHTML performance issues (which have plagued every
Netscape release) had not been fixed in 2 - 3 years, the last time I checked. 
And if I remember correctly, the profiling showed some "recursive-like"
redundance (inefficiency).  I admit I gave up waiting before Netscape 7 (i.e.
Mozilla 1.0) came out.

The point was made by the W3C Team that the possibilities existed and had not
been fully studied for ramifications.  Whether the standard would be used that
way is an open question.  In any case, "recursive" was not my criticism. 
Perhaps XSLT is also.

>More seriously, there is no problem here.

Technical justification for *ALL* ramifications of recursion in this content?? 
I think it is an open question.  I am curious on what technical basis you can
proclaim "no problem"?

In any case, I reiterate this is not my issue with XBL.

>> "powerful" possibly beyond the primary goals (see Tim Berners-Lee's 
>Yes it is powerful.

This is where the relevant technical discussion should begin.  We should
explore the ways that XBL is more powerful than XSLT, XEvents, XForms, and
XViewsAndFormatting, which are existing standards or at least W3C proposals.

We should then analyze whether the extra power of XBL is desireable from the
principles of good orthogonal design.  And whether there are very important
things that can not be done with the W3C standards.

Remember "principle of least power".  For example, it would be silly to write
an accounting program in assembly or machine code.  It would probably be silly
to write an accounting program in C/C++.  Simply too much power that gets in
the way of efficient, modular coding of the accounting data structures.  If you
do not understand well this point, then go read Tim Berners-Lee: 

> I have just added to Mozilla Composer the ability
>for a document's author to resize images using the mouse.

I DIGRESS: We've had that capability in Cool Page since 1998.  In fact, with
real-time resizing of the image presentation, which was code I submitted to
Mozilla several years ago.

> Eight image
>handles (one per side, one per corner), like in a vectorial editor. This
>is achieved 100% through XBL with a dash of CSS to absolutely position
>some anonymous content. The code is so simple that anyone with just a
>basic knowledge of JavaScript and CSS can understand it.

You've created a resizing widget for "anonymous content".  Great.  I think the
same can be done with existing W3C standards.

Your attached XBL example is apparently good for comparison:

Because it illustrates some of the weaknesses of XBL:

1. The event handler bindings are embedded in (not orthogonal to) the binding
of the abstract markup (e.g. "resizeHandle") to the implementation markup, e.g.
<html:span...>.  XEvents would be better standard.

2. The procedural code is embedded in (not orthogonal to) the bindings of the
events, or to the binding of the markup in #1.  XEvents would be better

3. CSS (e.g. left, top, etc) dependencies are not orthogonal to the binding of
the abstract markup to the implementation markup.

4. Presentation dependencies (e.g. event.ClientX) are not orthogonal.  This
abstract widget will not degrade gracefully in generalized presentation

Etc..  I could go on and on.  In short, this illustrates the "spagetti" method
of design.

>> of least power"...we all know he "created" the world wide web), depends on
>> "procedural code" (i.e. does not optimally modularize or abstract the
>> procedural binding layer), and mentioned other possible solutions:
>So ? A few years ago, he told me during the Paris Web conf "me alive,
>no internationalized URLs". Even gurus can follow the wrong path and
>make mistakes.

International URLs have nothing to do with Tim Berners-Lee's "principle of
least power".  In fact, I think you might even argue that making URLs more
powerful is opposite of his logic in "principle of least power".  I am 100%
confident that Tim Berners-Lee sticks to his basic assertions about correct
design philosophy, that I linked to in my first post.  I do not even know him,
but I know enough about design to know that he is correct on an abstract level.

>> I wish to add two comments:
>> 1. XBL is (mostly) W3C redundant
>Let's discuss that below.

I never saw you factually refute this.  More on that below...

>> 2. CSS is wrong W3C layer for semantic behavior *markup*
>XBL does not add markup to the CSS layer. It adds only one CSS-alike
>property attaching a binding to an element.

That is by definition making markup dependent on CSS.  Without CSS, the
abstract element binds to nothing and is ignored by XHTML.

Thus, one can not separate the CSS style sheet from the markup.

> Please note that the CSS WG
>has proposed behavior-like extensions to CSS for UI,

And you have noted that you are a primary author and proponent.  And I have
stated it doesn't appear to have timeline in CSS3 page.  And I have proposed
(as mentioned above), that there is an incremental way to get behavioral style
in more general and less complex way by leveraging only the selector logic for
XEvents standard.

In any case, behavioral style in an orthogonal style sheet, is not the same as
making abstract markup depend on style sheets.

> and that the
>'display' property is almost a behavior declaration in itself.

Everything in CSS is closer (less abstracted) from presentation than markup
is.  It is designed to be an othogonal layer, not one interleaved with markup
like "spagetti".

I agree display is fairly close to visual presentation (although it could be
interpreted for example for aural presentation), but that is besides the
point.  CSS does not violate the abstractness of markup because it is an
optional, orthogonal layer.

>> As W3C Team commented, the templating portions of XBL could be accomplished
>> with XSLT, an existing, widely implemented W3C standard.  The advantage of
>:-D Thanks for that morning laugh. Please try, wishing you good luck.

I guess you did not read the entire thread.  I had already written the
following before this reply from you:

For some reason unknown to me, that reply to my original post, did not get
shown under the same thread when www-style is sorted by thread.

Again the "snide" remark is not civil, is imflammator, and does nothing to
forward the technical discussion.

>> using XSLT is that the binding of the content markup abstraction does not
>> involve the CSS layer.  Content markup abstraction (model) should not 
>depend on
>> a controller layer (CSS).  If you mix the two layers, then you destroy the
>Because you think of CSS as a language designed for style only.

First, you do not know what I think from reading one email post of mine.

Second, CSS is an abbreviation for "Cascading Style Sheets".

Third, imho the only limitation of CSS be that it remain orthogonal to markup
and the presentation layer dependencies.  Any limitations beyond that are open
for discussion and design optimizations.

> Think of 
>another language,

Okay but then propose it as such.  As submitted by AOL and Mozilla, XBL uses
CSS to bind to markup.

> using the CSS general syntax, id est a selection 
>mechanisms based on Selectors, blocks of properties/values surrounded by 
>curly braces, inheritance or not, and you could define languages having 
>no relation with style using the same meta-definition. I wrote myself a 
>transformation language called STTS based on the CSS general syntax.

The set logic of selectors is powerful general concept, partially because it
*IS* orthogonal to markup.

>The -moz-binding property is available in CSS instances because our way 
>of attaching a binding uses the CSS general syntax, uses inheritance, 
>uses all the mechanisms intrinsicly attached to CSS. We see no value to 
>oblige document authors to divide one single rule into two pieces in two
>different files, one for styles and one for behaviors.

That is three different discussions.  First, using CSS to bind markup makes CSS
not orthogonal to markup.  Second, inheriting style from the abstract markup
level is another issue to discuss as it probably impacts whether using XSLT
instead of XBL is correct.  Third, whether behavior and style should be
orthogonal is another discussion.

On first issue, I am sure that CSS should not be used to bind markup.

On the second issue, I think it is more important to keep CSS orthogonal to
markup, even if we have style at the transformed layer instead of inherited
(which I haven't fully analyzed yet), than to merge CSS and transformed layer

On the third issue, I am confident that keeping events and behavior details
orthogonal to style is desireable.

>> benefits of orthogonality (modularity) in the "model-controller" design 
>> An example of such a benefit is exchangeability of CSS, i.e. if content 
>> depends on a style sheet, then the style sheet is required and thus no
>> exchangeable.

Either I do not know what "Boarf" means, or perhaps it is a typo for "barf"? 
Another "snide" remark?

> The rendering of a document depends on a rendering engine anyway.

Circular logic.

>It depends on a style declaration, hard-coded or declarative, anyway.

Absolutely false.

A presentation (rendering) layer may not support CSS at all.  CSS are just
"hints" to the presentation layer.  If you assume anything about CSS, then you
are presentation dependent.

>Does it make you scream ?

Another "snide" remark?


>Explain me how can XSLT generate and manipulate anonymous content ?

I had already begun:

I can attempt to elaborate on this once we get into a civil and productive

>> I am aware that instead of CSS, XBL can also bind using DOM extensions, but
>> again this violates the orthogonality between DOM and abstract content 
>> Most of the other benefits of XBL (and XUL) can be accomplished with
>> W3C standards and proposals.  For example, the abstraction of events using
>> XEvents and the abstraction of procedural code using XForms.
>In other terms, this is a choice between an existing simple and
>efficient implementation and two complex and unimplemented
>specifications-to-be. My choice is easily made.

Disagree.  FIrst, XBL is not "simple".  Apparently it may not be "efficient"
when modularity (at the W3C standards layers) is a desired goal.

Second, XSLT is widely implemented and is more of recommended specification
than XBL is.

As for XEvents and XForms, they are further along the W3C standards process
than XBL, and they are not necessary to begin using XSLT today to abstract
markup.  The implementation (transformed) markup layer that is output from XSLT
can utilize these new standards as they become available without merging CSS
with markup as XBL does now.  Not to mention that using XEvents and XForms in
future will lead to better orthogonality in terms of the other criticisms I
made of your resizeHandler XBL example above.

>> And to build entirely new widgets (as opposed to extending existing ones)
>> in XForms or XUL, there is the DOM Views and Formatting proposal I am
>> on, to abstract the presentation state.  I'd really appreciate if some
>> would enjoin to investigate the importance of this proposal.
>Hammers are too heavy to efficiently smash flies.

Another "snide" remark?

Factually, if any of your XBL scripts rely on the presentation layer
properties, such as the proprietary ones (e.g. OffsetX, etc), then you could
really benefit from a presentation layer standard for these properties.  For
example, your resizeHandler uses event.ClientX.  You are writing to a
proprietary layer than will not be transportable is a WC3 standard way.

I say that a large percentage of DHTML scripts in the world could benefit from
standardizing the presentation layer abstraction model.

Also I noticed that your resizeHandler (and many DHTML scripts) use pixel
units.  This is inherently presentation dependent.  Without a standard for the
presentation layer, then using abstract units (such as 'pt' or 'in') is usually
not practical.  As of today, 'pt' is not implemented to be 1/72 of inch.  For
example, if we could get the presentation layer to tell us what 'pt' is, then
we can use it more reliably to abstract ourselves from the resolution of the

Obviously the standardized presentation layer interface is applicable to
improving existing layers which rely on proprietary presentation interfaces.

>> (My) Proposal for Improved/Simplified ViewsAndFormatting Segment *abstract*
>> model
>> Exposing the critical ACTUAL style values?
>> The original goal of putting behavior in CSS was apparently to provide a 
>way to
>> "attach style to structured documents":
>Er, did you really read that message ? In particular, Ian Hickson's
>first lines ?

There you go again with another "snide" remark.

I will quote from Ian Hickson's post:

"How do XBL, HTC and BECSS help CSS to fullfill...They don't. They help another
goal, which is...a fuzzy concept..."

" it more likely, that any results of the related work will make it into
something else..."

>> I think this goal can be accomplished without violating the orthogonality
>> (separation) between markup and style, perhaps similar to how XSL and XSLT 
>> to be used together to style documents (something I admittedly haven't 
>> fully).  Maybe that is already the solution.
>This is IMHO an error, in the case of the Web. 95% of it does not care
>about structuration of the data. 95% of the web needs a an almost
>pixe-fine rendering based on languages so simple to learn, use, update,
>maintain AND extend, that the TCO of a web site can be neglected
>in comparison with the generated incomes. The rest lives in gurus'
>dreams only.
>We need a compromise between gurus' approach and pragmatical approach.
>What you propose is far from usability, AFAIC.

It is ironic that I disagree with you, because I am the author of Cool Page,
which is pixel-perfect positioning editor popular with the masses of novices,
and which (at this time) does a pretty horrible job of being structurally
orthogonal.  (Note how I start with self-criticism instead of insults)

And I agree that large portion (disagee with 95% and maybe not even majority)
is focused on presentation details.

However, I disagree that presentation details can not be orthogonal to abstract
markup.  And in fact, watch for something revolutionary and patentable in next
version of Cool Page.

And I think the orthogonal goal actually benefits the implementation of what
user's want.  Good design and algorithms beat brute force in every case I've
ever seen.

Also I dare guess (based on posts I've browsed in www-style and www-dom) that
your opinion is at complete odds with the majority involved at W3C.

>> In other words, it is not necessary to involve CSS in content markup
>> abstraction in order to achieve styling exchangability.  CSS sits is an
>> orthogonal, modular layer separate and independent from content markup 
>(even if
>> many authors don't use it that way).  See Tim Berners-Lee's "Modular
>I know this approach. I pushed it myself. And abandoned it. This is a 
>very nice conceptual approach but not pragmatical.

Maybe you were too deep in XBL "forest" to see how it could be done in a more
modular way.

I do not agree with your assertion that it is not pragmatic.  In fact, exactly
the opposite.  It is not pragmatic to do it any other way.  Because proper OO
design always beats brute force.

You start writing your accounting program in assembly code, and I will start
with PHP classes.

>> For example, I have proposed using CSS selector logic to style XEvents. 
>> Something like this would maintain orthogonality and not cause
>> interdependencies between the abstract semantics of content markup and the
>> binding (implementation) of event handlers, i.e. the crucial distinction 
>> my proposal is abstracting styling of behavior details not semantic 
>*markup* of
>> behavior:
>Still cannot deal with anonymous content.

With XSLT it can.

Please define "anonymous content" and give a short example, so I can be sure we
are writing about the same thing.

>> It is very important that we design the W3C standards such that we 
>maintain the
>> desired abstractness and orthogonality (modularness) of each layer standard.
>I just happen to disagree with that. XHTML should continue having
>presentation attributes normatively defined in full redundance with CSS

I disagree.  XHTML should become more pure than HTML ended up being after being
polluted by you (Netscape) and others.  CSS is another layer for those who want
to get closer to presentation.  And DOM ViewsAndFormatting will be yet another
layer for those who have an application that must be even closer.

I am have no problem with the challenge that your camp go non-modular and my
camp will go modular.  I am confident our camp will win.  I gave up on Mozilla
a long time ago, just as most everyone has (as a fact of authoring and user
market share).

Why should I invest in a Mozilla technology?  I'd rather leverage W3C
technologies.  Build on top of them incrementally and orthogonally.


>> And it is very important that we do not develop redundant standards, per an
>> essay "What is Good Design?" from Bert Bos, the CSS Chairman:
>> Lastly, using XUL and XBL will undermine use of XSLT and the other redundant
>> W3C standards mentioned above.
>Oh, what a nice side-effect, we should push XUL and XBL harder :-)

March your camp into Bataan if you wish...

>See above, my image resizer. One short XBL file only. Just try to do
>that with all the specs you mentioned, in a simple way, dealing
>correctly with anonymous content.

Please define "anonymous content", and give a canonical example, just to be
sure I understand specifically what XBL means by it???

Then perhaps I will attempt to write your resizer widget using W3C standards
such that it respects your notion of "anonymous content".

-Shelby Moore

Received on Thursday, 26 December 2002 22:00:06 UTC