Re: sXBL draft comments

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