techno.blog("Dion")

First came IE behaviours (HTC), which allowed you to bind script and binary behaviour to tags via CSS, for IE only of course. Mozilla decided that it needed a language to tie behaviour to XUL widgets and XML elements in general, and they created the first version of XBL.

I met Jonas Sicking of Mozilla for the first time recently, and found out that he is working on XBL 2.0, a spec that was edited by none other than Ian Hickson. That man is a machine!

XBL 2.0 cleans up the original work from Mozilla, and gives you a really nice way to add scripting behaviour to tags.

The example application below gives you a good view of how you could implement ‘an inaccessible implementation of the proposed HTML5 details disclosure element: it opens and closes when clicked, and reflects its current state in the element’s “open” attribute.’

<xbl xmlns="http://www.w3.org/ns/xbl">
 <binding element="details">
  <template>
   <div>
    <div><content includes="legend:first-child">Details...</content></div>
    <div state="hidden" id="container"><content/></div>
   </div>
  </template>
  <handlers>
   <handler event="click" phase="default-action">
    this.open = !this.open;
   </handler>
   <handler event="DOMAttrModified" attr-name="open" attr-change="addition" phase="target">
    this.shadowTree.getElementById('container').setAttribute('state', 'visible');
   </handler>
   <handler event="DOMAttrModified" attr-name="open" attr-change="removal" phase="target">
    this.shadowTree.getElementById('container').setAttribute('state', 'hidden');
   </handler>
  </handlers>
  <implementation>
   ({
     get open() { return this.boundElement.hasAttribute('open'); },
     set open(val) {
       if (val)
         this.boundElement.setAttribute('open', 'open');
       else
         this.boundElement.removeAttribute('open');
       return this.open;
     },
   })
  </implementation>
  <resources>
   <style>
    #container[state=hidden] { display: none; }
   </style>
  </resources>
 </binding>
</xbl>

What I find interesting is how you bind this behaviour via CSS a la IE behaviours:

details { binding: url(details.xml#details); }

You can also do so programatically:

$$('details').each(function(el) {
  el.addBinding("details.xml#details");
});

Once you have this behaviour setup, you are fully embedded in the DOM. You see ‘details’ as a true node, rather than a processing hack that would put in divs and spans in their place. You will notice the shadowTree that let’s you have a full DOM behind the scenes.

Imagine if this spec was implemented by a series of browsers. Is there a way to have a shim that could take XBL 2 and map it to IE behaviours? That is a question for Dean Edwards ;)

In general, this seems like a great extension point to let us take generic behaviour and reuse it. It could be a great way to add functionality to older browsers too, just as we were able to add alpha transparency to IE via binary behaviours.

Do you see value?

Other posts on Web archelogy:

• Java Pluglet API

Even since Ben and I looked at the notes for the first version of Mozilla that supported XMLHttpRequest, which suddenly took the technology from “Some ActiveX for IE” to “Ajax”, I have been interested in hidden technologies that maybe never made it. In those notes for that release we saw no mention of XMLHttpRelease, but technology such as FIXptr was prominently mentioned.

Also, something interesting about Ajax is exactly the fact that the technology was available since 1997, but didn’t make it big until many more Dilbert calendars later.

This points to the fact that there may be some hidden gems in the past that could also be resurrected in the now! As I look back in time, I thought I would talk about any that interest me in some way. Hence, the Web Archeology set of postings. If there is a technology that I am missing, please let me know!

Today I am going to talk about the Java Pluglet API. This technology is part of the Blackwood project at Mozilla, where it was created in 1999 by Igor Kushnirskiy & Akhil Arora.

Let’s walk back to 1999 for a second. Imagine working on Mozilla in a world where you had to futz with a lot of XPCOM and C++ to build things. XUL came about a way to reach out via more Web-y technology to get work done (XML, JavaScript, CSS, etc). In 1999, Java was a sexy language, and everyone was getting ready for fantastic server side Java with great technology like EJB ;)

What if the Java developers could get in on the browser action and develop rich plugins for Mozilla? This is where the Java Pluglet API comes in. It allows you to do just that, mimicking the C++ side of the house:

It was a conscious design decision to have the Pluglet API resemble its C++ counterpart as much as possible, while being able to reflect all of its functionality to Java, so that Plug-in writers will not have to learn yet another API. This concern, in our opinion, outweighed other alternatives which offered a cleaner, more Java-like look. Support for other Plug-in APIs can be easily added by contributing adaptors.

How you register the pluglet is via mime types. You could create application/wicked-cool and when that comes back from the server, Mozilla will say “hmm, I don’t understand this mime type, Pluglet Engine do you?”

At a high level the idea of writing extensions in Java makes total sense to me. It is obviously cross platform, but still low level enough, with a huge library set to get a lot done.

Isn’t this dead?

Probably? Ed Burns did step up to the plate though and reenergized the project recently. As part of the resurrection you can now interface directly between the Java side and JavaScript itself.

If you squint a little, you see an interesting plugin path for the browser. I often say that I would love for Gears to be made using Java instead of C++!