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

Hi David from Apple.  Glad to see you enjoined the discussion.  Per the
private email you sent me, you have a _vested_ interest in XBL also correct?


At 10:58 PM 1/4/2003 -0800, David Hyatt wrote:

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


Now that we agree that specification does not completely _control_
semantics, because implementation does also _control_ semantics (i.e. that
semantics is not orthogonal to implementation)[1], then yes I AGREE this
becomes a crucial part of discussion.

In fact, this was the original focus of my discussion (subject "CSS is
wrong W3C layer for semantics") before Ian diverted me into having to prove
first that specification does not completely _control_ semantics[1].

Indeed XBL has infinitely more power to change semantic implementation than
CSS does, because XBL can replace the implementation of HTML 4.01 tags and
it can define implementation of new tags.

Afaik CSS can not generally do this.



[...]
>Much of the attention seems to be focused on the anonymous content 
>feature of XBL.


Not true.  The <handler> syntax merged with <content> feature is what
really makes it different than CSS


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


I agree that the generated content features of CSS are dangerous, but not
so much, because you can not (afaik) change a <select> into a submit button
using CSS.  You can with XBL.


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


It is not only that XBL gives you more power to change semantic
implementation using events together with general content replacement, but
more importantly it is the application of XBL to making custom widgets.

XBL is targetted to swappable implementation (or augmentation) of tags.
CSS is not.  That is why they should be orthogonal layers.


>The subresource section and the event handlers section don't affect 
>semantics.

False.  The event handlers is one of the most dangerous aspect of changing
semantics.  If a <select> submits a form, then that is a major semantic change.

I am not against events (because we can do that now with HTML events).  I
am just against merging into the CSS layer all those dangerous semantic
features.  XBL would be okay if it was orthogonal to CSS and DOM.  Then it
would be essentially XSLT.


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

Agreed this is another problem.  Thanks for pointing that out.


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


Thanks for supporting my argument of how dangerous it is and how brittle
code has already been written.  You have a lot of courage to go against
your own vested interest in XBL.  I applaud you for being objective.


[1] http://lists.w3.org/Archives/Public/www-style/2003Jan/0087.html

-Shelby Moore

Received on Sunday, 5 January 2003 03:30:09 UTC