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

Ian,

Imo, you have made some excellent points in this response, and in other
cases you have continued to make false assumptions.  I will point out both
in fair spirit.  My conclusions is still the same, because of the false
assumptions I will point out below.

This really has to end some time, but I will reply again in detail.  At
some point, I will just have to let you have the last word, but that will
not mean that your final assertions are entirely correct.  It will just
mean that I (and probably every one) doesn't have time to read such
detailed debate.  BTW, I do enjoy your currect objective method of debating. 

Again I think my summary conclusion 2 days ago was sufficient stopping
point for now (until I have more examples to show XSLT can indeed to do
most of what XBL can that is useful).  I think it in a non-detailed manner
makes the same good points for XBL that you make here, while also pointing
out the disadvantages of merging layers:

http://lists.w3.org/Archives/Public/www-style/2002Dec/0228.html



At 09:20 PM 12/31/2002 +0000, Ian Hickson wrote:

[...]

>It appears you misunderstand what XBL's problem space is.
>
>XBL is a way for authors to provide complex presentations and
>behaviours at the user interface level, without changing the document,
>much as CSS does with providing stylistic effects at the user level.


I started this thread and the subject of the thread contains "CSS is wrong
W3C layer for semantic behavior *markup*"

You are making IMHO some incorrect assumptions below, and then follows that
you assert that CSS is the correct layer.

Fundamentally, CSS is the wrong layer to take something that is
*semantically* defined (i.e. markup) and map it to implementation which is
not *semantically* related.  CSS selectors allows one to select elements of
markup based on attributes which are not related to *semantics*.  Whereas
XBL binds (replaces) the implementation of semantic markup.

Why?  Because take for example font style.  When you change the font of a
paragraph, you are not changing semantically what a paragraph is.  You are
merely providing implementation details (hints).

What XBL does is provide both the power for semantic implementation and
also the ability to select non-semantically related sets of elements.  That
is a mismatched merging of what should be in two different layers.  If am
not saying take this capability away.  In fact, I have also proposed using
CSS selectors to bind XEvents:

http://lists.w3.org/Archives/Public/www-style/2002Dec/0077.html

The key difference is that I propose that CSS selectors for XEvents be a
separate layer from the *SEMANITC* binding.  Do not skip this point.  It is
crucial.  Let me try to finally explain this key point in a way that is
100% clear.

In XBL, afaik you can map semantics (the markup) to other content,
implementation, behavior, events, style, DOM, etc..  In other words, it is
not ONLY binding events.  It is mapping the entire semantic implementation.
 That is what I mean by *SEMANITC* binding.  So if you apply CSS selection
logic at the XBL layer, then you are replacing semantic binding with CSS
selection binding, but instead of doing it in layered way for each
orthogonal component of implementation, XBL does it in a global way which
destroys the clear connection between swappable semantics.  Your date and
time was an excellent example of this failure, because you were able to
remap a single <A> to mean date, without globally mapping all <A> tags.
You changed the semantic meaning of one <A> tag and not the rest of them in
the document.  I have no problem with changing the semantic implementation
of a tag, but morphing the document into inconsistent semantic meanings is
not good for semantic web.  Also it will lead to brittle documents.
Whereas, if the semantic layer is orthogonal, then you are forced to
semantically markup the date, and then carry on with redefining it's
semantics.  XSLT can indeed do all the important swappable semantics of
XBL, but it forces you to obey semantics at the semantic binding layer, and
then you can use implementation details (such as CSS selectors) at the
implementation layer.

P.S. I *sincerely* thank you very much for making that <A> tag example
because it was the most succinct way so far for me to explain how semantic
layer utility can be destroyed by XBL.  You saved me some work.  Thanks.

Until you grasp and agree with the importance of keeping the semantic
binding layer orthogonal, then the whole debate is just circular argument
with two people that have totally different basis.  That is why I made the
summary that says some people prefer to merge the semantic binding layer.
It is bad for the semantic web, and it isn't necessary to do compelling
work that is in high demand, and in fact XSLT can do it now, while XBL is
just a toy for Mozilla.  But I can't change the basis that people operate from.

I agree the CSS selector logic is powerful for implementation of style
details.  But it should be keep in that layer and not merged with the
semantic binding layer.  If someone wants to redefine semantics
inconsistently, then let them jump thru more hoops because it isn't a
useful or necessary way to do markup.  Afaics, one can always create a
semantic markup to make equivalent function.

I do promise to share some more complex examples in future to provide more
confidence that XSLT can indeed do the things that are in high demand.



>For example, if you want to add some decorative text to a document,
>you can do so using CSS generated content:
>
>   input::after { content: "Default: " attr(value) }
>
>However, if you need to make an element have a complex shading effect,
>e.g. fading in and out with mouse-enter and mouse-exit events, then
>you would use XBL instead.


XSLT can output content which does effects like this.


>Just as with CSS, the bindings should be optional:


XSLT bindings (transformations) are optional and swappable.


> the document should
>not lose meaning when stylesheets are disabled. This means that it
>should not change the DOM of the document, as seen by other documents.


You are trying solve the problem of semantic standards by changing what
semantics is.  Semantics is "consistent meaning" else it loses utility as a
layer.

Instead if you want certain custom tags to be a standard in DOM, then do
that.  You will never provide infinite cases, but destroying consistent
semantic layer just so you can get custom tags in the DOM which mean
nothing to other layers (because they aren't standard custom tags), only
accomplishes reducing the utility of what semantic layer is for.

Not to mention how brittle every thing will get.

When the epiphany happens in your mind, you are going to realize why this
was such a crucial thread that needed to me made *NOW* before CSS is ruined.


>Bindings should be dynamic: it should be possible to change to an
>alternate stylesheet, and have the new bindings take effect without
>having to reload the document or even lose any DOM modifications.


Implementation style sheets yes.  But the semantic layer is the semantic
layer.  If you want to swap properly at the semantic layer then you need to
reparse it.  Any other methodology will be merging semantic layer with
lower layers, and then the basterdization of the utility of semantic layer
occurs (as detailed above).




>It is not a transformation language.
>
>It is not a "semantic binding" language.


False.  It is ALSO semantic binding,  and ALSO the other things which
causes the decrease of utility of the semantic layer.  I said that 2 posts
earlier.  You've got to really ponder deeply what I wrote above.  If you
still do not see my point, then we might as well just stop debating. 



>There is a strong demand for such a technology; this is why over the
>last six years first Microsoft, then Netscape, then Mozilla have all
>come up with proposals to address this problem.


Components of it are correct.  The ability to use CSS selectors to style
events is imho necessary (as I proposed above).  Merging it with semantic
binding it not correct.


>Whether the demand _should_ exist is not really something I,
>personally, can do much about.


The demand is real and I agree with it.  I also want to write applications
by reusing the web standards rather than to proprietary apis of OS vendors.

I only see that semantic layer is best left orthogonal.  If DOM extensions
are needed they can be done with tranditional standards efforts such as DOM
HTML, DOM XHTML, DOM CSS.  Will there be a DOM XSL-FO??  Etc..



>Addressing XBL's possible dependencies on other technologies:
>
>XBL depends on XML and the DOM in much the way that all XML-based
>technologies do. (Some technologies depend on the infoset instead of
>the DOM, but the idea is the same.)
>
>XBL does not depend on particular interfaces of the DOM. XBL does not
>depend on CSS. XBL does not rely on a particular scripting language.
>XBL does not depend on a particular event set.


XBL may not force you to use CSS selectors to make the semantic binding,
but it sure makes it possible.  Ditto with "handler" syntax (events).  In
every case, CSS may not force you to use it's features which allow merging
layers at the semantic binding, but in practice that is the way it can and
probably is used.

Also I sort of disagree with your statement that is doesn't depend on DOM
and CSS.  I think it is highly integrated with those.  The "black box"
separation is not there.


[...]

I will answer the rest in separate post because the email has gotten too
long for my email client :-)

-Shelby Moore

Received on Tuesday, 31 December 2002 21:10:40 UTC