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

For some unknown reason, my replies are being correlated into a separate thread
when www-style is sorted in thread order.  I think it may have something to do
with the length of the Subject and the TAB character that is somehow getting
inserted into the Subject.  Hopefully participants can correlate the 2 threads
on Subject.

Any way, I wanted to elaborate on my last response to Daniel Glazman,
specifically in regards to "anonymous content".

After dinner, I just re-read (for 3rd time) the relevant portion of the XBL

The short definition is:

"Because this content is not visible to its parent element, it is said to be
anonymous content."

"this content" refers to the implementation that is bound to the markup

Again I will re-iterate that afaics, XSLT can make the necessary tranformations
to substitute a "content tree" in place of an extensible abstract markup
element.  Instead of placing the binding at the CSS layer, it places the
binding at the XSLT layer which sits on top of XHTML DOM layer.  So thus XHTML
DOM does not depend on CSS, as it does in the XBL - CSS binding model.  Instead
of swapping bindings by swapping CSS (and XBL), one swaps at XSLT layer.  Thus
semantic abstraction binding is at higher level of abstraction than (layer on
top of) XHTML and CSS.  XHTML are the basic building blocks of content markup. 
CSS layer is even less abstract and getting closer to presentation layer.

Again I will relish the challenge to make actual functioning examples.  After
all, that is my whole point of seeking a standard for the things I want to
program.  Only then we will truely demonstrate generality and any limitations. 
It may turn out that XBL does some important things that only it can do, and in
which case maybe this discussion will further that, as well as illuminate
weaknesses to improve.  Or more likely, we will confirm my assertion that XBL
is mostly unnecessary distraction from a focus on XSLT (and wdiely implemented
extensions to XSLT that already exist).

Again I welcome civil and reasoned technical discussion as we proceed along
this line of analysis.  After all, I started this line of inspection in earnest
by first *GENUINELY* pondering whether I wanted to build my new applications on
top of Mozilla and XBL.  That is when I realized it was not transportable.  And
that it depends on C++/XPCom code for new base widgets (menubar, etc).  Then I
started looking at why and what are the most practical solutions.  Then it so
conveniently dawned on me that the solutions were already W3C standards (or in
process).  And that XSLT is already widely implemented.  So I came here to
share my discovery and explore it with the revelant community.

I DIGRESS:   Even XSLT and XML DOM is now implemented in PHP (my new favorite
language in place of C++ for most programming, especially they are fixing the
OO weaknesses in Zend 2):

Imagine soon it won't be too hard to write a browser in PHP.  Maybe leverage
Gecko (NGLayout portion of Mozilla only).  Or maybe rewrite if Gecko is not
well modularized from rest of Mozilla or device/OS.  Write once, run every
where, may soon become a reality, but perhaps not the way people expected
(Java).  And also hopefully a proliferation of browser code bases for W3C to
consider when making standards.  I do not think it is good for Mozilla to be
the only major alternative to IE.

-Shelby Moore

Received on Friday, 27 December 2002 01:24:17 UTC