The WebKit team is picking up on Steve Jobs’s “one more thing” habit, announcing yesterday a new HTML element inspector, built into the latest WebKit nightly downloads.

Play around with it for just a few minutes and your jaw will drop. It’s especially fun to click around the DOM hierarchy and watch as WebKit obscures everything except what you’re inspecting. It makes it dead-simple to cruise around and get the lay of the land on any web page. You can start inspecting at any element on the page by right-clicking and selecting “Inspect Element.”

The inspector’s functionality doesn’t stop at merely poking around the DOM. Click the disclosure button in the lower-left corner to reveal two other nifty tools: Console and Network. Console gives you a nifty little JavaScript interface to the targeted page, which is a lot handier than typing all of your test commands into the URL box with “javascript:” URLs. And the Network tool is sort of a mini-Shark performance tool for the web. It shows you how long it took to load every element on the page, and in what order they were loaded. It even offers advice for performance tuning!

But what’s extra especially shocking and impressive is that this beautiful (no more HUD display!) UI is itself implemented entirely in HTML/CSS. To prove it, just right-click on any item in the inspector window itself, and inspect it!

You can use the inspector to see how the inspector pulls off some pretty impressive tricks to make the plain HTML/CSS look and feel more or less like a desktop app. While I don’t envy anybody trying to replicate the feel of Cocoa in HTML, I am quite impressed with the overall polish and usability of this interface.

Major congratulations are in order to the WebKit team for this amazing update in functionality. The one thing that screams out at me as missing, however, is the ability to edit the CSS for inspected elements directly from the inspector. I’m sure this is a feature many web developers would love to see. It’s something that keeps me running FireFox from time to time, just to accelerate that part of the web design process.

I propose that if some up-and-coming developer was to implement editable CSS for the WebKit element inspector, they would have heaped upon them the praise of many, many Mac developers and web designers. Not to mention the WebKit team itself.

Maybe this is your chance to break into the spotlight?

I just noticed a new section on mmalc’s very helpful “Cocoa Bindings Examples and Hints”:

Observing a Collection

I have personally found this very confusing when I’ve used bindings in my projects. The problem arises when you’ve got application model data stored in some “free” data structure like a dictionary or array. The model data can be manipulated quite handily with standard UI and array controllers, but what about cluing the rest of your application into the change? I find the problem of “bottom-up” observing with deeply nested data models to be one of the hardest problems with bindings, both conceptually and practically.

To me, mmalc’s explanation just confirms what I thought was true: bindings kind of sucks for nested “pure” models. There often must be some custom code associated with your model, or else you’ll have to jump through hoops to observe the changes in the data from some higher altitude.

I’m not sure what Apple should do to make it better, but I hope they do it. Or is my desire to store everything in dictionaries and arrays just a flaw in my thinking? Maybe I’m asking for too much.

Scotty invited Gus Mueller, Guy English, Wil Shipley, and myself on board for a little post-WWDC chat.

If anybody missed the Apple Store CocoaHeads event during WWDC, and wants to catch up on what went down, Steve Weller was kind enough to record the entire thing. The audio files are being hosted by Brian Christensen of Alien Orb Software.

I think the event turned out really well, especially the Q&A session where the audience obliged with many an excellent question.