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

On Saturday, January 4, 2003, at 10:00 PM, Sandy Moss wrote:

> 3. This is all tangential to the real issue at hand
> anyway, and that is: does XBL even change tag
> semantics?  Perhaps superficially, but a graphical
> comparison of the language to others (CSS, Delphi,
> etc.) reveals an axiomatic TSGR[1] of no more than
> 20-30%.  This would seem to indicate, unless anyone
> has a more normative source, that semantic
> metamorphosis in XBL is negligible at best.
>

This seems to be the crucial point.  Does XBL have any more impact on 
semantics than CSS already does?

An XBL binding consists of four distinct subsections.  The first is an 
anonymous content template.  The second is a subresources section 
(which can include scoped stylesheets, scripts, and image resources).  
The third is an event handlers section.  The fourth section consists of 
methods, properties, and fields that can be defined on the object (and 
is roughly analogous to an IDL description of a new DOM interface along 
with the implementation of that interface).

Much of the attention seems to be focused on the anonymous content 
feature of XBL.  I would argue that this feature has no more effect on 
semantics than the CSS 'display' property.  Using pure CSS, I can turn 
an <li> into a table-cell, or make a <table> into a block, or generate 
content before and after an element. The rendering object tree is 
already malleable from a CSS perspective, so in my mind there is little 
difference between the ability to morph the rendering object used and 
the ability to create an invisible subtree of rendering objects.  
Neither impacts the source document at all, so in my opinion the impact 
of CSS and XBL is similar.

The subresource section and the event handlers section don't affect 
semantics.  That leaves the implementation section.  The part of this 
section that could be considered problematic is that XBL can override 
methods and properties on an element, so it could in effect be used to 
extend and/or replace methods and properties outlined in the HTML DOM.  
For example, I could override getAttribute on all <table>s in a 
document using only CSS/XBL and make it do something completely 
different.

There are solutions however if this is deemed to be a problem.  
Standard interface methods/properties/fields could be designated as 
such, and an XBL implementation could be prevented from overriding them 
(although I should point out that some nifty examples have been built 
by overriding built-in DOM methods/properties).

Dave
(hyatt@apple.com)

Received on Sunday, 5 January 2003 01:59:39 UTC