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

On Sunday, January 5, 2003, at 07:21 AM, Chris Lilley wrote:

> DH> This seems to be the crucial point.  Does XBL have any more impact 
> on
> DH> semantics than CSS already does?
>
> No, it doesn't.
>

Yes, this is my position as well.

> DH> Much of the attention seems to be focused on the anonymous content
> DH> feature of XBL.  I would argue that this feature has no more 
> effect on
> DH> semantics than the CSS 'display' property.
>
> Or the 'content' property.
>

Right.  Generated content is extremely similar to XBL anonymous 
content.  The former is just a subset of the latter.

> If the rendering tree needs to be different in structure to the
> content tree (and it does, often) and if events are to be handled on
> the content tree (as DOM does) but also, events need to be handled in
> the rendering tree because it has actual structure; and if
> manipulation needs to be done in the content tree in real time (DOM,
> etc) with the results reflected into the rendering tree in real time
> (thus ruling out non interactive, batch-oriented processes such as
> XSLT) then an approach which produces invisible or
> unidirectionally-linked (child points to parent, parent does not point
> to child) XML shadow content is a sound architectural approach.
>

I believe so.  I'm glad someone else agrees.  :)

XBL is also extremely efficient (i.e., easy to implement efficiently) 
because the anonymous content is scoped.  This concept of scoping the 
content in a document is an important feature of XBL and I think the 
approach is more efficient than XSLT.

For example, scoped stylesheets in XBL apply only to the bound element 
and to the anonymous content within the bound element, and they exist 
at their own levels in the cascade.  This means that the rules in 
scoped sheets can be sorted together by specificity without having to 
mingle them with the sorted rules in outer scopes (like all the author 
rules in the main document), and it means that you keep these sheets 
out of the way of the rest of the document content.

Furthermore, since the sheets don't load unless the binding is actually 
used, you end up not paying the cost for user agent CSS until you 
actually use the tag in a document.

A great real-world example of this is Mozilla's non-standard 
implementation of the IE tag <marquee>.  It's done entirely using XBL, 
and because of that you pay no cost (not even code cost or parsing 
cost) until someone actually uses a <marquee> in a document.

Events are also scoped, and they have special behavior when they cross 
scopes (they either have to be retargeted to the bound element as they 
cross a scope, or they get canceled because the event had no meaning in 
the outer scope).  This is done both for efficiency and to uphold the 
mantra that the DOM must not be altered, which means events that flow 
through the DOM will never expose anonymous content.

For example, if you attach a DOMAttrModified listener to the root of 
the document, and then attributes start changing on anonymous content, 
no events will be delivered to any of the explicit content in the 
document.  They will stay within the appropriate scope and not bubble 
out to (or be capturable by)  explicit content.

I don't see how XSLT matches this behavior.  If I understand XSLT 
correctly (and I freely admit that I may not), it transforms a source 
document into a result document, which means that

(a) The result document would be tag soup, with the internal 
representations of widgets being exposed as explicit manipulable 
content in the result document
(b) The transformation is done once and is not dynamic.  What happens 
when I dynamically manipulate the source document?  If the results 
can't be reflected dynamically into the result document, then XSLT 
doesn't even come close to what XBL can do.  Moreover, can I 
dynamically change some property of an element in the source document 
and have its corresponding output in the result document completely 
rebuild itself to match some new template?

The issue of dynamism is important, because it is not just some edge 
feature of XBL.  It is integral to the functioning of XBL, and it is 
used throughout the Mozilla user interface (even in some very basic 
user interface elements).

Dave
(hyatt@apple.com)

Received on Sunday, 5 January 2003 13:28:41 UTC