You might have heard from Elias Torres that we have RDFa working in Operator. You might also be wondering where that version is.

Basically I’ve been working very hard to finalize the APIs so that I can get things ready for Firefox 3. You can take a look at them here. The ironic part is that I’ve actually gone back to the way I wrote Operator the first time in terms of how microformats and actions are added to Operator. I’ll be documenting this soon. And if you wrote to any of my other APIs, I’ll work with you to move things to the new model.

So what do you have to look forward to in Operator 0.8a?

• RDFa support
• Unified action architecture (actions on the toolbar aren’t specific to microformats)
• Support for non HTML documents
• A final architecture for actions and microformats so people can start coding to it
• Debug mode displays X2V output
• Export All available in “Microformats mode”
• Lots of bug fixes

Stay tuned. Just some fine tuning and we’re good to go.

So let’s talk about what Firefox 3 will hopefully offer for developers. The goal is that extension authors will have an API to access microformatted data directly without worrying about parsing. In addition, there will be a model for adding additional microformats, as well as adding semantic actions (more about that in a minute). Here’s what the API looks like right now.

Any microformat can be instantiated from a DOM Node:

var hcard = new hCard(DOMNode);

Once the microformat has been instantiated, members can be accessed directly, like hcard.fn. If the property is defined as an array in the microformat specification, it is an array in the newly created object. A pointer to the original DOM node is also stored in this object if you want to do anything to the microformat node on the glass.

Microformat objects can be queried from a document:

var hCards = Microformats.get(document, "hCard");

I need a better name for this one I think. Given a document and a microformat type, this API returns an array of objects that represent each microformat in the document. I’m not sure if this should go through all the child frames and return every microformat in every sub document. I have to think about that.

If you have DOM Nodes, you might need some information about them. The scenario here is what if you have a DOM Node and you don’t know if it is a microformat or not? What APIs could help you?

Microformats.isMicroformat(DOMNode)

This function tells you if the specific DOM Node you passed in is a microformat. It returns a boolean.

Microformats.getParentMicroformatNode(DOMNode)

This function gets the first microformat that is a parent of this node. If you pass in a microformat, it still gets the parent. This is important for finding nested microformats.

Microformats.getMicroformatNamesFromNode(DOMNode)

This function returns an array of the microformat types that this node represent.

So here's how you might use those three functions, for instance when a context menu is displayed on a given node:

  if (Microformat.isMicroformatNode(node)) {
    mfNode = node;
  } else {
    mfNode = Microformats.getParentMicroformatNode(node);
  }
  while (mfNode) {
    var mfNames = Microformats.getMicroformatNamesFromNode(mfNode);
    /* enumerate through names and do something */
    mfNode = Microformats.getParentMicroformatNode(mfNode);
  }

I mentioned semantic actions earlier. I'm still working on how I can create an action model that is easily extensible. In an earlier post, I suggested that actions be implemented like this:

semanticActions.actions.youtube_search_tags = {
  description: "Find videos on YouTube",
  icon: "http://youtube.com/favicon.ico",
  scope: {
    semantic: {
      "tag" : "tag"
    }
  },
  doAction: function(semanticObject, semanticObjectType) {
    if (semanticObject.tag) {
      return("http://youtube.com/results?search_query=" + encodeURIComponent(semanticObject.tag));
    }
  }
};

I'm now trying to decide if I should use a function method, something like:

semanticActions.addAction("youtube_search_tags", youtube_object);

There will be much more on that later.

Anyway, I'm primarily looking for feedback from people. Are these APIs sufficient? Did I miss something obvious? Thanks for the input.

I’m now the official owner of microformats support in Firefox 3. Here is the preliminary design document.

At this point, we’ll primarily be focusing on making microformats available to extension developers, with very little UI. The primary motivator behind this is that I don’t think anyone has come up with a good user interface for microformats. I want to take some time to bring up some different UI paradigms and have some general discussion on these ideas just to see what people think. We’re actually trying to have a UI discussion on the labs forums, but we’re not getting much input so I thought I would try here.

So far there have been multiple extensions with multiple ways to interact with microformats:

• Operator (toolbar, status bar button, toolbar button, right click on microformats)
• WebCards (in page “cards” – notifcation ribbon on the bottom of the screen, right click on microformats)
• Tails Export (sidebar)
• Tails (icon on the status bar – window presenting content of the microformats)

Some of the other ideas that have been floated have been using the Firefox notification bar to inform about microformats, in page highlighting of microformats, notifications on the URL bar similar to RSS feeds and changing the mouse pointer. You can see some of these ideas at Alex Faaborg’s blog.

The primary concern we have in creating a microformats UI is that it’s not necessarily something that is going to be accessed a lot (like a back button for instance, or bookmarks), so how much screen real estate should it take?

With Operator, my original plan was to allow for many different UI paradigms, and I’m continuing that in the next release by allowing individual buttons for specific microformats (a Contacts toolbar button for instance). So now I’m putting the question to you:

What UI paradigm for microformats do you prefer? Is there a paradigm you wish was in Operator (like a sidebar for instance)? What do you think microformats should look like in Firefox 3?

Feel free to come up with any wild idea you want.

In my next post, I’ll be talking about what we should do for developers.

Since my original post on setting up a Firefox update server, I realized that some of my information was not correct. This post is to correct that information.

My mistake stemmed from the fact that the format of the Firefox update URL changed between Firefox 1.5 and Firefox 2.

Here’s the URL for Firefox 1.5:

https://aus2.mozilla.org/update/1/%PRODUCT%/%VERSION%/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/%CHANNEL%/update.xml

Here’s the URL for Firefox 2:

https://aus2.mozilla.org/update/2/%PRODUCT%/%VERSION%/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/%CHANNEL%/%OS_VERSION%/update.xml

You’ll notice two differences:

1. The number after update was changed from 1 to 2 (this identifies which URL format to use)
2. %OS_VERSION% was added to the URL

The important change here is the addition of OS_VERSION. Whereas before, the update URL provided information only about the browser, with OS_VERSION, the URL now contains information that changes based on the machine on which the browser is running. This makes providing updates a little trickier (although not that much).

(Incidentally, the reason that OS_VERSION was added was so that the update server could detect Windows98 and Windows95 and not send them updates that didn’t work on those machines.)

Let’s present a modified .htaccess file that handles this situation. I’m going to assume that in your enterprise deployment, you don’t care about OS_VERSION, so we are just going to ignore it. In our original .htaccess file, we simply checked for the existence of update.xml in a path that corresponded to the URL. Because of the addition of OS_VERSION, that won’t work anymore, since we would have to duplicate the update.xml file based on every possible OS_VERSION that could be sent to us. So we need to create a .htaccess file that ignores OS_VERSION. The way we do this, is simply redirect the URL to a new URL that doesn’t contain OS_VERSION, and then use our old method of checking for the existence of a file.

RewriteEngine on

RewriteRule ^(.*)/release/(.*)/update.xml /$1/release/update.xml [R]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*) noupdate.xml

What this says is if the URL contains something between release and update.xml (OS_VERSION), remap it to remove the OS_VERSION. Then send it to the server again.

I’ll leave updating the PHP script as an exercise for the reader.

I hope this clears up any issues with my original post.