By James Edwards

The CodeBurner Family Welcomes Three New Babies!

By James Edwards


I’m very pleased to announce the launch of CodeBurner Version 1.5. More than an update, it’s three (count ’em, three!) new builds as well — extending the CodeBurner family to include an Opera widget, a Mac OS X Dashboard widget, and a standalone app built on the Adobe AIR platform. You can download them here:

Perhaps the most significant new feature is the addition of a new CSS view. It works in tandem with the DOM view, to provide a complete breakdown of all the style sheets used on the DOM view page. You can drill into each style sheet and obtain information about its rules, properties, and selectors. Furthermore, when you perform a “DOM selection search,” the results now include information about properties and selectors as well.

Adding this functionality to the Firefox and Firebug versions was relatively straightforward, if quite involved. Data made available by the DOM utilities class provides information about the CSS DOM, and it’s what powers the CSS inspection in DOM Inspector and Firebug.

However, no such functionality exists outside of Firefox — extending this capability to other versions meant writing a whole new utilities class, in order to analyze and extract the necessary information from a document’s style sheets collection! No small feat, I can tell you. It provides functionality, such as the ability to return a list of properties that apply to an arbitrary element, which the new versions use for their selection search.

CodeBurner now includes CSS selectors and at-rules in all its searches, in addition to the CSS properties, HTML elements, and attributes information it had before. For all the code output and code examples, you now have full syntax highlighting (with user-configurable colors in the Firefox version). As you’d expect, there’s also a range of smaller bug fixes and stability enhancements, including a new on-demand loading technique for the Firefox and Firebug versions; this latter feature helps reduce the extension’s memory footprint when it’s inactive.

In order to keep the version numbers uniform, all the new builds come straight in at Version 1.5; but there’s no need to worry — you’re still up to speed! The version numbers simply reflect the fact that all these new builds have a comparable feature set to the primary Firefox and Firebug versions, both of which have naturally reached 1.5.

So there you have it — more choice than ever, giving you the HTML and CSS reference data you need in whatever format is most convenient for you, be it a browser-based development tool, a browser widget, dashboard widget, or a standalone desktop application.

And if you’re yet to be impressed, you should see what’s coming in Version 2! (Sorry, you’re just going to have to wait.)


  • Doesn’t seem to do anything at all (Opera 10.00/Windows XP build 1750). I get another app on the task bar (“CodeBurner for Opera”), nothing more.

    Am I missing something?

  • Yes, I did miss something. You have to enable JavaScript globally or it won’t work.

  • Jenn

    Nice, thanks! Although at first I thought they were reference guide for opera, mac and adobe, not an app. lol. Oh well. Thanks again =)

  • search doesn’t work for me on the FF add-on. Does with the AIR app though.

  • Luki_be

    Doesn’t work for me on Opera 10.00/Windows XP build 1750. I get a time out, no matter what url i type. Javascript enabled.

  • Anonymous

    testing out the air app – pretty impressive so far.

  • @AutisticCuckoo – I didn’t know that. I guess it must be case for all Opera widgets then, and I’d probably want to consider that an Opera bug. Given that widgets have a different security scope, they really should have sandboxed configuration as well.

    @bbolte – what version/platform are you using? What exactly happens when you try to search? Are there any errors reported in the JS console?

    @Luki_be – same questions really – which platform/version are you using, and are there any errors reported in the error console?

  • I guess it must be case for all Opera widgets then, and I’d probably want to consider that an Opera bug.

    I agree. There should be some equivalent to ‘site preferences’ for widgets. Perhaps there is, but I haven’t found it. :)

    I also get the same ‘Request timeout’ problem as Luki_be. (Opera 10.00/Windows XP build 1750.)

  • Hmm .. could you have a look in the JS console when trying to load a URL – do you get a “Security violation” error?

  • Yep. I get a security violation error message in the console.

  • dammit, I thought that problem was fixed long ago!

    okay cheers, I’ll have to investigate .. expect a patch release fairly soon.

  • Shaun Hare

    The MACOSX dashboard widget is fantastic (Nice work James )
    One question is it possible to make it slightly higher or is there a way to adjust the height yourself

    The DOM window is quite limiting at that height.

  • @brothercake – WinXP & FF 3.5.3

    When I search, either from the status bar or from the window, I get nothing. The search field on the left is blank. Also, when I type into the “Search For” field in the window, it duplicates all my characters.

    The only errors in the console are:

    “No chrome package registered for chrome://sitepointreference/content/dictionaries/elements.js”

    “Error: uncaught exception: Error opening input stream (invalid filename?)”

    “Warning: The ‘charCode’ property of a keyup event should not be used. The value is meaningless.
    Source File: chrome://browser/content/browser.xul
    Line: 0”

  • @brothercake, excuse me, I mean the search field/return area on the right is blank (said left above).

  • tgoyer

    I get the same error as bbolte. Running the Firefox plugin on XP SP2 and Firefox browser v.3.5.3.

  • @brothercake – exact same results with FF 3.0.14 on Kubuntu 8.10. same double typing in search field. Same errors in console. Nothing showing in right text results box.

  • Okay, thanks for all the info – I’ll look into this now and get a patch at as soon as I can.

  • Okay – the Firefox issues are fixed now (I’m still working on the Opera issue).

    Please visit to install the 1.5.1 update that has that fix.

    For interest, the issue was related to the new script-loading technique I implemented. It’s designed so that if you have both the Firefox and Firebug versions installed, they can share reference data between them to reduce the overall memory use. Or, if you have only one version installed but you don’t actually use it in a given browser session, it doesn’t have to load the reference data at all, thereby reducing the nominal memory footprint. The problem was just a typo in the Firefox version, that was trying to load data using the Firebug version’s chrome URI. It wasn’t picked up in beta testing because we all have both versions installed!

    Thanks very much for letting me know, and I hope you enjoy using the newly-fixed build.

    I hope to have the Opera issue fixed in the next day or two.

  • @Shaun Hare – no unfortunately the Dashboard version isn’t resizeable at the moment. Since the widget framework provides no mechanism for creating a window chrome, I had to build one manually using a bunch of overlaid images, and making it resizeable was just too complex to implement in the time available for development.

    But I’ve taken what you said on board, and I’ll look into making the next update resizeable; because I agree, the fixed size can be somewhat limiting.

  • @brothercake – that fixed it on my WinXP computer. I’ll give it a go later tonight on my Kubuntu box. Thanks!

  • littrean

    Thanks, this is great guys.

    I’m using the Mac Widget and I strongly agree, resizing would be nice. I’ve also noticed that any other Widget I’ve used didn’t allow resizing so I just thought that applied to everything on the dashboard.

  • Well in a way it does – the widget mechanism provides no means for resizing widgets. But it should be possible to implement it anyway, it just means rolling it manually with JavaScript.

    Watch this space :)

  • Okay, the Opera issues are now fixed as well. Please visit to grab the 1.5.1 update with that fix.

    It turned out that the network security policy changed between Opera 9 and 10 (I’d been testing in 9.64), so all the fix required was a few additional entries in the configuration XML file, to tell it that network requests are allowed :)

  • It’s working fine now. Good job, brothercake!

  • Shaun hare

    @brothercake – thanks for the response

  • Luki_be

    @brothercake: opera works fine now. Congratz.

    What really really would complete it is the ability to change Css on the fly …

  • Isn’t that more of a Firebug thing? CodeBurner is more of a reference tool than a debugging tool.

Get the latest in Front-end, once a week, for free.