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

Shelby Moore wrote:

> Before responding on this thread, I beg the reader to also read *entirely* the
> linked references and threads.

Given the fact you gave 12 refs, please apologize the fact I did not
read entirely all the specs you mentioned. Please also note I work with
XBL on a daily basis, used XSLT to produce the CSS 3 Selectors Test
Suite, and I think I know quite well what Bert Bos thinks of the Web,
past present and future (hey Bert, do we need a future for the Web
anyway ?-))))
Last detail: I am the co-editor of the BECSS spec that federated some 
time ago the Action Sheets proposal from Netscape and the HTC proposal 
from Microsoft. I know quite well this subject.

> My high level semantic (not my complete) summary understanding is that XBL is
> used to abstract extensible semantic (by meaning) content markup from the
> implementation and style.  In content markup, we merely declare, "Widget", and
> XBL binds the abstract content markup to the widget's implementation details. 
> XBL also provides for reuse of widgets in other widgets:
> 
> http://www.w3.org/TR/xbl/
> 
> XBL was submitted to W3C, by AOL on behalf of itself and mozilla.org:
> 
> http://www.w3.org/Submission/2001/05/
> 
> The W3C team, apparently with Bert Bos of CSS WG listed as editor, has already
> 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. According to him, it was simple and fast. I use
his spinbuttons in my CSS Editor for Mozilla Composer. Trivial.

> undermine layer modularity), "recursive" in yet not fully explored ways,

Yeah, yeah, we end up with endless loops every second in Mozilla.
More seriously, there is no problem here.

> "powerful" possibly beyond the primary goals (see Tim Berners-Lee's "principle

Yes it is powerful. I have just added to Mozilla Composer the ability
for a document's author to resize images using the mouse. 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.

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

> http://www.w3.org/Submission/2001/05/Comment
> 
> I wish to add two comments:
> 
> 1. XBL is (mostly) W3C redundant

Let's discuss 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. Please note that the CSS WG
has proposed behavior-like extensions to CSS for UI, and that the
'display' property is almost a behavior declaration in itself.

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

> 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. Think of 
another language, 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 -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.

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

Boarf. The rendering of a document depends on a rendering engine anyway.
It depends on a style declaration, hard-coded or declarative, anyway.
Does it make you scream ?

> Using XSLT for templating does have the attribute that is just a transformation
> layer and thus the DOM will have no concept of the original content markup
> abstractions-- only the templated output.  However, this may be desireable, for
> the same type of reasoning of orthogonality.  The DOM is not designed to be the
> same layer as abstract content markup.  One could possibly design a DOM-like
> layer in between XSLT and XML if so desired to model XSLT transformations.  My
> fundamental logic is that although XSLT may not be "complete" solution, it
> doesn't violate the critical orthogonality of design layers (CSS and content
> markup, or DOM and content markup).  And I think it does accomplish the main
> goal of abstracting (make orthogonal and separate) extensible semantic content
> markup from it implementation layer.

Explain me how can XSLT generate and manipulate anonymous content ?

> 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 markup.
> 
> Most of the other benefits of XBL (and XUL) can be accomplished with existing
> 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.

> And to build entirely new widgets (as opposed to extending existing ones) not
> in XForms or XUL, there is the DOM Views and Formatting proposal I am working
> on, to abstract the presentation state.  I'd really appreciate if some others
> would enjoin to investigate the importance of this proposal.
> 
> http://www.w3.org/TR/DOM-Level-3-Views/views-formatting.html 

Hammers are too heavy to efficiently smash flies.

> (My) Proposal for Improved/Simplified ViewsAndFormatting Segment *abstract*
> model
> http://lists.w3.org/Archives/Public/www-dom/2002OctDec/0185.html
> 
> Exposing the critical ACTUAL style values?
> http://lists.w3.org/Archives/Public/www-dom/2002OctDec/0154.html
> 
> 
> The original goal of putting behavior in CSS was apparently to provide a way to
> "attach style to structured documents":
> 
> http://lists.w3.org/Archives/Public/www-style/2001Aug/0029.html

Er, did you really read that message ? In particular, Ian Hickson's
first lines ?

> I think this goal can be accomplished without violating the orthogonality
> (separation) between markup and style, perhaps similar to how XSL and XSLT are
> to be used together to style documents (something I admittedly haven't studied
> 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.

> 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 Design":
> 
> http://www.w3.org/DesignIssues/Principles#Modular

I know this approach. I pushed it myself. And abandoned it. This is a 
very nice conceptual approach but not pragmatical.

> 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 being
> my proposal is abstracting styling of behavior details not semantic *markup* of
> behavior:
> 
> http://lists.w3.org/Archives/Public/www-style/2002Dec/0077.html

Still cannot deal with anonymous content.

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

> For example, the primary goal of content markup is to declare abstract semantic
> structure, so that it can be used in powerful ways.  For examples of "ways",
> please read Tim Berners-Lee's "principle of least power":
> 
> http://www.w3.org/DesignIssues/Principles#PLP
> 
> So we don't want standards such as XBL which instead of using existing
> standards as "black boxes", instead requires changes to those standards (e.g.
> proposed -moz-binding in CSS) which are quite different from the original
> abstraction of the standard.
> 
> 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:
> 
> http://www.w3.org/People/Bos/DesignGuide/redundancy.html
> 
> 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 :-)

> I am assume there will be (hopefully civil and not inflammed :) responses
> explaining the things that XBL can do, which W3C standards mentioned above can
> not do in unison. 

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.

For more info, see the attachments to 
http://bugzilla.mozilla.org/show_bug.cgi?id=47066

</Daniel>

Received on Thursday, 26 December 2002 08:27:14 UTC