So, Steve Jobs gives us web developers a double shot today with “One More Thing” of Safari on 3.0 on Windows and a “One Last Thing” of iPhone application development being ‘web standards’ based — just a another HTML, CSS & Ajax application.
While its absolutely great that Apple is embracing web standards in this way — great on many levels not the least of which is that it allows me as a web developer a few new avenues for work opportunities — I’m still left with a bit of a feeling of unease and anxiety.
Why? Though its great that so much can be done with these same technologies I also worry about deployment and having to target so many different specific platforms and manage different versions of the same site. Desktop browsers, WAP browsers, Ajax enhanced mobiles, Wii.. what’s next?
Now don’t jump all over me and tell me that no one is forcing me to create different targeted versions of a site or application or that the iPhone will read a standard web page just fine — I get that. Its just that in reality the need, requirements or desires to tailor user experiences to the given platform or form factor dictate that this can’t always be the case.
So while we’re deploying all the same technologies, we’re still designing, managing multiple interfaces to the applications we’re asked to build.
P.S. Is there a DOM events documentation floating around yet for the iPhone’s touchscreen gesture based interaction?
I’ve gushed here numerous times about the Mozilla / Firefox DOM Inspector tool and how the insights it provides into the way the page is parsed and rendered by Gecko are indispensable when building a web site. What I haven’t spent nearly enough time doing is gushing about similar tools in other browsers—specifically Internet Explorer and Safari.
Safari Web Inspector
Safari, err, WebKit nightly builds have had a DOM Inspector tool of their own since January, Web Inspector, announced in this post. The tool really holds up well to its older counterpart listing node information, all individual and combined style rules, highlighting the active element in the browser window and more. It also has some interesting new features—two shown here—identifying what style properties have been ignored or overridden by another rule and a ‘metrics’ view which shows the box, padding and margin dimensions of any given element.
The only feature I find that I miss from the other tool is the ability to change CSS properties on the fly, but its an easy one to work around.
IE Developer Toolbar
What did I do before this thing? Seriously.
Its kind of a mix between toolbar and inspector with common items like outlines and validation tools, but the key feature is certainly the ‘View DOM’ window. Again, the features are in line with the other available tools, you can walk the DOM tree, inspect properties, change attributes of individual nodes and see important information like ‘hasLayout’ values right along side the CSS properties. But there seems to be one big missing piece that I find getting caught up on regularly when working on complex sites—no view of individual CSS rules, only combined rules—this can make trying to trace values through different style sheets (and sometimes IE only ones) still a bit hit or miss on complex sites.
Don’t let that prevent you from installing it, even without that key-to-me feature it still is a tool that has saved me countless hours since I’ve installed it. You can grab the IE Developer Toolbar here for IE6 and IE7 and read up on it here.
Jon Hicks has taken the idea of client side style sheets to highlight microformats that I implemented in my NNW Extract Microformats tool and ran with it. He’s cleaned up the presentation and made a user style sheet that you can use in most any mac browser—like Camino, Safari and OmniWeb (though the idea works in most other browsers as well). Combine the detection of microformats on the page via these style sheets with some bookmarklets (also provided) and you have a simple system for grabbing hcards or hcalendar events from any web site.
The downside of the client side CSS method is that you’re introducing new styles for microformat content where there may already be styles to highlight the hcards, or where the styles will otherwise clash with what the site’s author has coded. Chris Messina has posted a one example of this on Flickr. And here are two examples from Tantek’s site:
Even when there aren’t bugs, the effects of the style sheet can be gaudy or just feel out of place like in this screen shot of an article on ChunkySoup.net.
But presentational quirks aside, the idea is great and the implementation dirt simple. Its clearly a step in the right direction and another good example of how easy it is to leverage content marked up in these simple HTML based formats.
Because I’ve been so quiet around these parts lately here’s a big ole list of links for the web builder in you!