- From: Shelby Moore <shelby@coolpage.com>
- Date: Sat, 26 Nov 2005 22:16:50 -0500 (EST)
- To: www-style@w3.org
Assuming the consensus would be: http://lists.w3.org/Archives/Public/www-style/2005Nov/0170.html (note I misused word "you" at end of above post, I did not intend "you") (1) Another advantage over XSLT transformations that proponents of XBL have mentioned is that CSS is persistant, implicating that scripting on the DOM would automatically receive any XBL transformations. In other words, if <select> has been implemented as <a>s by an XBL script applied to all <select>s via CSS (pseudo code follows): <style>select { bind SelectAsATag.xml }</style> then instantiating a <select> in DOM would thus be automatically 'binded' (bound) to SelectAsATag.xml implementation. In short, the style bindings persist in DOM scripting. However, note that XAML has a <style> mechanism which appears to be persistant and apparently does not obscure semantics. There is a <style basedon="class"> syntax. I have not studied it enough, nor do I expect it is near it's final state of evolution. Also I suggest that in XAML (a possible future of the web), most scripting will happen in the "code behind" and thus the .Net CLR becomes the DOM. The implications are very important. And remember not to confuse the DOM with "markup layer". Semantics interopt above/on-top-of (not 'at') the "markup layer". (2) Just because we declare that semantic extension via XBL behind CSS is orthogonal to (off limits to) markup consumers, in order to avoid the interoperability issues, does not enforce it. We can not stop markup consumers (data miners) from trying to extract more information in order to gain a competitive advantage. Thus we are somewhat back to my original complaint. If you've conflated the layers, you've conflated them. Period. I am still open to the concensus in link above, with all caveats. Happy Thanksgiving to those in USA! -- Kind Regards, Shelby Moore http://coolpage.com
Received on Sunday, 27 November 2005 03:17:10 UTC