Burning Chrome

Extensible XUL Applications and ID Attributes

There's one big problem with XUL applications which expect overlays: the application must define a way for overlay developers to identify their content elements. The id attribute of XUL elements is particularly troublesome. After all, anyone could have this:

<vbox id="contentBox"/>

So if you have that in your overlay, and I have a similar element in my overlay:

<textbox id="contentBox"/>

Immediately one of us has a problem. The application should have defined for us a way to avoid ID collisions like this. At the very least, it breaks the DOM's getElementById method.

A few days ago, I blogged about a JavaScript scope registry. I thought to myself, "if we have a unique scope id for the scripts, I can reuse that as an attribute in the overlay."

So instead of relying on a single ID attribute to identify an element, I can rely on a two-part key: a scopeid attribute on an ancestor element, and a localid attribute on the target node.

Thus, I present a simple function for getting a node by this combination key:

document.getElementByAttrKey = function byAttrKey(aScopeId, aLocalId) {
  var scopeElements = document.getElementsByAttribute("scopeid", aScopeId);
  if (!scopeElements)
    return null;
  for (var ptr = 0; ptr < scopeElements.length; ptr++) {
    var list = scopeElements[ptr].getElementsByAttribute("localid", aLocalId);
    if (!list)
      continue;
    return list[0];
  }
  return null;
}

It is probably more efficient to cache these nodes in a registry, though.

UPDATE: I love it when someone comes up with a cleaner solution than me. Thank you, Mr. Karel. Still, the premise (that id alone is not enough) holds.

Posted by WeirdAl at May 14, 2005 11:41 PM