This is good news.

Advertise here with BSA

Firefox has been all over the news lately with the release of Firefox 4, the latest version of what was once my eye-opening favorite browser. Lots of browser talk focuses around performance. Every time a new browser version comes out many of the intro paragraphs for reviews mention ”OMG FASTTTT!” at least once. Speed is of the essence online, and the browser can have a large impact on that experience. Mozilla is doing something interesting by ranking Add-ons with the Slowest Start-up.

I wasn’t surprised to see Firebug, arguably the most impactful browser add-on in the history of browser Add-ons, but I was surprised to see it tied for first place as the slowest performing Firefox Add-on. I switched to OS X in 2006 and the first thing I noticed was that Firefox felt slower. I asked around and others confirmed that although it was their primary browser, it did in fact feel slower on a Mac.

Time went on, and Web Inspector came about, resulting in Safari finding a home as my default browser, as Firefox continued to grow glacial for me. Then Chrome came out, with a much more rapidly updating Web Inspector, and I haven’t looked back. I far prefer Web Inspector to Firebug now and knowing that it’s built in as opposed to being the slowest Add-on in my arsenal has me all the more comforted by my decision.

Advertise here with BSA

Acid3 made waves back when being a standardisa often meant being a bit (too) zealous about validation and the like. It was often used as a solid benchmark for browser compliance, and many times I’ll still see references to a browser’s Acid3 score before and after an update.

Firefox has received a slew of slack on this particular issue for quite some time now. It’s great to uncover the truth about it and spread the word about those browsers that do in fact score 100 on Acid3.

There’s something to be said about conforming to test requirements if it means putting real world experience aside and implementing for the sake of the test. Quite an interesting read.

Advertise here with BSA

I’ve been using Chrome exclusively for roughly the past six months, before that it was Safari. Needless to say I’m a big WebKit fan. I didn’t become one until moving to OS X, before that I was a die hard Firefox user when I ran Linux. I remember first stumbling upon Firebug and it was a glorious day. That extension completely changed the way I built websites. When WebKit first came out with the redesigned version of Web Inspector, I was thrilled. Front end development just got totally awesome in both Gecko and WebKit.

Admittedly, the aesthetic of WebKit’s Web Inspector had a draw on me, I loved it. The only problem was Safari’s release cycle. Sure there were WebKit Nightlies but… they’re nightlies. I need to test in browsers that are actually being used. Then came Chrome. A faster release cycle with an updated Web Inspector every time. That’s been my story for the past number of months. There’s no getting around the fact that Firefox’s performance on OS X leaves a bit to be desired when compared to Linux and Windows. I was happy with Chrome. Then the geniuses behind Firebug go and do something like this:

Smitten. Instead of the same old console.log you can fancy pants console.table your data.

That’s just one of the new features coming to Firebug 1.6, but it’s one that has my attention. The browser market is a cutthroat (in a great way) brotherhood, and it’s awesome. I love the fact that I can’t make it six months without thinking about switching browsers. Best of all, there’s only good coming from the competition.

Advertise here with BSA

The building process

Over the past couple years I’ve wavered back and forth between building websites in Firefox and Safari. With the release of Safari 4 beta, I’m 95% sure I’ll be sticking with Safari this year (the Web Inspector alone is stunning). The main point I’d like to get across is that you begin work on every website using a modern, standards-respecting browser.

Using a well built browser will help keep your markup and style lean and clean. Starting out with a substandard browser will bloat everything from the start; not something you’re looking to do. After your initial build, you can then take your work through The Browser Gauntlet.

It’s a familiar feeling for any Web designer — you’ve completed the first series of pages, you feel great and go get a cup of coffee. The next time you sit down, it hits you: time to test. To this day I still get a few butterflies as I come to that very realization.

My Browser Gauntlet

My primary workstation is a Mac, so I’ll begin testing using browsers native to OS X. After building the site in Safari I’ll quickly test in Firefox. It’s been a long time since any discrepancies have appeared during this first test, so it’s more of a quick sanity check and move on. From there I’ll test in the latest stable, public release builds of Opera and Camino. I’ll also check things out in the latest WebKit Nightly to future-proof a little bit.

Although I test in five browsers at this stage, it usually takes only a few minutes since each browser is extremely capable as far as standards are concerned.

The next thing I’ll do is boot up Windows XP via VMware Fusion. I’m a huge fan of Fusion, but using a virtual machine (in OS X or otherwise) is a serious timesaver.

I’ll begin testing in Windows with standards capable browsers. First I’ll test in the latest public release of Firefox (3.0.7 at the time of this writing). I’m also still testing in the latest version of Firefox 2 (2.0.0.16) as I’ve found some discrepancies when working with Flash between Firefox 2 and Firefox 3. I’ll also test in the most recent versions of Opera, Safari, and Chrome. Again, this testing usually takes a few minutes at most.

Next I’ll test in Internet Explorer. I’ve tried a mix of Snapshots to test each version of IE, but found that process to be a bit slow for my tastes. I’ve had great luck with IETester, a free Web browser that lets you easily switch between Internet Explorer rendering engines. As of this writing, IETester is at version 0.3 and includes engines from IE8 RC1, IE7, IE6, and IE5.5 on both Vista and XP.

Some designers I’ve talked to feel IETester is a bit buggy for their taste, but I’ve found a trick that works for me and has absolutely no technical backing. If the first tab you open is of the default browser on your system, switching between various rendering engines is quite stable.

Using IETester, I will first test in Internet Explorer 7, and correct inconsistencies using conditional comments. Once things are stable in IE7, I’ll move to IE6, which is the longest stage of The Browser Gauntlet. Again using conditional comments, I’ll make my way through the shortcomings of IE6, gracefully degrading where applicable. I don’t make a big deal about it, just make things tolerable and move right along. Last, I’ll quickly look at the site in IE8 (latest release) and tidy up there as well where I can. I no longer test designs in Internet Explorer 5.5 as our metrics don’t call for that attention to be provided.

The final steps of my Browser Gauntlet reside in Ubuntu. Ubuntu is my Linux distribution of choice, and I always keep a stock installation available in Fusion not only for testing purposes but also to play around with from time to time. I feel it’s important to test in a Linux environment not because a significant number of people are using Linux, but because the operating system gives us some variables we may not have otherwise expected. The most obvious differences are with type rendering in the browser, so I make sure to keep only the default font installed that come with Ubuntu. This helps me validate included font stacks and make sure nothing breaks for Linux users.

Once I’ve booted into Ubuntu, I’ll first check renderings in Firefox. From there I’ll check things out in Opera, Epiphany, and Konqueror. These browsers often use the latest releases of either Gecko or WebKit so it’s rare that any significant trouble pops up. The most significant thing I’ll keep an eye out for at this stage is type inconsistency.

Once testing in Linux is complete, I’m quite comfortable moving on to the later stages of development (integration with a CMS, adding behavioral JavaScript, integrating Flash elements, etc.). I’ll repeat this process before showing the client anything, just to make sure the design is properly reflected after the bulk of the work has been done.

Testing in mobile browsers

The mobile space will continue to advance, and when a client requests a mobile version of their website, there is an additional step to browser testing that takes place. While I don’t have a wide array of mobile devices on which to test, I’ll do what I can with the tools I do have. Primary testing takes place in the iPhone simulator, as iPhone optimized sites are primarily requested at this time. The iPhone simulator is available in the iPhone SDK and allows really quick and easy testing of iPhone-optimized designs. Blackberry optimized sites are also requested from time to time, and although much less streamlined, there are a series of device simulators available. The simulators are Windows-only, so I’ll do my Blackberry testing using those tools made available. Another popular platform to test with is Opera Mini. Many handhelds use Opera Mini, and the Opera team offers a simulator (demo) for that as well.

Unfortunately, not many of my clients have requested mobile optimized sites, but I will be integrating that testing pattern into my process as more websites come through the door.

Effectively testing for the mobile space is not as easy as the desktop, but more tools are becoming available, and there is always the device itself on which to test. Unfortunately quite a bit comes down to the client budget and how much has been allocated for the mobile space. We’ll be seeing more mobile-optimized clients over the coming years, so it will definitely be in your best interest to learn about the available tools and become familiar with them.

Your turn

Browser testing is a bit of a pain for Web designers, but it’s also a responsibility. One thing I’ve noticed as I continue refining my skill, is that browser testing takes up less time with each website I build. With each website, you’ll more than likely pick up something new. With each piece of knowledge, you’re preparing yourself for upcoming projects. You’ll have in the back of your head the knowledge that building this layout is going to cause the same headache as the last one, and you’ll be able to take a more aggressive approach to solving the issue before it’s even a problem. Don’t look at browser testing as a hassle, instead think of it as the finishing touches on the best work you can do.

Is your Browser Gauntlet similar to mine? Are you testing in a browser that I’ve overlooked? Do you have any tricks up your sleeve to make browser testing less painful?

Advertise here with BSA

Safari has definitely come of age

Safari 3 was a leap ahead for the browser, and I loved (nearly) everything about it. WebKit is phenomenal, and we’re finding it implanted in more applications than ever. I was excited about all the changes going on with Safari 3 during the time of its initial release, and made an effort to use it as a primary browser. Not because I was looking for something different from Firefox, but the performance issues were a constant.

I did my best to try to beef up Safari 3 just enough to make it work for me. I stumbled upon Safari Tidy which is an equivalent to the HTML Validator Firefox extension which I’ve come to know and love. The plugin worked well, and there was a command line adjustment to enable a hidden Debug menu which provided an error console, WebKit’s Web Inspector, and a few other really useful tools. I only used the HTML Validator extension and Firebug in Firefox, so with these two modifications I felt it was fair to see if Safari could work for me.

Safari’s Develop Menu The Develop menu available in Safari 3.1

I quickly found that I had become extremely spoiled by Firebug. WebKit’s Web Inspector is really great, but the error console doesn’t really compare to the console in Firebug. Safari 3 was not the proper browser for me to use. That is, until Safari 3.1 was released. With the release of Safari 3.1, Web developers were provided their very own Develop menu which, I must say, is spot on with including the tools I make use of most often. Instead of providing a tool for everything under the sun, you’re provided a short list of Web development tools to make your life easier.

The Develop menu in Safari 3.1 summarizes very well the toolset I generally use most often in my work. Web Inspector continues to be an extremely valuable tool for both analysis and debugging in Safari. I was really excited to see integration with the browser window itself a la Firebug. The Safari Tidy plugin isn’t compatible with 3.1, but the error console has been given a bit of a boost and provides some insight regarding any markup errors in the document.

Overall, I think Safari 3.1 has really stepped things up a bit insofar as to include so many valuable tools out of the box. I think that with this release, a number of developers will prefer to work in Safari over Firefox.

How does Safari 3.1 compare to Firefox?

When comparing Safari 3.1 to Firefox 2, I may have found myself making the switch. Had it not been for the release of Firefox 3 beta 4, Safari may be the default browser for me. Firefox 3 beta 4 is a beautiful thing. While not recommended for general use, I’ve adopted it as my primary browser. The performance increase has been substantial and I’ve found myself waiting out delays much less frequently.

While the toolset included by default with Safari 3.1 will be exponentially helpful, I’m going to say that nothing compares to Firebug. Joe Hewitt‘s extension is essentially miraculous for Web developers sprawling the entire spectrum of talent. While still in beta, Firebug 1.1 is the only extension I’ve installed for Firefox, and it’s all I need. I don’t want to make it sound as though I’ve discounted Chris Pederick’s Web Developer extension (because it too is fantastic), but I’ve found that Firebug does anything and everything I need.

What truly sets Firebug apart from anything else for me is the JavaScript interaction capability it offers. Everything from error displays, to AJAX request logging, to JavaScript breakpoints, Firebug offers itself as a more powerful tool than anything I’ve seen. It’s helped me get through quite a bit of work that otherwise may have ended in disaster, and that’s the honest truth. Joe Hewitt has honestly produced a flagship tool for the entire Web design and development industry. It’s no surprise that both WebKit’s Web Inspector as well as the new Developer Tools provided in IE8 have taken a page out of the Firebug book both in form as well as function. Joe Hewitt set the bar for developer tools, and he set it high.

It’s Firefox 3 for me

I gave Safari 3.1 the spotlight for a solid week with production work. I tested it through and through with both basic site development as well as more detailed JavaScript work, and it was Firebug that brought Firefox 3 across the finish line first in my case. I was disappointed to seemingly miss out on the impressive speed of Safari as noted by many. I just didn’t see it. In fact, many times I would be able to launch Firefox and load a target URL before Safari nudged its loading bar. I’m sure it was a bit of a quirk somewhere as I’ve often read that Safari is extremely fast, but unfortunately it’s no speed demon for me.

At the end of the day, I’ll be sticking with Firefox 3 beta 4 as my primary browser, but Safari has truly proven itself as a fantastic platform for Web development.

Advertise here with BSA

Safari Available for Windows

I’ve read a number of articles that were written as a direct response to this event, a post by Mr. Hicks as well as a reaction from Mr. Snook, among others. While Mr. Hicks offers some intriguing questions, I found myself agreeing with much of what Mr. Snook had to say regarding this release.

He said that the release for Windows really doesn’t do all that much for developers working in Windows, with which I agree 100%. Safari uses WebKit, and Safari 2 uses a completely different WebKit than Safari 3, so a Windows developer getting their hands on Safari 3 isn’t doing anyone much good. The improvements implemented in WebKit are exponential in it’s current form when compared to the version used in Safari 2. If you’re looking to test using various operating system and Web browser combinations, it’s best to use them natively (or at least in a virtual machine) in my opinion.

It can’t be ignored what a big change it will be for Windows developers to be able to test in Safari, but in my opinion, this situation (when Safari 3 comes out of beta) will be very similar to the IE6/IE7 mixed distribution. While it will be nice for Windows developers to be able to test in one browser, it will still require a run-through in Safari 2 as well. As will happen with IE6, Safari 2 will eventually be overrun by Safari 3, but that will take quite a bit of time.

Will anyone really care about the release?

So if the release doesn’t help Web developers, will it have any sort of effect on the general population? In my personal opinion, Safari wasn’t ported merely to give Windows users a better experience on the Internet. It was ported because it was seen as a viable way to show Windows users the way of Apple. Many people refer to this type of thing as the iPod effect, iPod halo effect, Apple Envy, or some sort of variant. Hitting Windows users with an application they can use for free, an application they could theoretically use every day, is one more step for Apple in an otherwise Microsoft-oriented world. A Web browser can be a very personal choice for a person, and Apple wants people to choose them.

Firefox has been ridiculously successful in providing people a better way to browse the Web. Apple has seen this success, and in my opinion, feels it is now the best time to capitalize on the idea that Internet Explorer is not the end all be all Web browser for Windows users. It is their time to show that they’ve got a solution as well, and their solution has anti-aliasing in menus to boot. Let us not forget there are also snappy page loads, a small footprint, and that spiffy interface! Safari is an interactive advertisement for Apple, and porting it to the most widely used platform gives the application a very big stage to present itself.

The newest battle in the Browser Wars?

Personally, I’m a big proponent of open competition. If there are a number of high quality Web browsers openly competing to be the best, I think it will force browser manufacturers to provide the best product they possibly can, or else their user base will shift to a provider who can. A very large number of people have embraced Firefox as an alternative to Internet Explorer after it has proven time and time again to be a sub-par Web browser.

To this day I discover quirks and bugs that have continued to prevail in Internet Explorer 7. While it is a slight improvement over IE6, the entire Internet Explorer family of products is truly a sad state considering what is being released elsewhere. At the very least, it’s my hope that Microsoft starts to take their browser more seriously than they have, and the release of Safari for Windows will help to try and make that happen.

The true issue to keep in mind, however, is that the average reader isn’t going to care whether or not you were able to take your design to the next level because you didn’t have to worry about z-index bugs, the only thing that gets noticed is when things go wrong. Many of the drawbacks to Internet Explorer are not seen, heard, or cared about to many people other than Web designers and developers. What does get noticed is a better feature set, a cooler interface, and any performance differences that may be in place. Superior applications will reign supreme when it comes to that criteria, which will eventually decide a winner in any sort of Browser War.

Advertise here with BSA

Customizing browser form controls with user CSS

A small post over at Open Switch clued me into an article with instructions on how to prettify the Firefox widgets (screenshot provided). The post provided readers using Linux a way to improve the aesthetics of the various form controls provided by default in Firefox.

I was intrigued so I took a second to run the small script, after a quick Firefox restart all of the ‘default’ form controls had a new and improved look. At first glance, they’re a vast improvement over the stock controls originally offered. Naturally, I became curious as to what exactly was happening under the hood.

I began poking around the shell script, inspecting the installation process. To put things simply, the script appends two style sheets as well as a set of six images to complete the new control designs.

The purpose of user styles

User styles are designed to allow readers the ability to control how their browser displays content by default. While user styles can still be influenced by site CSS, user styles can have great affect on the final display of any webpage. A good way to think about user style sheets is giving your reader the ability to infinitely expand various dialogs in their browser preferences to include any aspect of a documents design.

In my personal experience, however, I don’t think that I’ve come across anybody that has taken the time to customize their default font size or link colors, let alone use an entire style sheet.

Does anyone you know use their own style sheet?

In your personal experience, have you ever run into a reader who uses a custom style sheet? I personally don’t use one, and haven’t seen any circumstance in which a user style sheet was used.

The Firefox form control updates put a different spin on user style sheets, however. This script doesn’t require that the reader have any working knowledge of CSS, yet a custom style sheet will be applied to all documents after installation. This concept isn’t something that had occurred to me before, but it could be a trend that becomes more common in the future.

There is a moral to this story

What I took home from installing these custom Firefox controls is that user style sheets can have a strong impact on the CSS I author. While some of the applied CSS in this example is overridden by author CSS, there are other selectors that need attention to achieve the look I originally intended. Some of these specific selectors are proprietary, and the thought of having to nullify or correct them wouldn’t normally cross my mind.

Authors have absolutely no control over user styles, and in all honesty, stressing over the possibility of their presence isn’t in our best interest. What’s important to do, however, is be mindful of the possibility that a reader may have a user style sheet for accessibility purposes over aesthetic reasons.

A user style sheet that bumps up the default font size is very important to readers with impaired vision. User style sheets can also be used to improve color contrast by default by forcing a certain color and background-color. These things are important to keep in mind, and the best thing we can do is compensate our CSS with a bulletproof design.

Advertise here with BSA

Testing with text based browsers

In my opinion, testing with a text based browser will be the most true-to-life test case for the average developer. With a text based browser, you’ll be having an identical experience as someone who is actually using that technology on your website.

Current browser statistics, for the most part, are very vague when it comes to specifying text based browsers. They’re often classified into the ‘other’ or ‘unknown’ categories and more attention is given to the modern graphical browsers. It’s true; not many people are using text based browsers as their primary vehicle to browse the Internet, I’m not trying to say that there are. I do feel that it is an important technology to test with, however.

Text based browsers are a great way to get a look at the semantics of your document. Can you still determine the section layout of your document within a text based browser? Does the alternate content for your images make sense in all cases? How do the forms work? Is your navigation still effective? Those questions and more can be answered in full after spending 5 minutes testing in a text based Web browser. There are many text based browsers to choose from, and like graphical browsers, they all behave a bit differently and have separate traits.

Lynx

Lynx was the first text based browser I was exposed to, so I find myself testing with it by default.

Lynx was originally designed for UNIX and is easily run in Linux after compiling from source, or installing through your distribution package management (if it’s available). There are also versions available for Windows (DOS) or Mac OS X.

The one thing to keep in mind with Lynx is that it will transform any tabular structure you have come up with into a linear display, effectively lining up the data cells one after the other. Not all text based browsers behave like this, but it’s important to keep in mind as Lynx is probably the most popular console browser.

Yellowpipe Lynx Viewer Firefox extension

There is also a Firefox extension which will emulate Lynx. While it’s nice for quick tests, it doesn’t give you the interactive aspect that’s also quite important to test the experience you have using a text based browser. Links are no longer active, and you can use a scrollbar to scroll the content, whereas keystrokes will scroll in Lynx.

The actual output also includes ads for the Yellowpipe service which, although small, is quite annoying to me. Given the ability to install Lynx on any platform, using this extension doesn’t seem like a solid choice.

Links

Links is another text based Web browser that stands out with it’s support for tables and frames.

Testing with Links can come in handy if you’d like to retain the structure of your data tables, but other than that I find myself resorting to Lynx by default. Again, this browser was developed for UNIX/Linux systems but there are also installs for Mac OS X, Windows (beta), FreeBSD, and more. There are also hacked versions of Links available as ELinks and Hacked Links which are variants of the original application.

w3m

w3m begins to blur the lines of a text based browser. This application will actually include various inline images where it deems appropriate. I never find myself using this particular browser for actual testing for that reason.

Unlike the previous examples, there aren’t cross platform binaries for w3m available for download.

Update
Thanks to Bob’s comment, you can run w3m on a Windows machine using Cygwin. Thanks Bob!

Text based testing is easy

If you don’t currently give your sites a quick run through with a text based browser, it’s a good habit to get into. It really helps you keep an eye on the semantics of your document, and it also gives you a new look into the usability of your website as a whole. At the same time, you’re able to see how your documents behave without all that fancy Ajax you have going on.

Advertise here with BSA

Some readers may find what I’m writing about to be “designing”, but writing markup and styling documents — to me — is development. If my choice of vocabulary seems wrong to you, I apologize in advance and I hope you can see past it for the length of this article and continue to offer your thoughts.

Firefox not only helps me to develop, it helps me to make my development process streamlined. As an up and coming developer, Firefox and a few extensions can help you to cover more ground faster than ever and really make it easier to visualize what’s going on. One of the biggest hurdles to overcome when first embracing CSS is learning what effect different styles or techniques will have on certain elements or even a document as a whole.

First and foremost: Web Developer Extension

Chris Pederick’s well respected Web Developer Extension opened the doors for many people to Web development. The tools that the extension makes readily available help many people tackle the issues that may have otherwise been a dead end.

Instead of detailing what it is the Web Developer Extension can do, I’d rather give insight as to what I find myself using the extension for every day:

Outlining specific elements

When I first began working with CSS, I would constantly find myself giving certain elements a border style to find out whether or not it was behaving as I was expecting (wrong or not). I’m not sure if this is common practice among beginners, but I still find myself outlining elements on a daily basis to see what’s going on. The Web Developer Extension really helps out in it’s ability to outline block level elements, positioned elements (floating, absolute, and the like) or any custom element of my choosing. It can really help when you’re in a bind about certain elements clearing (or not clearing) when you think they’re supposed to.

Disabling JavaScript

It’s so very important to constantly provide worthy alternate content in your documents. With JavaScript and Ajax being so prevalent and popular as of late, it’s really important to test your sites with JavaScript disabled. I find myself disabling JavaScript in my browser using the Web Developer Extension all the time, and with the convenience it provides, there is no excuse for not testing with JavaScript disabled. It also comes in handy for those times when obtrusive JavaScript makes browsing a particular site an annoyance to use.

Disabling browser cache

If you’ve ever put a website together from the ground up, you know that a browser cache can be disastrous for your process. Neglecting to disable it can provide you with endless frustration from not seeing a change that definitely should have occurred. Disabling the cache with a quick click of the mouse can be very beneficial.

Disabling All Styles

This feature is present in Firefox by default, but I’m constantly using the Web Developer Toolbar hotkey combination (CTRL + SHFT + S) to see what’s going on.. Semantics are really important to document structure and a great way to check up on your markup is to see your document naked.

Disabling Images

Image replacement is an ongoing discussion amongst many people in both Web design and development. A good way to check up on the way you’re using images is to see what a design looks like without images. From time to time, viewing your markup and style without images will let you know that some serious thought should be put into a new image replacement technique.

View Image Information

I often use this feature to refresh my memory about the images making up a particular design after not working with it for a while. Essentially it will give you an overview of all the included images in the document, including background images provided using CSS.

Document Validation

I know I’ve spoken about the HTML validation extensions available for Firefox and other browsers, but the Web Developer Extension also provides an easy way to submit your document for W3C Markup, Section 508, and WAI validation. Beyond markup validation, it also provides means to validate you feeds and CSS in the same menu — having each in a central place has proven to be very useful to me.

View Generated Source

Going along with the aforementioned JavaScript features, another piece of the Web Developer Extension I find myself using is Viewing Generated Source. This comes in handy when you’re using JavaScript to manipulate the DOM and it isn’t behaving as you’d expect. Viewing any markup that’s a result of JavaScript is of great help when debugging or troubleshooting.

Those are the features of the Web Developer Extension that I find myself using most, and hopefully you are able to find one that will make your life a bit easier during your next project. The feature list is so impressive it takes time for someone to try out each and every feature.

While the extension is such a great tool to have, there are areas in which other tools can work faster and more effectively. One such area is working with JavaScript, bringing me to my next essential tool: Firebug by Joe Hewitt.

Firebug is an absolute must have

I’ve always been a fan of Firebug, but not until it’s most recent release has it proved so indispensable. I’ve been reading some accounts of developers saying that it will be able to replace the Web Developer Extension. That’s unfortunate because they’re completely different tools which hold their own ground. If you were a carpenter, would you ditch your flathead screwdriver for a Phillips? Each tool has circumstances in which one may prove to be of more use than the other, so keep both at hand.

When I first started using Firebug, it mainly proved valuable to me only for JavaScript. Having the Firebug console alone was a great feature to have for debugging. With the release of the 1.0 Beta, Firebug is in an entirely different class. As others have said, the style inspector is completely great, and the other features that are included are definitely useful on a day-to-day basis.

Document and style inspection

Firebug not only lets you inspect the DOM, it shows the applied CSS for everything, at the same time. On top of that, it lets you edit everything on the fly.

On the left you find the DOM, and on the right, any applied style is included. What’s really great is that the light gray ‘disable’ icon will actually let you control whether or not that particular style is applied to the element (think ON/OFF). I’m finding something like that to come in really handy from time to time when testing.

Clicking the actual property value of the selector lets you change them on the fly. If you want to change a font size or margin, you can do so instantly. Going further, you can also alter the markup using the DOM inspector in the same way. All in all the document inspection provided with Firebug is unmatched by anything I’ve seen before.

File transfer monitoring

A neat feature that’s also offered with Firebug is what’s called network monitoring. If you’re familiar with the Web Page Analyzer, you’ll like network monitoring in the extension. Essentially, it will give you a visual representation of each file used in your document, and give you insight as to how long each particular file took to transfer.

This can come in handy to get an overview of the file download progression of a particular document and style. Having the ability to discover a bottleneck can help you improve overall load time for a project.

Working with Firebug and JavaScript

By far, Firebug’s claim to fame was the ability to help developers work with JavaScript, and nothing has changed. Logging, error location, debugging, and on the fly execution of JavaScript all set Firebug apart from anything else and make it a must have for Web developers.

As with the Web Developer Extension, there’s much more to Firebug that I haven’t mentioned here. These are just the features I find myself using constantly and think they may be of definite use to people who don’t know about them yet.

Tips and tricks provided by you

I know that everyone uses their browser and extension arsenal in completely different ways. I’m always open to finding new and improved ways to make my life easier using extensions. There are countless extensions that can be added to a list of tools for web development, but the Web Developer Extension and Firebug are the two I’m constantly using day in and day out. Do you find yourself using either of these extensions constantly in any way that I haven’t mentioned? Were any of the uses I did mention something you hadn’t thought about before but might prove to be advantageous?

Advertise here with BSA