- From: Martijn <martijn.martijn@gmail.com>
- Date: Tue, 7 Sep 2004 22:33:08 +0200
- To: Jim Ley <jim@jibbering.com>
- Cc: www-svg@w3.org
Ok, I was a bit (very) clumsy with my email. This was my e-mail correspondence with Jim. It might be interesting to some people. ------------------------------------------------------------------------------------------ Martijn Martijn to Jim More options Sep 5 (2 days ago) On Sat, 4 Sep 2004 17:59:33 +0100, Jim Ley <jim@jibbering.com> wrote: > > Could you list where I might find these primary use cases? A requirements > doc or something, it strikes me as rather odd to have a primary use case > defined that overrides to me what are much more persuasive use cases in > visualisation of structured data (in HTML as much as in SVG) I realise the > history of the technology may be as you describe, but that is just the > history of it. I think he means the XBL form controls developed in Mozilla (but which never has been activated in any release).. > > XBL is also aimed at HTML authors who may not be sufficiently savvy to > > master rudimentary SVG skills. :-) > > The stupid authors already have plentiful options for creating HTML forms - > indeed there's a whole specification being developed for them, I hardly see > it as logicial to hobble yet more specifications based on this rather > limited use set. Especially as I would've thought XBL as a reusable > component language from tool vendors is a larger use case than the stupid > author. As far as I can see, the sXBL specification is already rather limited. I don't know anything about SVG (I'm one of those stupid authors, I guess), but when I follow your logic, this sXBL specification is not nearly enough for any SVG author. But a simple (and limited) XBL specifation would certainly be welcome in the CSS/HTML world. Unfortunately, the situation seems to be different. SVG gets a simple sXBL specification and HTML has to wait (for how long?) for XBL 2.0, which will be large and difficult to use (and to implement?). Regards, Martijn ReplyForward Jim Ley to me More options Sep 5 (2 days ago) [Didn't you want this to go to the list?] "Martijn Martijn" <martijn.martijn@gmail.com> > As far as I can see, the sXBL specification is already rather limited. > I don't know anything about SVG (I'm one of those stupid authors, I > guess), but when I follow your logic, this sXBL specification is not > nearly enough for any SVG author. Why do you feel that? it converts arbitrary XML into an SVG rendering? That is very valuable, there's nothing really missing that's hit me so far but you can never really know until you're using it(it has everything RCC had, and using that proved very helpful) > But a simple (and limited) XBL specifation would certainly be welcome > in the CSS/HTML world. I'm sure too! I'm not completely clear why sXBL should be so far ahead in getting a simple reduced implementation of XBL, whilst XBL 2.0 has to ponder along giving everything - there possibly are good reasons or there could be silly ones, who knows, I agree it would be good for XHTML to get similar ability sooner rather than later, XHTML has virtually nothing going for it currently, a few good things like XBL might help there. > which will be large and difficult to use (and to implement?). I don't see any reason to believe XBL 2.0 will be difficult to use or implement, if it is something has certainly gone wrong! Jim. ReplyForwardInvite Jim to Gmail Martijn Martijn to Jim More options Sep 5 (2 days ago) On Sun, 5 Sep 2004 21:40:52 +0100, Jim Ley <jim@jibbering.com> wrote: > [Didn't you want this to go to the list?] > > "Martijn Martijn" <martijn.martijn@gmail.com> > > As far as I can see, the sXBL specification is already rather limited. > > I don't know anything about SVG (I'm one of those stupid authors, I > > guess), but when I follow your logic, this sXBL specification is not > > nearly enough for any SVG author. > > Why do you feel that? it converts arbitrary XML into an SVG rendering? > That is very valuable, there's nothing really missing that's hit me so far > but you can never really know until you're using it(it has everything RCC > had, and using that proved very helpful) Well, I don't feel that. In fact, I don't feel anything about SVG (because I don't know it). I guess I got that idea, by your reply that you thought that CSS selectors are too limited. It seems I'm wrong. Current Mozilla's XBL implementation is more powerful, by the way. > > But a simple (and limited) XBL specifation would certainly be welcome > > in the CSS/HTML world. > > I'm sure too! I'm not completely clear why sXBL should be so far ahead in > getting a simple reduced implementation of XBL, whilst XBL 2.0 has to ponder > along giving everything - there possibly are good reasons or there could be > silly ones, who knows, I agree it would be good for XHTML to get similar > ability sooner rather than later, XHTML has virtually nothing going for it > currently, a few good things like XBL might help there. Personally, I'm more interested in HTML without the 'X'. I think the current specification could also work in XHTML, but not in HTML. There, you would need the CSS way to attach a binding (like Mozilla does). The more I think about it, the more I just would like this sXBL specification to be also applied to HTML/XHTML/XML. But I guess there are some compelling reasons not to do that. ReplyForward Jim Ley to me More options Sep 5 (2 days ago) "Martijn Martijn" <martijn.martijn@gmail.com> > Personally, I'm more interested in HTML without the 'X'. I think the > current specification could also work in XHTML, but not in HTML. > There, you would need the CSS way to attach a binding (like Mozilla > does). No you wouldn't, there's no requirement for there to be an CSS binding for it to work in HTML - it could work identically, a CSS binding may be useful though - remember I'm not against a CSS binding, indeed I think it would be useful, it's just not useful in the context of SVG. The problems with it being in HTML are somewhat different - mostly the credibility problem, and the legacy problem, the credibility one would be tough to solve, and I'm not sure if it's worthwhile anyway - there's no point continuing to extend HTML with more and more stuff when the only likely implementors of it already support XHTML and it's better defined extension mechanism. The legacy problem is also much more insurmountable, you need to have your content work in older UA's that understand text/html, which means you need to hobble the specification to enable that to happen - or if you don't hobble it, then you don't get any take-up by authors anyway. > The more I think about it, the more I just would like this sXBL > specification to be also applied to HTML/XHTML/XML. But I guess there > are some compelling reasons not to do that. I doubt it personally, I would suggest they're most likely almost all political. (again why not on the list? - although I probably wouldn't have said that last bit in public...) Cheers, Jim. ReplyForwardInvite Jim to Gmail Martijn Martijn to Jim More options Sep 6 (1 day ago) On Sun, 5 Sep 2004 22:58:16 +0100, Jim Ley <jim@jibbering.com> wrote: > The problems with it being in HTML are somewhat different - mostly the > credibility problem, and the legacy problem, the credibility one would be > tough to solve, and I'm not sure if it's worthwhile anyway - there's no > point continuing to extend HTML with more and more stuff when the only > likely implementors of it already support XHTML and it's better defined > extension mechanism. With the credibility problem, you mean that the W3C stated that XHTML is the successor of HTML, and therefore it would be not credible for the W3C to extend HTML any further? I'm seeing this XBL thing - for HTML at least, not for SVG I guess - more like a way of extending CSS styling than of extending HTML. > The legacy problem is also much more insurmountable, you need to have your > content work in older UA's that understand text/html, which means you need > to hobble the specification to enable that to happen - or if you don't > hobble it, then you don't get any take-up by authors anyway. I don't know what part of the HTML-specification you think needs to be hobbled to get this to work. As far as I can see, you only need an extra binding property in CSS. Regards, Martijn ReplyForward Jim Ley to me More options Sep 6 (1 day ago) "Martijn Martijn" <martijn.martijn@gmail.com> > On Sun, 5 Sep 2004 22:58:16 +0100, Jim Ley <jim@jibbering.com> wrote: >> The problems with it being in HTML are somewhat different - mostly the >> credibility problem, and the legacy problem, the credibility one would be >> tough to solve, and I'm not sure if it's worthwhile anyway - there's no >> point continuing to extend HTML with more and more stuff when the only >> likely implementors of it already support XHTML and it's better defined >> extension mechanism. > > With the credibility problem, you mean that the W3C stated that XHTML > is the successor of HTML, and therefore it would be not credible for > the W3C to extend HTML any further? Nope, there's no problem there. The problem is embedding non HTML data into text/html documents, that's the problem all the XML evangelism that killed SGML on the web isn't going to go away. > I'm seeing this XBL thing - for HTML at least, not for SVG I guess - > more like a way of extending CSS styling than of extending HTML. It's a rendering language for sure, but it needs to render semantics, putting new non-document semantics in HTML isn't going to work. > I don't know what part of the HTML-specification you think needs to be > hobbled to get this to work. > As far as I can see, you only need an extra binding property in CSS. Why do you need that? that I don't understand, the binding in sXBL would be just as appropriate in HTML as it is in SVG (it'd need to be an SGML representation, but that's no problem) The problem isn't the binding, the problem is in the source mark-up that is to be transformed, that simply cannot be placed in HTML as it is defined today - text/html has too limited an extension mechanism. Introducing the ability to have arbitray SGML content withn text/html documents is not something that's trivial to do. More importantly though to stop it is the legacy aspect. Jim. ReplyForwardInvite Jim to Gmail Martijn to Jim More options Sep 6 (1 day ago) On Sun, 5 Sep 2004 23:58:26 +0100, Jim Ley <jim@jibbering.com> wrote: > Nope, there's no problem there. > > The problem is embedding non HTML data into text/html documents, that's the > problem all the XML evangelism that killed SGML on the web isn't going to go > away. Why is that a problem? I've done this a few times in Mozilla and it seems to work just fine. > > I'm seeing this XBL thing - for HTML at least, not for SVG I guess - > > more like a way of extending CSS styling than of extending HTML. > > It's a rendering language for sure, but it needs to render semantics, > putting new non-document semantics in HTML isn't going to work. I'm not sure what you mean here. CSS needs to render semantics, sure, but most of the time you need to add a lot of divs/spans to get the rendering in HTML as you would like. XBL seems to be the perfect tool to reduce these obsolete divs/spans. > > I don't know what part of the HTML-specification you think needs to be > > hobbled to get this to work. > > As far as I can see, you only need an extra binding property in CSS. > > Why do you need that? that I don't understand, the binding in sXBL would be > just as appropriate in HTML as it is in SVG (it'd need to be an SGML > representation, but that's no problem) > > The problem isn't the binding, the problem is in the source mark-up that is > to be transformed, that simply cannot be placed in HTML as it is defined > today - text/html has too limited an extension mechanism. Introducing the > ability to have arbitray SGML content withn text/html documents is not > something that's trivial to do. Personally, I don't really like the way you apply a binding in sXBL. I prefer the CSS way. I think it is more simple and elegant. But I can imagine that there needs to be a way to apply a binding in XML without using CSS (but that's just not something I have interest in). Why can't the source markup be placed in HTML? Again, it seems to work just fine in Mozilla. > More importantly though to stop it is the legacy aspect. I'm afraid I don't know what you mean with the legacy aspect. Also, excuse me if I'm going really off-topic, but since this sXBL specification is going to be the base for XBL 2.0 which would be going to be the way you could do this in XHTML (not in HTML apparently), I think it is not entirely off-topic. ReplyForward Jim Ley to me More options Sep 6 (1 day ago) "Martijn" <martijn.martijn@gmail.com> > On Sun, 5 Sep 2004 23:58:26 +0100, Jim Ley <jim@jibbering.com> wrote: >> Nope, there's no problem there. >> >> The problem is embedding non HTML data into text/html documents, that's >> the >> problem all the XML evangelism that killed SGML on the web isn't going to >> go >> away. > > Why is that a problem? I've done this a few times in Mozilla and it > seems to work just fine. In Mozilla, where it's supported, but it cannot degrade where it's not supported without hobbling the spec (all content in attributes etc to hide it from the old UA's) >> It's a rendering language for sure, but it needs to render semantics, >> putting new non-document semantics in HTML isn't going to work. > > I'm not sure what you mean here. CSS needs to render semantics, sure, > but most of the time you need to add a lot of divs/spans to get the > rendering in HTML as you would like. XBL seems to be the perfect tool > to reduce these obsolete divs/spans. but you need to replace them with something else <chicken> or something, now putting a chicken element into an html document is the problem, it's not going to work on legacy clients, and it'll get a lot of stick from "valid or bust" people. You seem to be completely ignoring degradeability, I find that very depressing, as it shows you don't actually mind too much about legacy UA's. Mark-up served up as text/html will be consumed by all text/html eating browsers from IE2 to Jaws on top of Opera - these browsers need to be able to still use the pages you're sending, if you're sending XBL mutated HTML with embedded XML, then it's not going to work - unless you hobble the XML fragments in such a way that they hide everything from the legacy UA - which would hobble it, all content in attributes is not elegant, and would make for complicated XBL. > Also, excuse me if I'm going really off-topic, but since this sXBL > specification is going to be the base for XBL 2.0 which would be going > to be the way you could do this in XHTML (not in HTML apparently), I > think it is not entirely off-topic. Oh it's not, but off-topic, and anyway this is an email correspondance, not going to mailing lists, so what does it matter, If I wasn't interested, I'd just ignore the post :-) Jim. ------------------------------------------------------------------------------------------------------------- My last reply to him is: On Mon, 6 Sep 2004 10:55:34 +0100, Jim Ley <jim@jibbering.com> wrote: > "Martijn" <martijn.martijn@gmail.com> > > On Sun, 5 Sep 2004 23:58:26 +0100, Jim Ley <jim@jibbering.com> wrote: > >> Nope, there's no problem there. > >> > >> The problem is embedding non HTML data into text/html documents, that's > >> the > >> problem all the XML evangelism that killed SGML on the web isn't going to > >> go > >> away. > > > > Why is that a problem? I've done this a few times in Mozilla and it > > seems to work just fine. > > In Mozilla, where it's supported, but it cannot degrade where it's not > supported without hobbling the spec (all content in attributes etc to hide > it from the old UA's) But I'm talking about an external url for the XBL binding file. So there would not be any non HTML data in the HTML file. The way of applying an XBL binding internally would simply not be supported for HTML browsers. > >> It's a rendering language for sure, but it needs to render semantics, > >> putting new non-document semantics in HTML isn't going to work. > > > > I'm not sure what you mean here. CSS needs to render semantics, sure, > > but most of the time you need to add a lot of divs/spans to get the > > rendering in HTML as you would like. XBL seems to be the perfect tool > > to reduce these obsolete divs/spans. > > but you need to replace them with something else <chicken> or something, > now putting a chicken element into an html document is the problem, it's not > going to work on legacy clients, and it'll get a lot of stick from "valid or > bust" people. Well, in Mozilla you don't need to invent <chicken> tags, you can just use <p class="chicken"> or something, and then apply an XBL binding with a CSS selector. It's a very easy and powerful way of applying an XBL binding. > You seem to be completely ignoring degradeability, I find that very > depressing, as it shows you don't actually mind too much about legacy UA's. > Mark-up served up as text/html will be consumed by all text/html eating > browsers from IE2 to Jaws on top of Opera - these browsers need to be able > to still use the pages you're sending, if you're sending XBL mutated HTML > with embedded XML, then it's not going to work - unless you hobble the XML > fragments in such a way that they hide everything from the legacy UA - which > would hobble it, all content in attributes is not elegant, and would make > for complicated XBL. Again, I would not be putting any XML content in the HTML file, but in an external XBL file, so it should degrade nicely for legacy UA's as I would only put style related tags in the XBL binding and not anything vital to the document itself. Regards, Martijn
Received on Tuesday, 7 September 2004 20:33:10 UTC