This week marks the release of a few new incarnations of the CodeBurner reference tool: an OS X desktop widget, an Opera widget, and a standalone AIR app. Of course, you can still grab the original versions of the tool, CodeBurner for Firefox or CodeBurner for Firebug. You can now access HTML and CSS reference information no matter where you do your web development!
To highlight this release, I thought I’d give you the lowdown on a key technology I used in the development of these extensions: HTML.
Yep, plain old HTML. Used wisely, it can be the secret weapon that makes your Firefox extension stand out from the crowd.
This article assumes knowledge of the basics of developing Firefox extensions. If you’re new to the game, you can get up to speed with my free Build Your Own Firefox Extensions PDF ebook.
One of the great aspects of XUL components is that their appearance is largely out of our hands. This makes for interfaces that are consistent and accessible; they’ll always look like the rest of the browser interface, whether viewed with the default skin, a custom skin, or platform accessibility tweaks like large fonts.
Firebug is a prime example of an extension requiring HTML for parts of its interface, because XUL simply lacks the elements for the job. Let’s take a look at Firebug’s HTML panel, which is a representation of the DOM being inspected. Think about how you’d build it in XUL:
Figure 1. The HTML panel in Firebug
Well, it’s a trick question. It’s impossible to build it in XUL because XUL lacks any elements that can be arranged to create a tree-like structure with syntax highlighting. The nearest option is the
tree element, which can be used to create a similar structure, but only within the constraints of columns and rows. Here’s that element in action in the DOM Inspector:
Figure 2. The document: DOM nodes panel in the DOM Inspector
Here are some other examples of when I think it’s appropriate to use HTML in developing a Firefox extension:
For creating “about” pages or similar dialogs that only contain rich text, rather than actual interface components.
When the offsetWidth or offsetHeight of an element needs to be measured (properties that are unavailable to XUL elements), you could create a temporary HTML element inside the XUL element, and measure that instead.
When elements need to be positioned absolutely in the interface (absolute positioning is unsupported for XUL elements).
If more styling flexibility is needed, such as rounded corners or background images. The XUL
textbox element, for example, is particularly resistant to styling, so using an HTML
input may be the only way to achieve the desired results.
If you find yourself wanting to use HTML simply because of its additional styling potential, you should first consider whether you really need the styling, or whether it’s just eye-candy, or could be accomplished in some other way.
Absolute positioning in particular should be used with extreme care, because of the limits it places on the flexibility of an interface. In a great many use cases, there are other ways to achieve the end result: the
stack element, for example (within which elements can be positioned absolutely), or simply leaving elements in their flowed positions.
A good example of where an interface genuinely needs the increased styling potential is the CodeBurner for Firefox in Version 1.5. This proved impossible to implement with an XUL
textbox, so using HTML was the only option.
icon to delete the contents of the search box; this was added to
Figure 3. The search box in CodeBurner for Firefox version 1.5
I’ve shown you some examples of when it can be appropriate to use HTML, but that decision will always be a judgment call that needs to be made on a case-by-case basis. That said, let’s move on the nitty-gritty of how you actually implement it.