- From: Shelby Moore <shelby@coolpage.com>
- Date: Fri, 27 Dec 2002 00:24:26 -0600
- To: glazman@netscape.com (Daniel Glazman)
- Cc: www-style@w3.org, Ray Whitmer <rayw@netscape.com>, Samir Gehani <sgehani@netscape.com>, David Hyatt <hyatt@apple.com>
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 spec: http://www.mozilla.org/projects/xbl/xbl.html#anonymous-content 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 element. 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): http://www.php.net/manual/en/ref.domxml.php 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