Comments on: XBL 2.0 Primer

By: Valery Silaev

Valery Silaev — Fri, 27 Jul 2007 13:33:36 +0000

If you search W3C archives, you may find out that HTC (Hyper-Text Components) from Microsoft was evaluated for some time as standard. Now it’s clear that HTC proposal is abandoned (mostly by MS itself that put no effort into this project for more then 5 years).

XBL (or HTC) is in fact truly necessary, see comments above. However, I think it would anything but practical as final result:
1. Would IE ever support this? I bet the answer is “no”.
2. How it is aligned with other standards for W3C Web Applications initiative? Most importantly, is there any connection with xForms? It looks like W3C runs several competitive standards at the very same time…

By: Richard Kimber

Richard Kimber — Thu, 26 Jul 2007 09:30:13 +0000

This sounds great. I love the handlers.

By: Jon Davis

Jon Davis — Wed, 25 Jul 2007 18:43:30 +0000

Cool! Being an ASP.NET developer (don’t shoot me), it reminds me of how we already do server-side XML templating and behavioral markup, but here it’s client-side and declarative of both the HTML DOM and Javascript behavior. Very nice. I would love to see this supported in web browsers.

By: malte

malte — Wed, 25 Jul 2007 17:34:30 +0000

c:
XUL uses XBL (1.0 I think) for many, many widgets (text boxes, autocomplete, toolbar buttons, dialogs… nearly everything). Gecko even uses XBL for html elements.

jaimz:
It’s like unobstrusive JavaScript… but with all the code for detecting the nodes to apply the code to moved from the script to the browser(‘s css engine).

By: ix

ix — Wed, 25 Jul 2007 17:18:31 +0000

if you read it, you’d see the point is to further separate content from presentation.

having just read the spec, id summarize XBL as an XSLT which instead of transforming to another XML document, transforms to an in-memory DOM tree, replete with event bindings etc. script tags are gone in favor of elements named like handler, binding, etc.

but.. you can already serve your content as JSON or XML, and transform it with your dom-generation lib of choice in JS. or serve semantically-uncluttered/minimal/crawler-friendly HTML and add your app goodness in the client and 99 times out of 100 it will be more readable than this ‘custom subset of DOM API hacked into custom XML element attributes aned node names’ since your lib was made by a hacker who values concise code, rather than ‘everything needs to be written in XML’.

im sure some hardcore XML fiend out there will find this cool though..if those exist anymore

By: Jaimz

Jaimz — Wed, 25 Jul 2007 17:06:15 +0000

why is xbl needed, i mean really. whats the point

By: c

Wed, 25 Jul 2007 16:22:18 +0000

‘you will one day be able to’ – does this mean Opera, WebKitSafariAppleKDE, and IE have ligned up to support this?

it appears to be another way of doing the same thing with the side effect bloat/complicate browser implementations who choose to support it and raise barriers of entry into the space even more. all the bullet points above could just as well apply to HTML5/DOM..

i guess XUL is built in XBL or something? a nice diagram would be useful to show where this fits into place