Chrome: a silver lining for developers

September 22nd, 2008
by Kristof

The contest for best post-title is over. I just won it. Now, on to reality.

Did we need another browser? What's up with Google supporting Firefox and then coming out with their own Open Source browser?

I took Google Chrome for a spin as a developer and found out some interesting things. Sure, Google Chrome has no developer toolbar at this moment, but who needs a developer toolbar with all the built-in goodies from Safari? (Thanks Lagaffe). Check out what Google Chrome has to offer for developers.

Until now, people had to rely on Firefox and Firebug to debug their web pages. IE has had a developer toolbar since not too long ago but, face it, nobody develops for IE anymore. We all build things according to standards and then check IE to see where they didn't apply the standards. Right? Well, not entirely. A lot of people still depend on IE as their sole window on the web. This article does not apply to them.

Google chrome may well be the best thing ever to happen in the last year for web developers. Loaded with Apple's Webkit, it has what is probably today's best rendering engine. Webkit/Safari is the only browser that's getting a 100% test result on ACID3. Granted, it's on a developer build and Chrome isn't currently profiting from that build and is stuck at 79% which is slightly better than Safari's current stable release test result.

But how does one take advantage of all the features Chrome has to offer?

DOM Tree Inspector

 

Upon right-clicking anywhere on the browser screen and selecting "inspect element", a new window opens and it shows you where in the dom tree you clicked. It takes this even further. You can simply hover over an element in the dom tree and that element will get highlighted in the actual webpage. (on a side note: As I'm typing this, I'm also taking advantage of another great Chrome feature: drag the edge of any textarea to enlarge that textarea. Really handy when blogging) You can expand and collapse parts of the DOM  tree. It does NOT react to changes in the DOM tree but it does reflect that actual current status of the DOM tree. Confused? When you open the console, you get the actual status of the DOM tree. If you have, for example, a photo gallery where people can drag their own pictures around and re-order the gallery, the console will not update to every change made to the gallery. If you however make changes, close the console and come back, it will reflect those changes. It's a bit of a workaround but it's really handy to check your AJAX and MOOtools based websites (until Dreamweaver CS4 hits the market).

The great news is that it will show you the domtree for dynamically generated content as well. If you have some Javascript lying around that dynamically displays pictures, fetches remote text and creates div's on the fly, you can use Google Chrome to keep track of all that and find that one div that doesn't get created correctly.

CSS Inspector

Google Chrome has what I find to be the best CSS inspection module available today. Firefox has a few nice ones but Chrome definitely takes the cake.

As you can see on the left, Chrome has a number of things to say on every element of you web page.

Just select an element in the DOM inspector and the corresponding style will show up. Not just THE corresponding style as the Firefox developer toolbar can, but it will show you everything you want to know.

Let's start with computed style. This are the current style modifiers applied to the selected object. This may not be what you thought it would look like. Instead, Google Chrome simply adds up all of your styles and shows you what is applied.

Beneath the Computed Style are the other style elements that are applied to the object. All the style elementes you find are what make up the computed style.

In this case, I have the #footer div highlighted. It gets the color from the #footer h2 declaration and the margins from a previous h2 declaration. What declaration? Simply click the link next to the style element and you'll be taken to the CSS that declared it.

Check out the styles that were struck out. That means you applied that style but the style got overridden somewhere else. Google Chrome makes solving these problems a breeze. If I check out the "color" part that got struck out, I can deduct that it got overridden by the color declaration in the #footer h2 element.

The properties at the bottom of the screen should be self-explanatory but I would like to draw your attention to the Metrics box. This box actually shows you how the selected object is drawn. The footer, in this case, is 760x22 pixels, has no padding, no border and a margin of 30. Actually, that is not correct. The footer has no padding declared, hence the dash.

Using this style console has saved a number of my days already by helping me pinpoint those typical problems you get when editing humongous stylesheets.

 

Javascript console


At the bottom of the console is a small button. Hover the button and it'll say "console". It's a Javascript console in which you can type actual Javascript. Not just the alert as I've demonstrated, but also calling functions in your webpage so you can debug them in the Javascript debugger (alt+`).

Resource console

Last is the resources console. You can access this by simply clicking the "Resources" button on top of the console window. It may happen to you that this window is empty. You can fill this by simply going to the webpage you wanted to check and reloading it. The resource console only shows the resources that are loaded when the console is active. The blue bar is the HTML page. The green bar is the CSS. The purple bar are "other" resources such as flash files or images. The orange bar represents Javascript files and the grey bar is the garbage can.

For each resource, you can see the start of the request, the time it took for the server to start returning data and the time it took to receive the data and render it on screen. It's not useful all the time but it can tell you which files are slow to load and might by holding up your web page. You can also use it to track server response times. Don't rely on this too much when dynamically loading information from the web page. Each additional load, through AJAX or simply loading in a new image will expand the "loading time" from your web page.

Conclusion

Aside from the wondrous interface and the incredible speed at which Chrome handles or helps to handle complicated pages (like the WordPress admin interface), Google Chrome is mana from the heavens for developers. It may take a few hours to get used to the new interface and to understand all the information you're getting but once you'll have mastered the information, you'll wonder how you ever managed without them.

Google Chrome already made me look good and other developers I talked to have also switched to Google Chrome - even if only for debugging the heavier parts of their website.

So, did we need another browser? I guess we did.

Posted in HTML, Selfish, UI & Usability | Comments (10)

10 Responses to “Chrome: a silver lining for developers”

  1. Lagaffe Says:

    All the developer tools you’re talking about are part of Webkit and are available in Safari as well.

    On a mac you need to activate them by excuting “defaults write com.apple.Safari WebKitDeveloperExtras -bool true” in terminal. Activating the internal debug menu is nice as well: “defaults write com.apple.Safari IncludeInternalDebugMenu 1”

    On Windows, you’ll have make sure that the following lines are in your preferences file at the location “C:\Documents and Settings\\Application Data\Apple Computer\Safari\WebKitPreferences.plist” (where should be your Windows user name):
    WebKitDeveloperExtras

  2. Lagaffe Says:

    Looks like the form filtered the XML code :-s

    WebKitDeveloperExtras

  3. Lagaffe Says:

    And he did it again :p

    The information can also be found on: http://trac.webkit.org/wiki/Web%20Inspector

  4. Kristof Says:

    Hey Lagaffe,

    Thanks for the additional info. I had no idea that the developer tools were actually a part of Webkit. Thanks for setting me straight! I’ll make sure to check those tools in Safari!

  5. Mateo Says:

    To me, this is not as powerful as Firebug and the addons for Firebug 😛
    FF is heavy on resources but imy PC doesn’t have problem to handle too many windows and tabs, so, i can live with it.

  6. Sabra Says:

    I have already switched to Chrome permanently, since this lightweight browser rocks! For development, I was surprised by the built in features. What a bonus for developers! Thanks for breaking it down!

  7. Pat Says:

    I find that not having the css link not show you the actual line number that the style is set in the file is a pretty big reason for me continuing to use Firebug. If it wasn’t for that one feature, that I use pretty constantly, I would be 100% Chrome.

  8. Han Sanosyan Says:

    Very informative put up, love the way you write and I think that the data helps in a way. I don’t usually say this, but I feel this can be a nice job done. When you prefer to exchange links, I would be very happy to supply a hyperlink again to your site. Hope to hear from you soon. Cheers

  9. Niki Q Says:

    Hi what theme are you using on this site? I love it 🙂

  10. Kristof Says:

    Hey,

    This theme was custom made 🙂 It features … ME!

    Thanks for asking,

    Kristof

Leave a Reply

SEO Powered by Platinum SEO from Techblissonline