I’m not sure if everyone has been following the recent Microformat work being done at Mozilla, but it’s very cool – and exactly what the Microformat movement needs.
I was able to talk with Michael Kaply the night that he released Operator (Mozilla’s, sponsored, Microformat extension). This extension is part of the new Mozilla Labs initiative that was just started (It’s an attempt to sponsor and promote excellent-quality extensions, and other tools; a terrific idea).
We discussed Microformats in general – and both complained about the shoddy quality of most Microformat parsers. We agreed that in order for the Microformat initiative to move forward, a couple things had to be done:
- A standard for parsing Microformats had to be clearly defined.
- An excellent implementation of that standard needed to be implemented.
- And an important player needed to adopt the use of that tool.
The reason why I’m so excited, right now, is that this is actually happening. In Firefox 3, it’s looking likely that there’s going to be native handling of Microformats. This would include a defined API for handling Microformats (most likely on the extension level) on any given web page.
This is a huge step forward for the Microformat movement.
Thankfully, Michael has already started developing the solid Microformat Parser, with Andy Mitchell, that will go into Firefox 3. And since this is part of the overall Firefox 3 Content Handling Requirements, it’s a big priority for inclusion.
So, what could this content-handling API mean for you, the Firefox extension developer? It means that you would be able to write quick-and-dirty JavaScript to handle matched Microformats – and it’d be blazingly fast.
For example, here’s some pseudo-code (any final result will, most likely, be very very different):
Microformats.addHandler("hcard", function(card){
var img = document.createElement("img");
img.src = "hcard.gif";
img.title = card.data.name + "'s Personal Information";
card.container.appendChild( img );
});
When it becomes this easy to handle Microformats, it almost becomes harder to not support them in your extensions. I suspect that once this feature hits the big time, we’ll see a flood of Microformat-supporting extensions. And this is great for extension developers, the Microformat movement, and, most of all, end users everywhere.
This is a great time to be getting into Microformats.
Mike Beltzner (February 1, 2007 at 1:51 am)
Hey John,
Just to be clear, right now the PRD is in draft, we’re still evaluating and soliciting feedback, and so it shouldn’t be considered final. Even right now, they’re considered P2s, which means that should it come down to a ship-now-or-ship-later decision, we wouldn’t hold Firefox 3 for the microformat requirements.
I’m all hip with microformats, and think that getting a first-class parser and extensible framework in place could be great – I do share your excitement – but I don’t think it’s appropriate to promise what will or will not be in Firefox 3 at this juncture.
John Resig (February 1, 2007 at 2:03 am)
@Mike: Good call, I’ve re-worded the post to be less promising and more forward-looking. But yeah, I’m really excited by this.
Karl Dubost, W3C (February 1, 2007 at 2:21 am)
Mike,
is there a place where you collect the comments, feedback, etc?
First times are very important and lead to cool things, great improvements and painful ties sometimes. So indeed when a browser is proposing new UI widgets directly related to the *semantics* of content, we have to be very careful.
At first, I say “cool, very cool!”. Then, taking a step back, I think about what about the documents which have been created for the last 15 years before microformats effort existed. These documents contain class names which are probably and most certainly very similar to some values defined by microformats community. So there will be documents where a UI widget will be activated but not with the intended meaning. Basically it is changing the contract between the author and the reader by hijacking the intended semantics.
There /was/ a solution for this profile attribute URIs with the URI of the used profile. Problem ahead it seems that some developers want to suppress this attribute in HTML document.
I think there is a possible win-win here. The Mozilla UI widget could be activated only when the right URI is really here. (a bit like the doctype switching). It will encourage people to use the right URIs, because the effect would be immediate, it will not hijack documents previously written. Everyone win.
Laurentj (February 1, 2007 at 4:12 am)
For what i’m understanding about your pseudo code example : do you reinvent the wheel ? You can define such thing with XBL, right ?
Dao (February 1, 2007 at 5:00 am)
“do you reinvent the wheel ? You can define such thing with XBL, right ?”
Not really. One element can only have one binding. Bindings can extend each other, but they can’t co-exist on the same level.
Btw, the pseudo code wouldn’t work atm, even if there was such an API. You would have to create the img with the container’s document or use adoptNode.
fdafd (June 5, 2007 at 12:49 pm)
kkk
Sandra-nl (September 6, 2007 at 1:36 am)
smart discipline satellite manufacturing inc easton maryland newspaper photographs at lasalle university pod trailers for rent in valdosta ga russel harrington state of fate concert french lick professional development arkansas state university puffy tits tgp