- From: Shelby Moore <shelby@coolpage.com>
- Date: Sun, 22 Dec 2002 17:04:09 -0600
- To: www-style@w3.org
- Cc: Ray Whitmer DOM Chair <rayw@netscape.com>, Peter Trudelle Mgr XFPE <trudelle@netscape.com>
Before responding on this thread, I beg the reader to also read *entirely* the linked references and threads. 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 undermine layer modularity), "recursive" in yet not fully explored ways, "powerful" possibly beyond the primary goals (see Tim Berners-Lee's "principle 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: http://www.w3.org/Submission/2001/05/Comment I wish to add two comments: 1. XBL is (mostly) W3C redundant 2. CSS is wrong W3C layer for semantic behavior *markup* As W3C Team commented, the templating portions of XBL could be accomplished with XSLT, an existing, widely implemented W3C standard. The advantage of 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 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. 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. 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. 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 (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 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. 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 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 It is very important that we design the W3C standards such that we maintain the desired abstractness and orthogonality (modularness) of each layer standard. 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. 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. I am interested in these insights, but will also be considering Tim Berners-Lee's "principle of least power" and the primary goals: http://www.w3.org/DesignIssues/Principles#PLP -Shelby Moore
Received on Sunday, 22 December 2002 18:03:46 UTC