Hmm, seems like the example link is broken...

Nice!

... although the "degredation" of this example in non-XBL-capable browsers leaves plenty to be desired.

(link obviously WFM)

Try http://www.mozillazine.org/weblogs/hyatt/demo/tranquille.html

So... is Safari ever going to support XBL?

I'd say that it will, Kevin. Otherwise Dave wouldn't be talking about.

Colour me stupid, but when I "View Source" on the example, I still see the extraneous <span>s:

<div id="pageHeader">

<h1><span>css Zen Garden</span></h1>
<h2><span>The Beauty of <acronym title="Cascading Style Sheets">CSS</acronym> Design</span></h2>

</div>

Weren't we supposed to get rid of them?

Awww, come on Dave!!!

I only have Safari on my system and so I can't see the pretty pictures!

:P

Jacques, heh. I forgot to remove the spans from the source. It's fixed now.

Wincent, I implemented XBL in Mozilla originally. I'll still talk about it even if it never gets implemented in Safari or any other non-Mozilla browsers. :)

Hi Dave! Sorry to bother you about an unrelated bug here, but I suppose it's preferable to email. ;-)

I've either discovered a bug or a design decision related to the handling of onUnload when popup blocking is turned off. (Why do I *want* popups? I'm implementing a version of an open source PHP/Flash based chat script, and the ONLY way to track logouts is by using a quick popup which logs the user out and then closes itself when the user closes their chat window.)

A reduced test case is here:

http://flaneur.homeunix.com/safari/

If this is a design decision, why the different behaviour compared to Camino and IE? And does anyone have any better ideas on how to log someone out of a Flash/PHP-based, "serverless" chat scenario?

Keep up the great work!

Although this is intriguing, I have to wonder, why couldn't client-side XSLT be used for this? I understand that Safari has no support for client-side XSLT either at the moment -something that I hope will change- but it seems to me as though it could easily accomplish this same purpose in a way that's an established standard.

I'm not trying to bash XBL; it's an intriguing idea in its own right. But what makes it better for this task?

"Although this is intriguing, I have to wonder, why couldn't client-side XSLT be used for this?"

It can, and in my oppinion it is more powerfull. With XML/XSLT you can also get rid of the div/h1/..-tags in the XLM-source. You can also change the XSLT or the XML on the fly. You could even use XBL on top of it all.

I think client-side XML/XSLT will be used on many sites in the future (because M$ win IE supports it). It is a w3c standard so I would like it more than XBL. And will MS ever adopt XBL?

Today's random question...

How does one tell what version of the Konqueror engine that Safari is using?

David, you wrote: '...span tags serve no semantic purpose and are clearly only included in the source markup to provide an element that can be used as a style hook for CSS'.
OK, I agree on you, but... writing a valid 'HTML / CSS / WAI-AAA / Section 508' tableless page in few time is too much hard if I don't use a combination of background-images and hidden span tags. I love XBL, but in the 'Real World' I have to test my pages in all browsers and all platforms...

> "Although this is intriguing, I have to wonder,
> why couldn't client-side XSLT be used for this?"

Because XSLT is not dynamic. That is, if the document gets a new H1 via DOM manipulation, the transform will not be applied to it. Whereas with XBL, a new H1 created via the DOM will automatically get the XBL binding applied to it.

In other words, XSLT is great for static content, but when working with dynamic content you have to write all your scripts to work with the transformed page; this means that the content (the script) is dependant on the style (the XSL stylesheet). With XBL, the scripts work with the actual page DOM all along; the fact that XBL bindings get applied to some of the elements is a matter of sublime indifference to the content author.

Okay, I'll be the bastard who points it out:

<div id="pageHeader">
<h1>css Zen Garden</h1>
</div>

#pageHeader h1 {
background: transparent url(h1.gif) no-repeat top left;
margin-top: 10px;
width: 219px;
height: 87px;
float: left;
}

#pageHeader h1 {
-moz-binding: url(tranquille.xml#imageheader);
}

<bindings
xmlns="http://www.mozilla.org/xbl"
xmlns:html="http://www.w3.org/1999/xhtml">
<binding id="imageheader">
<content>
<html:span style="display: none">
<children/>
</html:span>
</content>
</binding>
</bindings>

vs:

<table border="0" cellpadding="0" cellspacing="0"><tr><td background="h1.gif" width="219" height="87">&nbsp;</td></tr></table>

;)

Or even, for that matter:

Obviously I understand why you'd use each, and in a LOT of instances the Fahrner image replacement technique as seen in the Zen Garden (and the expanded Hyatt XBL technique) can be considered overkill.

But I think there's something to be said for an H1 that's as visually engaging as an image, but accessible and modifiable as text. Doesn't it just *feel right* that way, forget the extra work involved?

That'll teach me not to preview. The second code example:

<img src="h1.gif" width="219" height="87" alt="CSS Zen Garden" border="0" />

As cool as XBL is, I am a little concerned by the character weight. Given a choice between a few semantically dead spans and using XBL, I'd tend to go with the spans (although it would depends on how many spans I needed, I suppose). This is in part because we've that the #1 factor in page loading and drawing performance is its raw size, not the way it's laid out. As more and more external files get piled on, the performance suffers even further.

(And before someone says "pretty soon bandwidth won't be an issue," people have been saying that for a long time now-- more than a decade at least. I don't buy it.)

I do find XBL a lot more interesting now that Hyatt's provided a good example (thanks Dave!) and will definitely look into it further. For me, XBL's ability to keep up with dynamic changes makes it more interesting than client-side XSLT. But as is often the case when I encounter a new XML-based language, I feel like it's a needlessly bloated and clumsy syntax, leading to file much bigger than they need to be. I don't blame XBL for this, I blame XML itself. In my view, XSLT is a perfect example of a good idea gone really confusing thanks to the demands of fitting it into XML.

Nevertheless, an example showing the creation of several anonymous boxes, with the content split up into two or three of them, with a scoped stylesheet, would be pretty awesome. It would help a lot of people better understand XBL, and pave the way for realistic assessments of its benefits and drawbacks. So how about it, Dave?

Yes, it's important to realize that just getting rid of one span is about the weakest XBL binding you could come up with. :)

However, remember that the same binding is reusable, so if your page did the header trick more than about 10 times, the XBL just paid for itself. In fact you start *saving* bandwidth past 10.

Looking at Zen Garden, it looks like it does this "hide my content" trick 6 times, so it's a tradeoff.

Once the binding is even remotely complex, however, XBL clearly saves bandwidth.

You also said, "I feel like it's a needlessly bloated and clumsy syntax."

I'd be curious to get specific criticisms of the syntax, i.e., what you find bloated/clumsy about it. I find it very intuitive, since the anonymous content tree is just actual markup, the same XML markup you'd have found in the source document.

It seems right to me that anonymous elements would be described using XHTML markup just as an author would have used had he/she placed the markup directly into the source document.

Solutions that try to invent a new language for describing anonymous layout objects without using markup seem far less intuitive to me than one that simply uses the same syntax that authors are already familiar with.

Hey Dave S. - your table example doesn't work. Yeah, it will display the image, but what if you switch to a stylesheet that uses the text and not the image there? Suddenly, your table example doesn't work anymore! The reason the page was designed the way it was (and the XBL examples too) was to allow that element to display either an image OR text, depending on the stylesheet, not just an image.

About CSS: Couldn't this be archieved with the text() selector (if it existed):
#pageHeader h2 text() { display:none; }

About bandwidth: isn't this issue about latency?

About XSLT: why is this actually always static? Can't this be dynamic, as XML Scheme is enforcing rules on DOM manipulation dynamically? I've seen it done on a wysiwyg xml/xslt editor (xopus).

Kevin - you're missing the point. I was getting at the fact that if you're going to design for flexibility, you go the Fahrner/XBL route, but if you don't need it, you can save a lot of bandwidth.

You're correct in your statement about why the page was designed as it was; but it's one example. Other sites might find either method beneficial, depending.

They're both absolutely valid ways of doing the same thing, one just allows for more flexibility, CSS-wise. As Dave H. has further clarified - it's an exercise in self-hatred to go that far for one or two elements, but if you're building a larger site that can be controlled by a CSS file, there's something to it.

On the bloating issue: I admit I may still be suffering from post-XSLT-trauma syndrome. But using XML for purposes other than document structuring and data exchange always leaves me a little skeptical. Compare the syntax of CSS to XSL:FO, for example.

Anyway, as for clumsiness, take your example:

<bindings
xmlns="http://www.mozilla.org/xbl"
xmlns:html="http://www.w3.org/1999/xhtml">
<binding id="imageheader">
<content>
<html:span style="display: none">
<children/>
</html:span>
</content>
</binding>
</bindings>

Compare to the proposed/hypothetical CSS-based alternatives:

#pageHeader h1::content {display: none;}

#pageHeader h1::inside {display: none;}

...or something similar. True, there's no public support for such things, but then almost the same could be said for XBL's current market coverage. And yeah, if you have to do the same thing to 20 pieces of a layout, even this XBL would save you something over the spans.

As you say, the issue at hand is likely to be close to the worst possible example of XBL's benefits, so I'm definitely not judging the technology based on this discussion. I need to come up with a complex idea or two and see if I can write my own working examples; I'd love to see you do the same, Dave, since you obviously know XBL better than just about anyone...

Doeke made my point: I'm pretty sure the original markup with SPANs is lazy. If you structure your CSS to replicate the structure of the HTML, you can pretty much avoid dead tag syndrome. It is a PITA: it's too bad CSS isn't set up to conform to document structure more naturally and compactly.

Yes, the current simple example of needing to hide your internal contents can be done using CSS3 (::inside). Similarly you could avoid multiple boxes for nested borders if everyone just supported -moz-border-colors.

It's definitely worth noticing some of these cases that XBL was used for in XUL and adding capabilities to CSS to avoid the "XBL overkill" for extremely common design patterns.

XBL really shines when you get into behavior as well as appearance, e.g., do you want to represent your blog entries as sticky notes that can be dragged around on a bulletin board?

http://lxr.mozilla.org/seamonkey/source/xpfe/global/resources/content/bindings/checkbox.xml

I think that's a pretty good example of what xbl can be used for. It's fairly simple, if somewhat boring, and it provides a JS interface for controlling the behavior of the checkbox. Anytime you see a checkbox in the Mozilla chrome, there's a element in the XUL that this binding is bound to. It definatly saves a huge amount of code duplication.

It's not a very complicated example, like you wanted, however.

I've use quite some xbl (and htc) for my site.
The round borders are made with xbl. I think it is a good example of avoiding tag pollution. The nice thing with xbl is, it even works with javascript turned off (contrary to htc).
The glowing menu links are also made with xbl. I must say I found it quite harder to make than with htc.
Also that moving thing with 'Gast' on it is made with xbl (I made quite some effort in not crashing Mozilla in the process ;) )

Oooh, XBL works without JavaScript? Bring it on! :D

-Walter
anti-javascript to the core

For every action there is an equal and opposite government program.