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

On Sunday, January 5, 2003, at 12:30 AM, Shelby Moore wrote:

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

I didn't agree to those points (which isn't to say that I disagree... I 
simply haven't read enough of the back posts yet to know what's going 
on) :)

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

Can you clarify what you mean when you say "implementation"?  That has 
a very specific meaning in the context of XBL (i.e., the 
<implementation> element), so I want to make sure I understand what you 
mean here.

CSS can decide how something will be rendered, e.g., for some made up 
tag you could say:

goo { display: table }

and suddenly goo is a table.  I guess I'm curious at what point the 
choice of render object starts dictating semantics.  Does "goo" have 
some meaning now that we know it will be a table?

Is it specifically event handlers that you object to?

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

Handlers do give you a lot of power, but they are necessary for certain 
presentational effects.  For example, maybe you want the letters in a 
link to pulse when you mouse over a link.  This effect is purely 
presentational, and CSS alone cannot achieve it.

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

You could use only CSS and make all <select>s into static text runs.  
The ability to pick choices could be taken away using only CSS.  Does 
this mean that CSS has changed the semantics of the select if it does 
this?

As for changing a <select> into a submit button, remember, XBL cannot 
alter the original document.  If the select has child options, then the 
only way to hide those options is with CSS.  XBL alone cannot do this.  
(XBL can position the options somewhere within an anonymous content 
template, but CSS would have to be used to hide the options).

So while you are right that a <select> can in effect be presented as a 
submit button, the only real difference I see between CSS and XBL in 
this case is that the former's generated content is limited, while the 
latter can generate arbitrary markup.  Both can dramatically alter the 
appearance and presentation of a <select> to the point where it is 
unrecognizable (and unusable).

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

I actually envisioned another form of binding for XBL (in addition to 
CSS and the
DOM), and that was through a processing instruction in the document 
that would then
use an XPath expression to attach a binding.

Note that XBL itself is largely agnostic regarding how it is bound.  
The goal was to allow
for maximal flexibility by implementing both a DOM mechanism and a CSS 
mechanism
for binding.

> Thanks for supporting my argument of how dangerous it is and how 
> brittle
> code has already been written.

Maybe you could elaborate on why XBL bound through CSS is dangerous.

Putting aside the arguments over what constitutes semantics for a 
moment, we all agree that XBL can essentially morph on element into an 
entirely different element, since it can essentially hide the element's 
original content and generate some new anonymous content of a specific 
type.

This does in effect give CSS (using XBL) the power to render an element 
as though it were any other kind of element, even though the source 
document's DOM remains unaltered.

So my (possibly naive) question is this: what is so horrible about a 
world in which CSS has that kind of power?

dave
(hyatt@apple.com)

Received on Sunday, 5 January 2003 04:23:25 UTC