blogZero

Joe Hewitt may be a lesser known member of the original three Firefox cast, but among DOM and JavaScript developers, his work is legendary. In a later Power Tools installment, I will cover in more detail the DOM Inspector, for which he is perhaps better known. At least until recently. This article focuses on FireBug, which Joe has been working on continuously of late (among other endeavors) and what he ultimately considers to be a DOM Inspector replacement.

The latest version of FireBug was released September 12th, 2008.

What in the hell is a FireBug?

I won't get into entomology—which ironically in Greek means "that which is cut in pieces"—although there really is such a thing as a firebug. The extension, on the other hand, is designed to make the Web developer's job a whole lot more productive. With it you can inspect and debug your markup, stylesheets, JavaScript, and even keep an eye on asynchronous XHR object calls back to your server.

Unlike the DOM Inspector, FireBug normally runs in a horizontal console (although you can open it in a separate browser window) underneath the document's rendered view. A statusbar icon indicates if there are any problems with the current page, which can indicate any number of conditions including errors, warnings and results from:

• JavaScript
• CSS
• XML
• XMLHttpRequest (aka XHR or Ajax)
• Chrome

and even problems encountered from remote domains—which can be the source of massive numbers of errors (I'll leave it to Joe to name names). Thankfully you can suppress these messages, or disable FireBug entirely for certain domains, through the options menu.

Almost every object in the FireBug interface is actually a hyperlink. Elements in the source view can be expanded or collapsed and your current XPath is displayed as you explore the document structure. Like the browser itself, views are toggled through a tabbed interface, which include Console, HTML, CSS, Script, DOM, and Net. Each tab has one or more sub-functions associated with that feature.

By using FireBug, you will quickly learn just how much is going on behind the scenes of even the simplest Web page.

Power Tools

• console.log()

Forget about using alert() to test or debug your scripts. By adding console object logging to your code you can pinpoint exactly what is going on, and even restrict messages according to different levels of severity including: informative, debug, warnings, or errors.

The console object also allows you to make assertions to more deeply test your code as well as performing stack traces, time sections of code, and log the number of times a function is called and has been executed.

All of the console logging methods can format strings using patterns similar to the C stdio printf() family of functions.

Command Line Functions

For command line junkies like me, console mode gives you access to a wealth of query and history/editing features you're probably already familiar with. Even more powerful are the following predefined shorthand functions:

• $("id") - A shortcut for document.getElementById().
• $$("css") - Returns an array of elements that match a CSS selector.
• $x("xpath") - Returns an array of elements that match an XPath selector.
• $0 - Variable containing the most recently inspected object.
• $1 - Variable containing the next most recently inspected object.
• $n(N) - Returns the Nth most recently inspected object.
• inspect(object) - Displays an object in the DOM Inspector.
• dir(object) - Returns an array of property/method names on an object (Python anyone?)
• clear() - Clears the console.

>>> inspect(document)

is a good place to get started.

CSS Quick Search

While in Inspect mode, you can use the quick search box to locate any element by entering a CSS selector. FireBug will display all matching elements in the console view, which you can then expand to view more details or switch tabs to explore the stylesheet that defines the rules for each element, the computed propeties and layout/display attributes, JavaScript events that are attached to the element, and even the gory details of DOM for the selected item.

You can also use quick search to match JavaScript events.

In the future, Joe plans on adding XPath search as well as plain text. For those in a hurry, you can try the getElementsBySelector() JavaScript function, which uses the Firefox XPath API to translate CSS selectors to XPath making them a lot faster than searching the DOM directly.

FireBug 1.2

Some of this material is a bit dated. For the latest on FireBug, visit the new Get FireBug Web site and in particular the "Learn more" feature links on the home page and the documentation section.

Prototype version 1.5 has just been released and includes many enhancements and bug fixes. Best of all, excellent online API documentation. For more information on the latest version, visit the Prototype blog.

Joe Hewitt has announced the final release of FireBug 1.0. Rather than go into all the details about new features and enhancements here, I'm going to refer you to the Yahoo! User Interface Blog where you can view a lengthy video featuring Joe as he demos the new version. Joe has put an enormous amount of work into this extension, if you use it regularly and it saves you time and frustration, then consider helping out with a donation.

JavaScript development just keeps getting more efficient and powerful!

In my second visit to the DC PHP Developers group meeting I joined yet another over-crowded room of local programmers for this month's presentation. I really appreciate Robyn Wyrick's efforts to put these meetings together, but it's becoming clear that the venues provided by the National Press Building are faltering—a testament to the growing popularity of the group.

Jonathan Modell was tonight's presenter. A DC local, recently returning from a 10 year stint in Colorado (my home state, or more accurately I was born in Durango and then lived in Boulder for a year), Jon has extensive experience in many aspects of Web development.

His presentation focused on how he learned to integrate Ajax technology within a core PHP system. Obviously this is a hot topic, if somewhat too hot in my opinion. In a nutshell, Ajax allows you to create an HTTP request back to a server-side script, and then dynamically insert the results into your page via the DOM—all without having to POST or GET a new page (something most PHP programmers are well versed in).

Web-based applications that quietly introduced this technique are most famously associated with Google. First was "suggest" a sort of search as you type, and then Gmail and many others that began to reinvent how Web pages could improve interactivity. In truth, it was Microsoft (circa 2000) who first implemented the XMLHttpRequest (XHR) object in their version of JavaScript (jscript). Later browsers (Firefox, Safari, et al.) followed suit.

As the function implies, the traditional payload of a server-side script called by an XHR request is XML. I know of very few people that continue to do this. By far the simplest method of dynamically insterting results into your page is to use a element with a unique id, initially hidden via CSS, then grab the data returned as normal markup (for instance a set of unordered list elements), then use innerHTML to update the DOM, and finally "unhide" the element (typically a <div>). This technique is sometimes referred to as AHAH.

JSON is another lightweight technique for returning data to the requestor. It's basically serialized JavaScript in the form of name/value pairs that you eval() on the client-side for parsing and insertion into your page. In addition to JSON, the Yahoo! Developer Network set of Web services are able to return serialized PHP. Although not as applicable to an Ajax implementation, it is none-the-less an interesting method worth investigating. If there is such a beast as a JavaScript unserialize PHP function or class out there, by all means drop me a comment. For PHP developers interested in available packages for encoding and decoding JSON data, visit this comparison of PHP libraries. As of PHP version 5.2.0, JSON support is native.

In the early stages of his presentation, Jon confessed to having tested many of the Ajax JavaScript libraries that are floating around out there, and then spoke highly of his choice to use Sam Stephenson's Prototype. He is not alone, not by a long shot. There are a number of frameworks that are built on top of Prototype: RoR, Rico, and "effects" libraries that include script.aculo.us and moo.fx. PHP frameworks with built-in Ajax support include CakePHP and ModX.

If you are doing this sort of development work, I cannot emphasize enough how much Joe Hewitt's fantastic FireBug Firefox extension will save you hours of headaches.

To conclude his presentation, Jon demoed a social networking application that displays a calendar of events and the members who are attending, locations, dates, and so on. I came away with the feeling that traditionalists in the audience were impressed how the page would update without the need to refresh it. But keep in mind that is the nature of asynchronous requests. There is nothing particularly new going on here, these are normal HTTP requests, they just happen to occur in the background via JavaScript and a little DOM magic to alter the page on the fly.

A few days ago an informal poll appeared on the Digital Web news page asking visitors if they are Formally Educated or Self-Taught? I was surprised by the large number of respondants (many of them highly influential developers) stating they are mostly self-taught.

Another prevalent thread running through the comments is the concept of learning by observation, or what I like to call "how'd they do that?" In order to understand a technique, one of the best methods is to study source code. This is easy enough to do with any browser, and Firefox has some extensions that make it even easier. On my own Web site I try to expose as much as possible, including the markup, PHP source code, I also list my CSS and JavaScript files in the sitemap, and so on. These are just niceties, because other than code originating on the server-side (PHP for example), anything delivered to the user-agent is viewable in source form. Unless you're in the obfuscation camp, which I'm not here to discuss (shame on you if you are).

By now you may have heard of Ajax, and the booming trend in dynamic or DOM or client-side scripting that goes along with it. In other words, JavaScript is red-hot right now. If you're just getting into scripting, then this is a damn fine time to be learning by studying the code that drives all this stuff. It's also a fine time to be learning JavaScript because its reputation as a toy language with many poor examples is quickly being replaced by a new-found respect and clean, structured code.

As far as JavaScript code goes, there are a couple of different sources you're likely to run into. Embedded JavaScript can be found right in the markup. This is still almost as common as it is a bad practice. So there you are, back to viewing the page markup. Often this practice is made even worse by code that is disorganized and dispersed all over the place. There is also inline JavaScript, most often used to fire on certain events such as onclick, but I'm not going to get into that here. Likewise for so-called "javascript:" protocol URLs, such as those used by bookmarklets.

A better solution is to use the src attribute of the <script> element to include external libraries of code. Some developers claim this can cause the page to load more slowly since it involves an extra HTTP GET request for each included JavaScript source file. In my opinion modularity, code maintenance and browser caching of the external scripts easily trumps these concerns.

So once you land on that page with the fancy JavaScript effects, what is the best way to study the techniques being used? One method is to open the source of the page, locate the code embedded in it, or in the case of external source, copy the URL to the file and make a separate request with your browser. Using this rather tedious method for external code with Firefox and most other browsers will result in the code being displayed in a window as plain text, although IE has a nasty habit of prompting you to download the file rather than simply displaying it.

A more elegant solution is to use JSView, a Firefox extension which will open up separate view-source windows for any or all external JavaScript files referenced by the current page (it will do the same thing for external CSS). I find this method acceptable if I only want to look at a particular file, and it sure beats hunting through the markup, copying (and possibly having to modify "../.." paths) then pasting the URL into the address bar of a another tab or window so you can continue to view and test the rendered page.

But this method only works for external source code. Some pages use a mixture of external files and embedded code. In these cases, the all-powerful Web Developer extension really shines. From the Information menu, select "View Javascript" and the extension opens a new tab with all the JavaScript from the current page concatenated into one view. Code from external files are labeled as such with links to the files, and embedded JavaScript is labeled as "Inline Script" referencing the document that defined it. The code appears in source-order, or in other words in exactly the same sequence as it is appears in the markup.

But source order is not important to the JavaScript interpreter embedded in your Web browser. It simply builds a collection of objects after receiving and parsing each form of source code, and then waits for some event to fire that will trigger the intended behavior. If you think in these terms, which I recommend, then Steve Chipman's JavaScript Object Tree favelet/bookmarket is the way to go. To use it, simply drag a copy of the link to your bookmarks toolbar, then on the page you want to study click the link. A new <div> element appears overlaying the top portion of the document and in it you will find a collapsed tree-view of every object type defined by that page. Object types include functions, objects (arrays, dates, etc.), strings, numbers, and so on. To expand an object type into a list of its members, just click on it. To view the value of an object, which in the case of a function is its source code, just click on the item by name. You can easily collapse parts of the tree in the same manner.

Another really handy favelet is Shaun Inman's View Rendered Source, which also overlays the current document with source code, but not JavaScript code. Rather, it displays the browser's internal view of the markup after any changes are made to the DOM. For example, if a script is using Ajax to insert new elements into the document tree and you want to observe the results, then the script will give you a before and after snapshot of the markup.

Remember that observation and studying working examples are powerful ways to learn how Web software is built, and a great way to improve your skills. Whether you are a new or a seasoned JavaScript developer, if you plan on studying code in the wild then Firefox and its many extensions, and any number of other tools (I'm just scratching the surface here) are the way to go.

On a tip from Krista at Digital Web Magazine, I learned that O'Reilly's seminal Web Design in a Nutshell by Jennifer Niederst was recently released in a 3rd edition. This is good news since the 2nd one was getting a little dog-eared and needed to play catch-up with the latest trends and techniques. I hope O'Reilly is planning on doing the same for Webmaster in a Nutshell.

Acclaimed accessibility advocate Derek Featherstone and Digital Web contributing author Aaron Gustafson both invested some of their time in the Nutshell project, and today A List Apart has published an excerpt from Aaron's work titled Getting Started with Ajax. The article does a good job of introducing Ajax concepts, including the JavaScript XMLHttpRequest object, various data formats that can be returned from such calls, and how to update the DOM of the page with the requested data. Aaron uses the simple XHConn interface library in his examples, and provides sample code, both markup and JavaScript. Keep in mind that ALA is not a programmer's magazine (any more than Digital Web is), so do not expect gory details here. But it is important for designers to understand Ajax development since it is a client-side technology. Or at least the designer's half of the equation.

And this leads to my point, something I plan on asking as many designers as I can corner at SXSW—in this day of Rich Internet/Web applications and Ajax (I really hate to mention Web 2.0), do you see the line between designer and programmer blurring a bit more? If you're not able to make it to the convention, feel free to post your viewpoints here, regardless of whether your area of expertise is design or code.

Well boys and girls, in just one weeks time those who can make it will be jetting down to Austin, Texas for the South by Southwest 2006 Interactive Festival. If you are lucky enough to have the whole week off you can stick around for the music and indy film festival as well. I've never been to Austin myself, but I have an old friend who lives there. So I will also be taking the opportunity to hang out with him, and he knows the area well so maybe I can coax him into stopping by to share some tips on good places to eat and the famous local music scene.

I thought I would take a few moments to share with everyone what panels I find interesting and what parties I will be attending. Some of these overlap, or may fill up fast so there is no guarantee I will be at all of them. Except for the parties of course, since there will be some people at each I am looking forward to meeting in person for the first time, not to mention the free food and drinks. Oh what fun it will be to snap pics of drunken digerati and upload them to Flickr so I can post them to this blog later.

Saturday, March 11th

• How to Bluff Your Way in DOM Scripting [Jeremy Keith]
• Creating Building Blocks for Independents [Tantek Çelik]
• Starting Small: Web Business for the Rest of Us [Nick Finck]
• South by Northwest [Blue Flavor, Newsvine]

Sunday, March 12th

• Making Web 2.0 Accessible [Derek Featherstone]
• Flickr, Upcoming.org, and del.icio.us in the company of Yahoo!

Monday, March 13th

• Web Standards and Search Engines: Searching for Common Ground [Molly Holzschlag]
• CSS Problem Solving [Dave Shea]
• Microformats: Evolving The Web [Tantek Çelik]
• WaSP Task Force Panel: Getting the Job Done Right [Drew McLellan]
• Ambient Findability [Peter Morville]
• Design Eye for the List Guy [Keith Robinson]
• WaSP Annual Meeting [Jeffrey Zeldman]

Tuesday, March 14th

• RSS: Not Just for Blogs Anymore [Christopher Frye]

Note that each panel consists of several speakers, all of them worthy of mention. I am simply listing the person I am most familiar with. Parties are indicated in green (is there really any need to post links to the sponsors of the second one?)

I'm looking forward to seeing everyone there!

Always on the lookout for more than just code libraries and the basic documentation (if any!) that generally comes with them, I came across a very interesting piece from Dustin Diaz today. In Forget addEvent, use Yahoo!'s Event Utility, he spends some time really picking apart the Yahoo! User Interface Library: Event Utility.

These JavaScript libraries tend to be large (the Yahoo! namespace source file is only 1.5k, but event.js weighs in at a substantial 30k), so Dustin takes the time to strip extraneous whitespace from the source and then wraps the code in PHP, which by using ob_start() and the gzip callback handler, he is able to compress the code down to only 2k. And before you go crying "IE doesn't handle compressed JavaScript well or cache it!", he also takes care of sending the correct HTTP headers to do just that.

According to the Yahoo! API documentation (which is excellent by the way, ignore the crack at the top of this post):

The Event Utility facilitates the creation of event-driven applications in the browser by giving you a simplified interface for subscribing to DOM events and for examining properties of the browser's Event object.

What Dustin is interested in highlighting are these features:

• Handler Attachment Deferral
• Automatic Scope Correction
• Automatic Event Object Browser Abstraction
• Send an Arbitrary Object to the Event Handler

Along the way he drops in some great code examples and wraps up with the obligatory sample page to show off what the code can do. Dustin is very excited about this library, and even asserts dropping any of the various incarnations of addEvent() in favor of the Yahoo! Event library. Which need not concern you, since it is released under an open-source BSD license.

Nice work, but take it easy on the "dope," "tight," "sexy" and "sweet" next time, will ya?

Question: Which of the following DTDs allow target attributes with anchor elements?

• HTML 4.01 Strict
• XHTML 1.0 Strict
• XHTML 1.1

Answer: None of them.

The target attribute is designed for frames (who uses frames?)—if you want to use targets, use a Frameset or Transitional DOCTYPE.

Sadly, I am witnessing an ever growing trend with sites that serve strict document types (XHTML in particular) and insist on opening new windows from external links. Yet they still want to sport the "Valid" XHTML W3C badge on their sites.

The trick? Simple, just use a rel attribute of "external" on those anchor elements, and then dynamically alter the DOM using JavaScript to add a "_blank" target attribute.

It took me all of 5 minutes to write this little function and test it with an XHTML 1.1 document:

/* give anchors with attribute rel="external" a target attribute of "_blank" */

function external() {
 if (document.getElementsByTagName) {
  var i, a;
  a = document.getElementsByTagName('a');
  for (i in a) {
   if (a[i].getAttribute('href') && 
       a[i].getAttribute('rel') == 'external') a[i].target = '_blank';
  }
 }
}

window.onload = external;

/* external.js */

The results? The W3C Validator happily reported "This Page Is Valid XHTML 1.1!" Why? Because of course it doesn't know anything about what happens to the DOM after you've altered it with client-side scripting.

Is this old news? Probably. Do I intensely dislike people who insist on opening new browser windows just because they are under the (false) impression they will somehow retain the visitor by doing so? Yes, very much. And I happen to the think this point of view is ass backwards. Thankfully, I can use a browser like Firefox that allows me to at least redirect these links to a tab—and when I notice it happening, it usually only takes me one more visit before I mentally blacklist that site forever.

Are there times when opening a new window is warranted? Occasionally, if done with care and for the right reasons. I'm not going to get into that. Argue amongst yourselves.

The Yahoo! Developer Network has just released a complete open-source User Interface Library.

The Yahoo! User Interface Library is a set of utilities and controls, written in JavaScript, for building richly interactive web applications using techniques such as DOM scripting, HTML and AJAX. The UI Library Utilities facilitate the implementation of rich client-side features by enhancing and normalizing the developer's interface to important elements of the browser infrastructure (such as events, in-page HTTP requests and the DOM). The Yahoo UI Library Controls produce visual, interactive user interface elements on the page with just a few lines of code and an included CSS file. All the components in the Yahoo! User Interface Library have been released as open source under a BSD license and are free for all uses.

Perhaps even more interesting, are a growing set of Design Patterns that include:

• Auto Complete
• Breadcrumbs
• Drag and Drop
• Module Tabs
• Navigation Tabs
• Pagination

There's a ton more information available on the YDN Web site. For additional feedback, RSS feeds, articles and announcements, visit the Yahoo! User Interface Blog.

For many years I dismissed JavaScript as a toy language, something that was only used to perform cute Web tricks (who can forget mouseovers?). Worse (as is often the case), because folks quickly realized you could use it to open new windows, it was exploited (and still is to some extent) for advertising purposes. It also suffers from (perhaps even more so than HTML) the "how'd they do that?" copy-and-paste mentality that still pervades the Web to this day. The so-called browser wars certainly didn't help much, with Netscape and Microsoft going in different, proprietary directions with their implementations of the language.

I am not alone in these sentiments.

However, since the standardization of markup languages, JavaScript (ECMAScript), the DOM and, more importantly, the DOM Event Model (since JavaScript is most often used for creating "behavior" or interactive features), the language has really matured and is finally receiving the recognition that is long overdue.

Does your Web project require remote scripting (AJAX)? Then you will need to understand how to code in JavaScript. How about creating something using Greasemonkey? Or authoring a Firefox extension? Guess what—JavaScript is a key ingredient in Mozilla's powerful cross-platform development framework. If you want to get really fancy and add desktop features like animation, drag-and-drop, and so on, JavaScript is the method of choice.

Many of these examples ring true for me, and delving deeper into the language I found to my surprise that JavaScript is an elegant, deceptively simple, and powerful programming language. A new wave of frameworks and code libraries are paving the way out of the old days of HTML bulging with snippets of poorly written, embedded code. Another frequent complaint are the lack of tools necessary to ease the development of JavaScript code. Admittedly, the Venkman JavaScript debugger has been around for a while, but new tools such as the DOM Inspector, Console² and the MochiKit JavaScript Interactive Interpreter are changing all of that.

So, love it or hate it, even us old server-side developers must embrace this new JavaScript, and add it as a permanent member of our toolkits.