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

On Sunday, January 5, 2003, 7:58:43 AM, David wrote:


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

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.

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.

DH> Using pure CSS, I can turn
DH> an <li> into a table-cell, or make a <table> into a block, or generate 
DH> content before and after an element. The rendering object tree is 
DH> already malleable from a CSS perspective, so in my mind there is little 
DH> difference between the ability to morph the rendering object used and 
DH> the ability to create an invisible subtree of rendering objects.

Creating an invisible subtree, originally in XML and indirectly linked
to the content, which does not contaminate the real content tree, is
far preferable (and has less influence of the "semantics" such as
they are than

a) hiding the content behind the server and delivering only an "html
rendering tree" (a common xslt approach)
b) creating visible subtrees that affect "semantics" and navigation
and DOM calls
c) Loading up CSS with a whole load of pseudo-markup to give some sort
of structure for generated content.

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.

Making the binding of the shadow content to the real content requires
some sort of selector mechanism such as XPath or XCSS selectors or
....

XBL is one system which uses CSS selector syntax to make such a
binding. I don't see anything wrong with that.


-- 
 Chris                            mailto:chris@w3.org
 CSS WG chair alumni ;-)

Received on Sunday, 5 January 2003 10:21:12 UTC