If you’re a Web coder, Safari 3 offers some really nice debugging features – if you know where to look for them. First, you need to turn on Safari’s Develop menu (hidden by default). To do this, choose Safari > Preferences, then in the Advanced tab check the Show Develop menu in menu bar option. You’ll see the new menu appear to the right of the Bookmarks menu in the menu bar.

The first option, Open Page With, lets you open the current page in any other installed browser – handy for cross-browser testing. The second, User Agent, tells Safari to masquerade as another browser when viewing websites. Safari still renders pages as Safari, but sends another user agent string to the Web server. This can be useful if you’re testing browser detection code, for example.

Call in the Inspector

The fun really starts with the next option, Show Web Inspector. The Web Inspector window is reminiscent of the Firebug Firefox add-on, and shows you the syntax-highlighted markup (or, by clicking the button in the toolbar, the DOM tree) of the current page, the contents of any linked style sheets, the images used in the page (with info), the source code of any JavaScript in the page, and info on any other page elements it finds.

Click the Console option at the bottom left of the window, and you can see JavaScript errors and other messages; click on an error to jump straight to the JavaScript line that caused it (nice). You can also type your own JavaScript commands into the single-line box at the bottom of the console window and see the results appear above – great for finding out the current state of variables and so on.

Another nice touch: You can log your own JavaScript debugging messages to the Console; much more convenient than using alert(). To do this, use window.console.log():

Deeply cool, though, is the Network option below Console. This reveals a timeline that shows you how long each part of the current Web page took to load over the network. The bars are colour-coded by media type: green for style sheets, purple for images, and so on. This is a really great way to see how long your site is taking to load, and what the bottlenecks are. I’ve used a few such network profiling tools in the past, but none are as readily accessible (and as pretty) as this one.

The geeky joy continues

Moving further down the Develop menu, we have the Snippet Editor. Enter HTML and CSS directly into the top pane of the Snippet Editor window, and the rendered results appear in the bottom pane. This can be useful for testing small snippets of markup without having to edit a Web page, but in practice I find it’s more useful to just go ahead and test within the page proper.

The final six options let you disable various Safari features to aid with debugging. They work like this:

Disable Caches: Temporarily turns off caching, forcing Safari to fetch Web pages, images and other resources from the net each time they’re needed. Great for making sure you’re looking at the most recent version on your server.

Disable Images: Replaces all images in the page with the contents of their ‘alt’ attributes. Good for checking you’ve included ‘alt’ attributes for all your images (as every Web developer should!).

Disable JavaScript: This is exactly the opposite of the Safari > Preferences > Security > Enable JavaScript option. Use it for those times when you want to test how a site behaves with JavaScript turned off.

Disable Runaway JavaScript Timer: Safari features a built-in failsafe timer for those times when your JavaScript runs very slowly or gets itself in an infinite loop. (We’ve all been there.) However it can get in the way occasionally when you’re running certain types of scripts. Turn it off with this option.

Disable Site-specific Hacks: Yucky, but true – Safari apparently contains hacks and workarounds for certain types of Web pages (Apple purists avert your eyes). You can disable such hacks with this option. (Exactly what these hacks are is a mystery.)

The Develop menu in Safari 3 is a powerful beast, and it’s a great way to debug Web pages. I find myself using it quite a bit these days (as well as Firebug in Firefox).

By the way, if you’re after more general info on developing Web pages with Safari, the Apple developer site has a decent Safari Developer FAQ.

Bookmark this post:

This entry was posted
on Thursday, May 22nd, 2008 at 8:20 pm and is filed under Mac tips & tricks, Software, Uncategorized.
You can follow any responses to this entry through the RSS 2.0 feed.
Both comments and pings are currently closed.

I’m guessing the Site specific hacks is actually a good thing. My guess is it’s to fix HTML/CSS issues that make a site behave or look improperly when rendered *according to standards*. Since these sites are likely quite popular, it would potentially kill Safari’s chance at ever being taken as a serious browser if they couldn’t display these common sites properly. (ie. “Safari can’t even render cnn.com properly, forget it!”) I obviously have no idea what sites they are, but you get the idea. So, really, their choices as I see them are:

1) Insist on keeping the standards (not a bad idea), but make some popular (albeit poorly designed/tested sites) look bad.
2) Compromise by breaking Safari’s excellent standards compliance and make it render things in a non-compliance method.
2) Create site specific CSS hacks to get the best of both worlds. Transparently change the CSS (the real source of the problem) to make things look as people would expect, and do not compromise the excellence of your rendering engine.

That is not to say there aren’t some down sides to Option #3, but I would think they are of less concern than #1 and #2.