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

At 01:22 AM 1/5/2003 -0800, David Hyatt wrote:
>> Now that we agree that specification does not completely _control_
>> semantics
[...]
>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) :)


Okay but there is no use discussing whether XBL can change semantics more than
CSS can, unless we first agree that implementation can change semantics.

Regarding your points about presentation vs. semantic change, there is a very
clear distinction.  If an implementation change violates the specification,
then it is non-conforming and thus it is a semantic change.  All other
implementation changes are not semantic changes (just presentations).[1] [2]



>> 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"? 


Non-conforming semantic implementation is any change to the implementation of
markup which is non-conforming to normative specification.


[...]
>CSS can decide how something will be rendered, e.g., for some made up 
>tag you could say:
>
>goo { display: table }


http://www.w3.org/TR/REC-CSS2/visuren.html#display-prop

"Conforming HTML user agents may ignore the 'display' property."

Thus CSS "display" controls semantics because it admits it is not conforming.


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


At the point it becomes non-conforming to the markup specification.


>Is it specifically event handlers that you object to?


I object to putting more non-conforming power in the CSS layer, when it isn't
necessary to accomplish the kind of goals people have with XBL.  Similar goals
can be done with XSLT (subject of this thread: "XBL is (mostly) W3C
redundant").

Also combining events non-orthogonally with the semantic implementation is
another major problem.  Much better if used the "id" binding of events to
semantics as in XEvents.


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


Yes but that can still be done with orthogonal event standards such as
XEvents.  As I explained in earlier thread, XEvents can bind to the markup
orthogonally.  Whereas, XBL combines the events and content in same binding.



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


See above ... CSS "display" is non-conforming to normative markup.


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


See above ... CSS "display" is non-conforming to normative markup.



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



Now we are getting to core of my argument.

Yes that is another problem.  The semantic implementation should be as
orthogonal as possible to the presentation implementation layer.


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


Again see above.  Presentation is conforming to normative markup.



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


Yes!  That is the correct direction.  Put the binding at the semantic layer
(before the parser and DOM).  And then make the events bindings orthogonal
also.


>Note that XBL itself is largely agnostic regarding how it is bound.  


Cool!  But the <handler> is bound non-orthogonally.

And the anonymous content is not exposed at a standard layer in the way a
pre-parser transformation does...but that will be longer debate so let's save
that one for later discussion...  Let us first focus on areas where we agree!!


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


Because you are merging a non-conforming layer with a (largely) conforming one.

If you truely want me to go into lots of detail, then I need to first see that
we truely have an attitude of wanting to do productive work here in this
thread.  So far, I see that from you.

I would like to go further in areas we agree first, before diving deep into
areas we disagree.


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


Agreed.



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


Agreed.  Thanks.  I am willing to meet you halfway.  This is the spirit of
production.  Thanks.


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

Okay that is good question to explore.  I always wanted to get to that point. 
But first we need to make sure we have the enough agreed foundation on what is
fundamentally agreed and not agreed.  I am not going to jump n detail (as I did
with Ian), and then have the foundation of debate constantly shifting.


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

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

-Shelby Moore

Received on Sunday, 5 January 2003 05:06:16 UTC