The Grumpy Editor encounters Firebug

Those who have been paying close attention may have noticed a number of changes to the LWN site over the last few weeks. Most of those changes are not visible; our quaint early-90's table-oriented HTML is slowly giving away to a more contemporary design which makes use of the features of cascading style sheets. This sort of work involves a lot of change-and-reload cycles in an effort to figure out why something is not rendering as your editor intended. CSS is a powerful but sometimes obscure technology. One tool your editor wishes he had stumbled across earlier is Firebug, a Firefox extension designed to help with just this sort of work.

Firebug can be thought of as a sort of interactive debugger for HTML and CSS. It is not an authoring tool; it is assumed that content is being created by other means. It is, instead, a way of figuring out why things look the way they do and how to make them come out better.

To that end, Firebug includes an interactive HTML inspector. It's a sort of "view source" window, but done in a much more useful way. By using the "inspect element" option in the Firefox content menu, a web developer can find the HTML for a specific item in a hurry. The display of the document tree is hierarchical, making it easy to see how elements relate to each other. Editing of element attributes is a matter of clicking on them and entering new values; numeric attributes can also be adjusted up and down with the arrow keys. As a result, it is easy to make quick HTML changes and immediately see what the results are.

It is also possible to edit the text contained within the elements, but the interface is somewhat awkward. But this is not a functionality which really matters anyway; Firebug is about markup and rendering, not the content itself.

Positioning the mouse over an element in the HTML inspector highlights the corresponding part of the displayed document. This feature can be useful in correlating the two windows, but it also leads to extensive flashing and blinking as the mouse moves through the window. Something a little less distracting and gaudy would be more to your editor's taste.

The HTML inspector also features a pane which shows the stylesheet entries relevant to the element of interest. The entire cascade is shown, with overridden attributes marked. As a result, it is easy to see where all of the rendering parameters for an element are coming from. Anybody who has worked with CSS for a while knows that the combination of selection rules and cascading can lead to mysterious effects at times. The CSS display removes the mystery, making the source of strange behavior obvious. Once again, CSS parameters can be tweaked on the fly, making it easy to adjust attributes until things fit together just right. One shortcoming here is that adding new attributes does not appear to work in any useful way; it seems that attempts have been made to support this functionality, but your editor was unable to make it work.

There is a separate "layout" display which shows how the various parts of the CSS box model come together in the rendering of a specific element. The values of the margin, border, and padding attributes can all be adjusted on the fly, and a set of rules shows how each plays into the final positioning of the element on the page. Your editor, who has often used the old trick of turning on borders to see how an element has been placed, likes this display better: it separates out the effect of the various attributes and does not, in itself, change the rendering. So questions like "where is that extra white space coming from?" are easily answered. One complaint here is that changing the border parameters is pointless if border style is none (which is the default); it would be nice to be able to play with border styles in the same place.

Finally, there is a mode for playing with stylesheets as a whole. In this mode, the entire stylesheet is available and attributes can be tweaked to see what their effect is on the page as a whole. There is a toggle for every attribute allowing it to be turned off. New attributes can be added - that feature seems to work on this screen. What is missing is any way to save the results of changes.

For those who are concerned with page load times, there is a mode which shows, in bar-graph form, just how long each component of the page took to load. It is possible, in each case, to look at the request and response headers associated with that loading. This feature is probably not one which will be heavily used by most web developers, but it can be useful if a specific page is loading slowly for any reason.

LWN is not a site which makes much use of Javascript, so your editor has not played with the Javascript-specific features of Firebug. Those features look impressive, though. There is a complete interactive debugger, a profiler, a DOM inspector, and more. The HTML inspector, unlike the Firefox "view source" feature, shows what the document's HTML looks like after it has been mangled by Javascript code. All told, it looks like a nice package for those doing that kind of work.

"View source" has always been a fundamental part of how web pages are designed. So it is not surprising that Firebug supports this mode of operation very well. But trying to figure out how a CSS designer got a specific effect from the standard "view source" screens is, with modern pages, often a painful experience. Firebug takes a lot of the pain away by making it easy to look at specific elements and the CSS declarations which affect them. In general, Firebug is a tool which gives a highly useful view into just how the browser is rendering a document. It has become an important part of your editor's toolbox.

---

(Log in to post comments)