- From: Shelby Moore <shelby@coolpage.com>
- Date: Tue, 31 Dec 2002 10:09:18 -0600
- To: Ian Hickson <ian@hixie.ch>
- Cc: www-style@w3.org
At 11:15 AM 12/31/2002 +0000, Ian Hickson wrote: >>> [ snip a very example of XBL and a request for an example of how to >>> do the same using existing W3C technologies to demonstrate that XBL >>> is "W3C redundant" ] >> >> What is the compelling use of such an example? > >There is no compelling use of such an example. So the purpose is to prove that XBL can do useless things? Why should I waste my time on that? >I gave you a complex example with a real use case and sample XBL code, >you said it was too complicated for you to show us how to write the >equivalent in XSLT. I said "this minute". I promised to come here "couple (or few) months" when I am actually doing commercial development with XSLT. You've been doing "commercial" development with XBL for apparently some months now. The examples I am being asked to rewrite in XSLT have some years of development behind them. I say "commercial" in quotes because none of it runs on Internet Explorer (or any other non-Mozilla UA), so it is just an exercise in "Brain%^$%". I did not submit XBL to W3C. I am just provided a logical reasoning as to why it is W3C redundant. It is up to the submitter to prove it is not, with compelling use examples. It is up to you to work thru XSLT and prove it can't be done. I will share my work as I do it. But I will not be forced to play useless mind games with no $ compensation. >I gave you a real use case that is implemented in XBL that I use on my >Web site, you said it was possible to do the same in XSLT but told me >to go read the spec instead of asking you for the equivalent in XSLT. Isn't that what you say to people who ask for help with implementation in this list? This list is not for me to teach you how to use XSLT. If you want to refute my points, then prove it. >I gave you a trivial example that is also a real use case that is >implemented in XBL, you told be that I should (a) change my markup and Ian you just don't get it. I don't see any production in repeating myself. >(b) not ask for the feature because it was "not orthogonal". I told you how it could be done in XSLT. If you prefer to morph into date, the contents of an anchor tag (semantically has nothing to do with a date) that is not semantically marked up as a date, then go ahead. Have fun redefining the semantics at the implementation layer. Find more ways to mix up the layers. By all means go ahead and destroy the ability for separation between semantics and implementation. >I gave you a very simple example that only took me 30 minutes to write >from scratch in XBL, you told me that the example was not compelling. You agree it is not. >Are you actually able to give _any_ example of XSLT doing the >equivalent of XBL? I have given 2 simple examples and then described how to accomplish the main features of XBL that are desireable: 1. Binding of semantic markup to anonymous content (with additional benefit of being orthogonal to the rest of features unlike XBL) 2. How to make events compartmentalized (without actually forcing a single event mechanism). 3. How to inherit attributes from markup into arbitrary implementation (inheritance) Etc. >Even just one of the above four cases would be a wonderful start. I haven't seen you prove how XSLT can not do a compelling example. Every conceptual point that has been raised, I have refuted. Even your incorrect argument about namespaces which you abandoned and never admitted I am correct. You just keep piling on new mind games to save your ego. Go ahead. I am not stopping you. I will repeat for the 4th time, that I have promised to come back here and share commercial, complex examples as I implement them. >The only XSLT you have provided us does something that has nothing to >do with XBL: changing one semantic element for another, without >defining any of the behaviour. You need to lookup the definition of "semantic". The "meaning" of a <select> is to be able to select from a list. A radiobuttons set is semantically the same, using a different behavioral implementation (presentation). >> Doesn't this example basically prove that XBL is non-orthogonal to >> the DOM, which I have already argued is bad design. > >XBL is not orthogonal to the DOM. Indeed it is (amongst other things) >a way of creating now DOM interfaces for elements. Would it make it >more acceptable to you if XBL was called "DOM Level 3 Bindings"? DOM is orthogonal to semantic markup. If you did that, then DOM would lose it orthogonality to semantic markup, because of the semantic binding capability which also merged into XBL. >> You can disagree with me that orthogonality of DOM and XBL is >> important. > >The entire _point_ of XBL is that it be a way of extending the DOM, >binding elements in the document tree to stylesheets, event handlers, >properties, methods, and content nodes. I know. That is why I am against it. It is spagetti design. >It allows you to take a document tree, and augment it with >presentational behaviours without polluting the document tree, without >exposing style rules to unrelated elements, and without any impact on >the window's scripting namespace (something which is vitally important >in the real world). You can do all these with XSLT and not loose orthogonality. The one thing you can't do with XSLT is have the semantic binding layer be interactive with the DOM. Thank God! If you don't agree with me, then fine. I am not going to repeat this point any more. I have said it as many different ways as I can reasonably think of. >> I have not studied it. Your description of it's function does not >> inspire me. I think my example to convert <select> to radio buttons >> was more inspiring. > >Converting <select>/<option> elements to <input type="radio"> elements >is exactly the kind of thing which XSLT is designed for. XBL does not >pretend to compete in that problem space. The main argument for XBL is for using the browser to make applications (part of XFPE). It is for abstracting semantic markup with swappable implementation. That is the same problem space of XSLT. Now if you are referring to the ability to DOM-CSS "spagetti" capabilities of XBL, then I agree those are not the problem space of XSLT. If you want to write applications that merge those layers, then go ahead and watch your code break horribly in future. >XBL, on the other hand, was designed to take <select> elements and >imbue them with the dynamic behaviour required for the user to >actually be able to use them. XSLT can do this. I have promised to share complex examples in future as I implement them. If you believe XSLT can not, then prove it, if you are impatient. You aren't paying me. I did not submit XBL to W3C. >You are the first person I have seen claim that XSLT is able to solve >this problem. The W3C Team said if before me. Apparently you did not read their comments about the XBL submission: http://www.w3.org/Submission/2001/05/Comment "An alternative approach might be to use XSLT to transform a source document to one that includes the fragments, although the disadvantage will be that the DOM contains the expanded document and no longer only the original. Also, this approach does not really reduce the number of different technologies involved." Note that W3C Team did not say that the different technologies involved had to be used non-orthogonally with XSLT. I deduced that advantage and came here to add that point to the considerations for making XBL a standard. >> You've apparently proved that XBL is good at making inseparable >> dependencies between CSS, DOM, events, and XBL. > >I have never claimed the opposite. Could you explain why this is a >problem? (Preferably without using the word "orthogonal", since I do >not really understand what you mean by it; and yes, I have looked it >up in a dictionary.) As I said, we have different basis. I have a lot of experience in making huge code bases that I want to live as long as possible. Until you understand the mistakes of non-orthogonal design (and the hard way on your pocketbook) then you probably will not appreciate it as a priority, nor understand it well. So for me give a class here in this thread of benefits of orthogonality in OO design is beyond the scope of this thread. That is why I gave up trying to debate you. You want the non-orthogonal capabilities of XBL. I can not debate personal preference. My quickest summary of "orthogonal" in this context is to make each standard a "black box", so that any other standard can be swapped in without needing an upgrade to any standard or to the UA.The problem with making standards that syntactically merge the other standards, is that the other standards are no longer swappable. It also encourages the type of examples you created, wherein you prioritize implementation over semantics. You soon end up with very brittle code bases which have to go thru painful overhauls and delays for standards (and UA) upgrades. Netscape has a history like this, because they try to make really "cool" things in a hurry. They have a strong need to make a big splash in market, so they tend to not really think thru orthogonality well. You can see this in almost every web extension they made, whether it be cookies or the original alignments for <img> tag. Most gets very excited to use new technology because it can do "neat" effects, without really thinking thru the long term design of the new capabilities. I think Netscape/Mozilla is at it's best when it follows W3 standards, not lead them. I could applaud their implementation of CSS for example. They just shouldn't just get too excited and revert to old mistakes. >>> I made a test driver app in HTML to test it: >>> >>> HTML: http://www.hixie.ch/tests/adhoc/xbl/demos/simple-driver.html >> >> I get an error when running Internet Explorer. Unable to test. >> Line13: "undefined" is null or not an object > >Ironically, that error message is unrelated to XBL -- it is a bug in >IE's XML DOM. That is to say, a bug with its W3C standards support. How about not using propoganda. And just say that IE hasn't yet implemented fully a very new standard (relative to typical standards implementation timelines) When Mozilla people talk religiously, and especially try to impune any one who doesn't belong to their religion, it makes me want to ignore every thing they say. It is like the freak standing on the soap box in front of the mall. I am not a Microsoft lover. But I am really sick of the religious wars. I am just a developer who wants things to work. I do not like the noise of the cross-fire, most especially when it is directed at me personally just because I have a technical opinion about a Mozilla technology or business operation. I note that most (I think all) the people criticising my logic in this thread belong to the Mozilla church. >In any case, XBL is a Mozilla proprietary technology. To show the >equivalent in IE, one would have to use HTCs, of which I have no >experience. Or use XSLT, then it will run every where. I have made this point about 4 times already in this thread. >> Wait a couple of (maybe few) months, > >If it takes that long to write XSLT equivalents of simple XBL demos, >then that would seem to be a hands-down argument against ever using >XSLT. I am sure it is not because you have no free time, since you >have spent much more time replying to www-style e-mails recently than >I did writing the "simple" XBL demo. I did not come here on free time. I am being paid to advance a business objective. Writing complex examples with XSLT is not something we have started yet. I was actually hoping that someone would give me a compelling reason not to use XSLT. This was part of the research of whether to proceed, while also making a necessary point in the standards process for XBL. I barely have enough time to answer all these counter points. I have been having to stay up to 3am to try to answer and still get my other work done. >> then I will post some compelling complex examples. > >Compelling simple examples would be even better. I am falling behind on real work. When I have a breather (especially if I do not have to come here to make same points over and over in defense), then I will try to extend the <select> example to have some simple events. Would that make you happy? >> I assume the timeline for XBL standards consideration can tolerate a >> few months for competing examples. > >I am not aware of any W3C-led project to standardise XBL. Okay. I thought it had been submitted to W3C. >>> My apologies, it was certainly not my intent to offend or be >>> obscene. Brainfuck is the name of the programming language, there >>> isn't much I can do about that. >> >> And !@*%#$%^ is in the dictionary. > >I am not aware of any string of punctuation marks found in any English >dictionary, nor do I see the relevance here. > >How would you rather I refer to this programming language? I'd rather not. The point was quicly refuted by saying that XSLT outputs XML, so the possible apis are sufficient. There was no need to involve that shocking but otherwise irrelevant name in this context. Any way, never mind. [...] >> XSLT outputs XML and CDATA. That is about as general as you need to >> do any W3 content. > >Actually, it is not sufficient. Arbitrary XML and CDATA (which is just >a particular part of XML, so I'm not sure why you bring it out >separately) CDATA to emphasize scripting capabilities > cannot bind individual elements to CSS, I do not want them to!! This is the semantic binding layer, not the style layer. > nor can they >extend the interface of individual DOM nodes without polluting the >window's namespace. I refuted that already. See replies to Baron. > In practice, it's not even clear what the >processing model for XSLT is: does it replace the original DOM It has nothing to do with DOM. Linear logic starts from some point, say A (or DOM), and supposes B, then C. Set logic supposes A, B, C and their optimal organization = orthogonal > or is >it a dynamic layer above it (in practice only the first is feasible, >the second is a performance nightmare -- unfortunately, only the >second is acceptable from a binding point of view). I have said at least twice that I do not want XSLT to be interactive. I see no compelling need for that capability, which can not be accomplished at lower layer. If ever you want style at the higher layer, then extend XSL-FO as one possibility. CSS was not designed to be required layer of DOM or markup. >>>>> Turing complete does _not_ mean it can do anything -- XSLT >>>>> cannot, for instance, add a new DOM interface to an element. >>>> >>>> Of course it can. >>> >>> How? >> >> Afaik, using Javascript. > >An example, please? Javascript can add new properties and methods to existing objects. I am confident you know the syntax. Afaik, the DOM interfaces are objects in Javascript. >> People such as I, who have written huge projects with multiple year >> life spans, know something about the importance of OO design. > >Then you are probably ideally suited to see the benefits of XBL: it is >an object-orientated language, it encapsulates data and code, and it >performs simple wrapping and reordering in a way that is insulated >from the main DOM. Initially I did get excited about XBL. But then I saw how it merges what should be several classes into one class. >> You can have behavior without DOM or CSS. > >I have yet to see this. My simple example with XSLT <select> was an example. XUL is an example. XUL doesn't require DOM does it? If it does, then I will be against it. Because XHTML does not require DOM XHTML. The UA is free to implement only the layers it wants. Curious what Ray Whitmer (DOM Chair) would say. I think he has said to me that all of these things are not guaranteed in a UA. >Note that a transformation that someone includes DOM and CSS in its >output is still a transformation that depends on both DOM and CSS. But XSLT does not have to change in order to swap a new transform. The UA could even provide it's own transform. Or the visitor. That is one of the main points of CSS and XSL style. >> More importantly, the highest layer is binding of semantic markup to >> swappable implementation (anonymous content). The next layer below >> that is DOM. The next layer below that is style and events. > >In practice, behaviour is intimately linked to the content, the style, >and the events. You've helped my argument immensely with that statement. Precisely what XBL is trying to solve (abstract semantics), it is destroying. XEvents is an example of making events orthogonal to semantic markup. >Take, for example, a text input box. When you focus (event) the >control, it should change colour (style) and select all the contents >(DOM). That is implementation layers. > When you type (event) it should change the contents (content >model) and move the cursor (DOM). That is not markup. That is not DOM core. That is specific to DOM HTML or DOM XHTML. That is not guaranteed to be case for all presentation (UA). That is the whole point of making things orthogonal so easily swapped and supported every where (not only author but UA or visitor can swap). >XBL merges all the layers because that is what is required to solve >the problem of creating behavioural presentational bindings. The dependenices should be isolated in their layer, so that only one layer can be abstracted and swapped independently of other layers. >>>>> 2. The times next to the posts on http://ln.hixie.ch/ are, in the >>>>> markup, served as times in UTC. Using XBL [3], the times are >>>>> displayed in the local time zone. >>>>> >>>>> Can you do this is XSLT at all? >>>> >>>> >>>> Of course this is very easy. You would just enclose the time content in >>>> custom tag of name yuo choose such as <timezone>2002-12-27 23:21 >>>> UTC</timezone> >>> >>> Without changing my originial markup [1], how would you do it? >> >> Now you change the challenge again. > >No I don't. The challenge was "do what XBL does in XSLT". The XBL >doesn't _touch_ the markup. XBL most definitely provides binding of custom tags. You choose to make semantic assumptions about the <A> tag which imo are dubious. Did not make me desire to analyze, but I think perhaps you were relying on CSS selectors to get at that tag in non-semantic way. Again I would be against that sort of non-orthogonal design. You gave a very good example of hox merging layers causes XBL to encourage destruction of semantics. Now the <A> tag is no longer an anchor. It now means a date. Wow! That is so "neat" (undesireable). >> Why is it important I not be able to use a tag to semantic identify >> where the time data is? > >It's not. The tag, however, is an HTML element, already chosen, see >the site for the exact markup. > > >> I think the opposite. It is desireable to semantically markup the >> time. Imo that is the whole point of semantic binding... > >Since there is no date or time element in HTML or XHTML, the point is >moot. Thanks. You've just pretty much insured I have won the debate. That is why we have XBL and XSLT to extend the semantics. That is the whole point of their existence. You've thankfully shown that XBL has too much power in wrong directions because it merges layers and encourages the changing of semantics, rather than JUST swapping of implemention (binding to anonymous content). >>> I would be very interested in seeing the actual XSLT you would use >>> to do this. My thorough examination of the XSLT spec did not find >>> any date or time manipulation routines. >> >> Why do you want time or date functions in a binding layer? > >So that I can show the date and time of my Web log posts in the >current time zone, as I do now, in XBL. You missed the point. I know why you wanted to display the time and date. I just think those libraries should stay in Javascript where they are now. We don't need XSLT to have them. XSLT can output Javascript. >> Those are totally different things. You would advocate merging time >> and date libraries into binding layers? > >I'm not advocating anything at this particular juncture; I am merely >asking you to do using existing W3C technologies, what I do now using >a few lines of XBL and JS. I did to tell you how to do that example, except you want me to change the semantic meaning of the <A> tag. I think we agree XSLT can do it, by enclosing the date in markup with a custom tag such as <datetime>. My solution perserves semantics. >Are you saying this isn't what XSLT is designed to do? XSLT can bind semantics to arbitrary anonymous content which is the main thing mentioned in first paragraph of XBL specification. XSLT can not change semantic meanings by using CSS selectors to bind specific instances of tags which have another semantic meaning normally. >If so, I completely agree. But it _is_ what XBL is designed to do. I know XBL can do bad things. That is my point here. >>> The binding is not essential to the page -- which is why it is >>> bound from the CSS level. >> >> Non-compelling use example then? > >How do you mean? If the semantic binding is very optional then it is also probably not that compelling of a use. >>>> But XBL is not orthogonal to DOM and CSS as explained in previous >>>> posts. >>> >>> Indeed. XBL is a glue language to combine DOM and CSS together for >>> behavioural styling. >> >> Now we agree. :-) > >I have never disagreed with this statement. Okay then we agree. I think go back to my summary yesterday and see that I had already reached the conclusion that we are slowly migrating towards. Which is that it depends on your priorities for orthogonal design: http://lists.w3.org/Archives/Public/www-style/2002Dec/0228.html I'd be happy if we could agree on that summary (or you have the last word by making your points against that summary), then I will come back here later and provide more examples when I have more time and am actually using the work for business production. >> Except XBL also does semantic binding. > >What do you mean by semantic binding? Binding semantic markup (i.e. markup the way it is supposed to be used) to an implementation that is semantically consistent. >> I do not know how else to explain that if handler is in the syntax >> of XBL, then you won't be easily adapting your XBL code for XEvents >> or any other superior standard that comes along. > >XEvents is (merely) a specification that describes how to capture DOM >events, something which XBL already does. Why would XBL need or want >to use XEvents? Or anything else new. Just build it all into XBL, instead of reusing "black boxes". Watch me break in future. Watch me scream when Mozilla upgrades aren't fast enough to meet my new needs. >In any case, if it was so desired, it would be trivial to adapt XBL to >use the XEvents module syntax rather than the existing XBL syntax. > >I fail to see how this is a problem. See below for main problem... And also note that XBL encourages use of it's handler mechanism which will mean a lot of code to adapt. And also not that XEvents <onevent> can be placed any where and referenced by id. >> And remember when XBL needs to be improved, you have to wait for all >> UA to upgrade. > >Strangely enough, exactly the same applies to every single W3C >technology ever created as well. False. I can write new transforms for XSLT 1.0 that can use XEvents 3 or 4 or 5 or N. XSLT does not have to change. It is Turning complete (with XML generality), orthogonal "black box". >> Whereas with XSLT, you just change a transformation. > >You still have to wait for UAs to be upgraded before using new CSS, >DOM, XSLT, XML, XEvents, or other features. Yes but I can choose what is implemented on any given UA. >Don't forget, XBL uses JS, which is turing complete, so by your logic, >it can do anything. Why can't you just change the XBL binding just >like you change the XSLT transformation? Proliferations of non-orthogonal issues in XBL. At this point, I'd have to refer readers back to the entire thread. It may be difficult to wrap one's head (even mine!) around all the issues at once. >> If you want to try out XEvents, or any other technology, then you >> can, because the semantic binding is orthogonal to all the other >> layers of implementation. > >You still have to wait for XEvents to be implemented. We also have to wait for XBL to be implemented in Internet Explorer. What do you think the chance of that happening without major changes to XBL that make all Mozilla code inoperable? You can use XSLT today with many different technologies and run on both IE and Mozilla. See #1 of my post: http://lists.w3.org/Archives/Public/www-style/2002Dec/0201.html [...] >There was no sacrasm intended. I did actually think you meant it as a >compliment. Thanks. If I goofed up any politeness above, please forgive me did not sleep yet last night (10am). -Shelby Moore
Received on Tuesday, 31 December 2002 11:08:26 UTC