One of the many challenges of building a usable black theme for Mac OS X is making it work with web pages. If you use Safari, the buttons, scrollbars, and other interface widgets on web pages get their marching orders from the system's graphics files—the same ones that regular applications use.

So, if a web page has a pushbutton, the button will by default take on the style of the active theme. If you're running Crystal Black, this means that the button inherits the Crystal Black style. We like this.

Color for the button's text, on the other hand, gets its marching orders from the browser's default Cascading Style Sheet (CSS) file—which, naturally, makes the text black, and therefore unreadable on top of a black button. We don't like this.

On first glance, the solution seems to merely design a special CSS file for Crystal Black and make Safari use it. And that does work for many web sites and many buttons. However, many folks who design web pages like to fiddle with the CSS style for their pages' buttons, and such fiddling means that there's nothing "mere" about designer a Crystal Black style sheet.

Further, many Mac applications these days have views that are simply embedded web content using Apple's WebKit framework. The practical implication here is that Mac apps don't know how to read a Crystal Black CSS file, so Crystal Black must do some fiddling under the hood to avoid having unreadable buttons in such web views.

Then there's Safari itself. I really wanted to theme the Web Inspector—the incredibly useful built-in website viewer/debugger/designer assistant—with the Crystal Black look and feel, but it wasn't immediately obvious how to do this. I assumed that the tool was just a part of Safari, and therefore built with classes and widgets from the Cocoa AppKit (which is the framework all Cocoa apps are built with). However, when I began to inspect the Inspector, I discovered that everything contained within its borders was simply web content: HTML, CSS, JavaScript, and images.

In other words, the Web Inspector tool is nothing but an intricate, sophisticated, and extremely well designed web page!

Having built a Crystal Black CSS file for web pages in general, and with my past expertise in CSS, I attacked this challenge with relish! It reminded me of the time I realized that Dashboard widgets are, at their core, nothing but little web pages (as are simply apps for the iPhone). In tackling this one, the main question was, How should the various elements look? And the hardest part was inspecting the various parts in of the Inspector in great detail to determine which CSS rules governed their default appearance and behavior.

As I discovered, the WebKit has a a sub-framework called "WebCore," which in turn has a folder of resources specifically for the Web Inspector. In the Inspector folder, among other things, is a suite of CSS files that handle different aspects of the Inspector's design and behavior. Of these, the primary one I needed to tweak was called simply "inspector.css."

Besides controlling the usual attributes of a web page—document elements, text elements, image elements, layout elements, form elements, and so on—this style sheet applies various advanced CSS properties that serve the purpose that in years past would have been handled by many individual images. As I've described this CSS 3.0 magic previously, there's no longer a need for using graphics and JavaScript to add box shadows, rounded box corners, borders, gradients, and reflections to your web pages.

Naturally, since the open-source WebKit project was initiated by Apple, and since that project zoomed ahead of all other browser engines in developing new ways to design with CSS, that's how the Web Inspector is built. This approach—using a command syntax rather than images to design a user interface—is one that Apple has been adopting for its desktop applications. In recent years, Apple has been adding new classes and methods to the AppKit that make it a trivial matter to build a window frame, a border, a toolbar, or a button using code rather than individual graphics. 

While this is a logical and efficient approach, it also presents challenges for theming Mac applications, a challenge that Crystal Black is often unable or unwilling to overcome. (The story of all the challenges in building Crystal Black are described in this article.)

Not so with the Web Inspector, fortunately.

The Inspector does use a few images in its design, but most of the toolbar, separators, and section headers are built with CSS gradients. Very cool indeed!

This bit of Crystal Black will eventually be bundled with the whole theme, but for now I offer it as a free download. Admittedly, the audience for such software is small—you have to like Crystal Black, and you have to be a regular user of the Web Inspector—but it might be of interest to others who are curious about how such things are done.

One caveat in viewing the screenshots... The scrollbars that appear, as well as the HUD window style, are part of the overall Crystal Black theme and are not part of the Web Inspector theme itself.

Enjoy!

Update 4/18/11: The full Crystal Black 1.0 theme is now available from the Crystal Black website.

Installing Crystal Black for Web Inspector

The download contains a small application that you can use to install—and to uninstall—the theme. Simply double-click and select "Install" to apply the theme. Or select "Uninstall" to restore the default CSS files and graphics.

After installing or uninstalling the theme, you'll need to quit and restart Safari for the theme to take effect.

Crystal Black for the Web Inspector (Download file is 1.0MB)

Surfin’ Safari - Blog Archive » Styling Scrollbars. I've been so busy I missed this... it's another in the WebKit team's aggressive expansion of the possibilities for user interface development using the basic stuff: HTML, CSS, and JavaScript. The brief article on the Surfin' Safari blog has a pointer to an interactive demo.

Surfin’ Safari » Web Inspector Redesign

For my money, Safari's Web Inspector has been a strong rival to the excellent Firebug that Firefox deveopers use. Its capabilities and usability have been growing by leaps and bounds since it was first introduced in January 2006.

I wrote a brief article on the enhancements that came in August 2006, and since then the improvements have just kept coming:

1. June 2007, total redesign with beaucoup added features.
2. December 2007, adding inline CSS editing, a database browser, downloadable fonts, several CSS properties, and more.
3. September 2008, redesigned interface and way too many terrific features to list here. Go read the WebKit blog article for details.

At this point, I don't think there's any question among those of us who've used both Firebug and Web Inspector that the bar has now been raised far beyond what's available to Firefox developers.

Note: At this time, the new web inspector--like the hugely faster Squirrelfish JavaScript engine--is only available in the nightly WebKit builds. But that doesn't mean you can't use it in place of Safari!

Tom Yager: Developers should skip Google's Chrome, and jump straight to WebKit

Of course, I completely agree with Yager, but I'm delighted to see a nationally prominent technology analyst come out with this opinion. I can't try Chrome yet because it's not available for Mac OS X (that's strike one against it!), and besides, Chrome uses the WebKit engine under its hood.

The latest builds of WebKit, and in preview builds of Safari 4, provide developers with the richest set of tools for building advanced Web 2.0 applications yet. Sadly, most tech writers are totally oblivious to this, even some who use Macs. Firefox is still the new and most politically correct kid in town, despite the fact that WebKit is just as open source but has a much faster-moving and forward-thinking engineering team.

Consumer Reports urges Mac users to dump Safari, cites lack of phishing protection

And to think I used to like Consumer Reports!

They keep writing me to "come back" and resubscribe, but I've told them that won't happen until they become objective and truly knowledgeable about the Mac... at least as knowledgeable as they are about Windows PCs.

And now, it turns out they're recommending that Mac users "dump Safari," which just happens to be the best web browser on the Mac platform. Oh, and since this article also appears on ZDNet, while other industry journals gave it little play, I begin to conclude that ZDNet is a rats nest of Microsoft zealots.

So, here's the little note I left them today about their latest phishing/Safari scare tactic:

There is nothing in common between phishing and viruses, adware, spyware, or other malware. Phishing is just an old-fashioned scam dressed up in new HTML clothing. Consumers need to be educated about it, and no anti-phishing technology is going to save them. For one thing, most phishing schemes come to consumers through their email client, not their browsers.

Oh, and 6 or 7 years ago, why didn't Consumer Reports advise Windows users to ditch IE? That would have been the single best way for them to avoid Internet malware, but I never heard them do such a thing. The phishing problem pales in comparison to the security nightmares we experienced after IE6 was released (and before SP2), and which millions of Windows users continue to experience today. Active/X is the most dangerous technology out there as far as security is concerned, but is MS being pressured to remove it from IE?

Unfortunately, I don't think we've heard the last of this... At least, until Apple goes ahead and joins the other browsers in adding "anti-phishing technology" to Safari. Like I noted above, it really makes a lot more sense to add this capability to users' mail clients, since phishing is just a form of junk mail in the end.

ZDNet: iPhone vulnerable to phishing, spamming flaws

There has lately been a rash of articles about how "insecure" Safari is because it has no anti-phishing mechanism. Frankly, I think this is a bunch of hogwash. It's an attempt to show how lax Apple is about security, and, by implication, how great Microsoft is.

It's not that I don't think phishing is a serious problem... I do! It's just that phishing is not a security issue, which is how the anti-Apple, pro-Microsoft (and pro-Firefox) zealots are trying to portray it.

Here's the comment I left on ZDNet's site about this article, dated 7/23/08:

Phishing scams are very bad, but they are not the same as viruses or malware that gets installed on your operating system. Not even in the same category. They are simply a sophisticated con, and unfortunately there are a lot of naive, clueless web users who will click on any link they're offered. Then again, I know people who are so paranoid they won't click on any link in an email at all... even if it comes from a trusted source (like a friend). I'm not at all convinced that anti-phishing software will work any better than junk-mail filters have, though I understand the need to try.

All you guys who are so hot to jump on Apple need to at least know what you're talking about. Though the companies who make money on security vulnerabilities like to lump phishing in with "security" flaws, in my opinion they aren't. Why? Because they pose no threat to the integrity of your computer or to your network.

Later, in reply to a reader who thought I was kidding with this opinion, I wrote:

Of course it's bothersome... on the same plane as the scum who trick old ladies out of their social security checks by conning them into some phony investment.

Phishing is more insidious, but if you have an ounce of common sense, it's easily avoided.

Not so with viruses and spyware, which can invade your system without any action on your part... not even clicking on a link. If following a link loads a virus, that's not phishing, defined as [blockquote] the activity of defrauding an online account holder of financial information by posing as a legitimate company[/blockquote].

My point is, phishing is not so much a security liability as it is a privacy issue... Phishing amounts to identity theft.

I'm not arguing that phishing isn't a serious concern that needs to be addressed. But I'm saying it's not a security issues in that it doesn't install software on your system, invade your network, or propagate itself to others.

I am arguing that it's more like spam, which is likewise a serious problem that can lead individuals to dangerous websites or tempt them into bad decisions. Like spam, I'm doubtful that any software solution to eradicate phishing is possible.

In this light, the urgency to correct a phishing vulnerability is much lower than that to correct a security vulnerability, and the fact that such a vulnerability exists should not alarm users to the same degree.

Turns out this "phishing" scam isn't over with the iPhone or Safari. See more of my ranting in Part 2 of this topic.

My, we've come a long way in browser choices since 2005, haven't we? It's been a very heady time for programmers who dabble in the lingua franca of the World Wide Web: HTML, JavaScript, Cascading Style Sheets, the Document Object Model, and XML/XSLT. Together, this collection of scripting tools, boosted by a technique with the letter-soup name "XMLHttpRequest," became known as "Ajax." Ajax spawned an avalanche of cool, useful, and powerful new web applications that are today beginning to successfully challenge traditional computer-desktop software like Microsoft Word and Excel. As good as vanguard products like Goodle's Maps, Gmail, Documents, and Calendar apps are, one only has to peek at what Apple has accomplished with its new MobileMe web apps to see how much like desktop applications web software can be in 2008.

That this overwhelming trend toward advanced, desktop-like applications has happened at all is the result of the efforts of determined developers from the Mozilla project, which rose from the ashes of Netscape's demise to create the small, light, powerful and popular Firefox browser. The activity of the Mozilla group spurred innovation from other browser makers and eventually forced a trend towards open standards that made the emergence of Ajax possible.

This article starts with a brief history of web browsers and then jumps into a look at the feature set of the four primary "modern" web browsers in 2008. The comparison of browser features begins by listing the core features that all these browsers have in common. The bulk of the article lists in detail "special features" of each browser and each browser's good and bad points, as they relate to the core browser characteristics. Following that, I present some recent data on the comparative performance of these browsers. The article concludes with recommendations I would make to organizations interested in making the switch from IE6 in 2008.

1. Web Browsers in 2008: A Brief History
2. Comparison of Browser Features
• Baseline Features
• Firefox 3.0
• Internet Explorer 7.0
• Opera 9.5
• Safari 3.1
3. Browser Performance
4. Conclusions
5. Bookmarks for Further Reading

Web Browsers in 2008: A Brief History

Comparison of Browser Features

Browser Performance

Conclusions

Bookmarks for Further Reading

SproutCore is Apple's Flash, Silverlight-killer - Mac software - Macworld UK Sproutcore is a new Ajax/JavaScript framework being developed as an outgrowth of Apple's new MobileMe product. It's also part of the ongoing rapid development of the iPhone development platform and the WebKit browser engine that forms the basis for Safari. To call it a "Flash killer" is perhaps a bit overstating the case, but judging from the demos on the Sproutcore website, it appears to be on its way to being a robust rival to more mature frameworks such as Ext.js. I've installed Sproutcore and look forward to playing around with it soon.

Why 'no Macs' is no longer a defensible IT strategy | InfoWorld | Analysis | 2008-04-21 | By Galen Gruman This article is a must-read for anyone who cares about the longstanding problem of getting enterprise IT staff to support Macs. If you can get them to read the article, published by a major and highly respected IT trade journal, you may change a few minds. The author runs down all of the issues that kept Macs out of the enterprise in the past, and effectively addresses the concerns, some of which have been outdated since the release of Mac OS X.

My only quibble is the author's assertion that enteprise reliance on Microsoft Office means unequal time for Macs. He points out that OpenOffice is a viable alternative but makes no mention of Apple's own terrific iWork suite, which is quite compatible with the basic aspects of Microsoft Office. Likewise, he fails to acknowledge Apple's effective collaboration suite in the form of iCal, Mail, iChat, and Address Book. Perhaps it's because those aren't cross-platform. However, even if that's the case, since they are able to interoperate with Office, they should be considered by businesses seeking to support their growing numbers of Mac users.

A lot has happened in the world of web browsers and CSS 3.0 since I wrote this article last summer at the time Safari 3.0 became available as a public beta. Besides WebKit/Safari, Opera, iCab, Konqueror, and Firefox have all made progress in adopting CSS 3.0 specifications, the next generation of the W3C's Cascading Style Sheets standard.

However, the WebKit team continues to lead the pack, as they have since I first contemplated this article over a year ago. In the last 6 months, that team has not only adopted more of the CSS 3.0 specs ahead of the others, but they have proposed several exciting new specs of their own, which the W3C is taking up as draft recommendations.

In addition to updating the state of CSS 3.0 in WebKit/Safari, I've also added some new demos for the Backgrounds section of my CSS playground at the end of the article.

Here are the CSS 3.0 features I wrote about in July 2007:

1. Box-shadow: Yes! Add drop shadows through CSS!
2. Multi-column layout: Can we really do this now? With HTML?
3. Resize: Give JavaScript hacks a rest and let users relax when typing input on web pages.
4. Rounded corners: The corners of any
   element can be made round to any radius you specify.
5. Colors with transparency: There goes another ugly hack from way back!
6. Background image controls: Remember how great it was when you could add images as well as colors to an element's background CSS style? Well, it's about to get a whole lot better!

And since then, WebKit and Safari 3.1 have adopted the following bleeding-edge CSS features:

1. Adopted last October, WebKit introduced its first take at CSS Transforms, which it has submitted to the W3C for consideration. With CSS Transforms,
   s can be scaled, rotated, skewed and translated... all without using JavaScript!
2. Announced at the same time is the equally exciting implementation of CSS Animations. At the moment, the only type of animation that's documented and demonstrated on the WebKit blog is based on CSS Transitions, which let you define how an object or attribute changes over time from one state to another. Using this specification, you can now program many kinds of animations with CSS alone.
3. Also in October, WebKit added the CSS Web Fonts feature, which lets designers beam fonts to users through CSS and HTML, approximating the capabilities of PDF in a much lighter-weight form.
4. Then, after a lull, things started to heat up again last month, when Apple released Safari 3.1. Safari 3.1 incorporated all of the CSS 3.0 features WebKit had pioneered earlier, plus it added a bunch of things the WebKit team hadn't blogged about. Chief among these was support for CSS Attribute Selectors. This is something of a holy grail to advanced web developers, since it opens up a whole world of possibilities for using the Document Object Model (DOM) to build better web interfaces. When released, WebKit was the first and only browser to fully support this geeky, but highly practical feature. (Some of the other browsers have implemented partial support.)
5. And then, just today, WebKit added support for CSS Gradients to its portfolio. Gradients are not yet a CSS 3.0 specification, but they are part of the HTML 5.0 spec. No doubt Apple's implementation will be referred to the W3C for consideration. (This is the only new feature in this list that as yet works only in the latest WebKit nightly build.)

This article lists the CSS 3.0 features that were first available in Safari or the nightly WebKit browser. Besides listing them, I've tried to keep up with what the features can actually do for me as a web designer, so each feature is accompanied by a demo or two and some explanatory notes. Since some of the features are a bit complex, and almost totally lacking in documentation from either W3C (which only lists the standards, not the implementation details), Apple, or the WebKit team, I've had to experiment to discover what some of the attributes do.

Fortunately, a forward-thinking group of techno-weenies is keeping a close eye on the emerging details of the CSS 3.0 implementations, and they have done some experimenting of their own. Since they're in the same boat I am (actually, they have a much better boat!), it's not surprising that I'm finding ambiguities in the way they've built some of their demos. Still, it's the closest thing to documentation that I've found, and I highly recommend that anyone interested in learning more about CSS 3.0 pay a visit to the terrific CSS3.info website. In fact, you'll find links to their pages throughout this site.

Following CSS3.info's lead, I'm organizing the (at this time) CSS 3.0 available in Safari into four categories: Borders, Background, Effects, and User Interface. These correspond to the W3C draft modules for CSS 3.0. The fifth tab in the navigation control below gathers the CSS 3.0 specifications that have been implemented by Safari and at least one other major browser. As you browse through these up-and-coming features, I think you'll understand my excitement about the benefits they offer to web graphic- and user-interface designers.

In the first release of this article, I only had demos for the section on Borders. Today I've added demos for CSS Backgrounds, and I plan to continue experimenting with the rest as time permits. In the meantime, as mentioned before, do pay a visit to CSS3.info for their demos of each, or follow the links to demos at the WebKit site. I hope you're inspired to take up a keyboard and pound out some experiments of your own!

Gone in 2 minutes: Mac gets hacked first in contest The fact remains that neither I nor any other Mac user has ever had our machine infected with a virus, a worm, or any of the numerous forms of malware that Windows users have suffered from since 2001, when Mac OS X was released. The single biggest risks users have faced online during this period are (a) running Windows XP, (b) running Internet Explorer, and (c) running Microsoft email software. Why? Microsoft has called it various things over the years, but I know it best as Active/X. Microsoft argued in the aborted antitrust trial that tying IE tightly to the OS was in the best interests of consumers. Right. It certainly has been good for IT security firms. Heck, this gave rise to an entire industry that would never have existed without Microsoft's highly vulnerable system, and it made consumers and businesses spend billions of dollars on antivirus/antimalware software to combat the problem. Plus it created a generation of people who are afraid to use the web to the fullest, and who are neurotically suspicious of hyperlinks in emails... even when they come from people they know and trust.

Even if you believe these things would have happened if Apple's OS held the monopoly (which is a demonstrably false opinion), the burden of computer security has fallen exclusively on Windows users over the last 7 years. Exclusively... not just 90-95% of the burden. I have never spent a dime on security software or subscriptions, nor have I spent a moment worrying about going online. I've never had my machine hijacked by malware, or had my browser go haywire because I visited the "wrong" website. I take sensible precautions about suspicious emails, and I don't download files from suspicious websites.

If someone has developed a true exploit for hacking Mac OS X, I'm sure it'll be quickly squashed by Apple. And one or two such exploits in 7 years is a far more intelligent risk than dealing with thousands of such exploits a year over that period, don't you think?

Apple - Support - Downloads - Safari 3.1

This update brings in all the latest standards implementations and innovations in the open-source WebKit project, plus a few interface enhancements as well. The Windows version gets some important updates too. From Apple’s tech document on Safari 3.1:

Performance

• Improves JavaScript performance

Standards

• Adds support for CSS 3 web fonts
• Adds support for CSS transforms and transitions
• Adds support for HTML 5 <video> and <audio> elements
• Adds support for offline storage for Web applications in SQL databases
• Adds support for SVG images in <img> elements and CSS images
• Adds support for SVG advanced text 

Developer

• Adds option in Safari preferences to turn on the new Develop menu which contains various web development features
• Allows access to Web Inspector
• Allows access to Network Timeline
• Allows editing CSS in the Web Inspector 
• Allows custom user agent string
• Improves snippet editor

Other

• Double clicking on the Tab Bar opens new tab
• Includes URL metadata when images are dragged or saved from browser
• Opens Download and Activity window in current Space
• Supports trackpad gestures for back, forward, and magnify on MacBook Air and compatible MacBook Pro computers
• Shows Caps Lock icon in password fields

Surfin’ Safari In case you missed it (I've been so busy that I did!), be sure to check out the WebKit team's writeup of their pick of the 10 best new features of Safari 3.0 (which has WebKit 3.0 running at its core). My nomination goes to the absolutely incredible upgrade to WebInspector and Drosera, the two tools for web developers that have been included in WebKit since early this year. WebInspector is the best tool out there now for analyzing the makeup, structure, content, and interactivity for any web page you encounter or are building. Drosera is the sidekick JavaScript inspector. But as you'll see from reading the WebKit team's blog, the goodness in Safari 3.0 doesn't stop there! According to the blog, most of the features described are also available in the upgraded Safari 3.0 browser included in the new Tiger upgrade, OS X 10.4.11.

By the way, before any defensive Firebug fans (I love Firebug, too, by the way) start a reflexive reply, you should know that in a recent podcast for Ajaxian, Firebug developer Joe Hewitt made clear he's now working on iPhone development and has been won over by WebKit from Firefox. He now thinks WebKit/Safari is the best platform for web development out there. I'd say his opinion is pretty significant! I see he's also built an early version of Firebug for the iPhone.

Demeter This is certainly welcome news! I've been disappointed at the very slow pace of development on the core Shiira project, and Demeter appears to be a fast-growing branch of that project. Like Shiira, it's open source, and also based on the latest (Safari 3.0) WebKit code. Definitely worth a look-see!

Apple - Safari 3 Public Beta - Download I'm still going through all the news from today's blockbuster announcements at the Apple developer's conference, but this one has blown me away the most so far: Apple has made available a beta release of Safari 3.0 (which is awesome, let me tell you, as a Leopard developer), which contains all the amazing advances I've been reporting on since last fall. Not only that, but when I went to the download page, I couldn't believe my eyes... there are Windows downloads as well! Yep, that's right! One of web developers' biggest complaints about Safari is that it's not available for Windows... now, it is! This is incredible.

Shiira Project

The Shiira Project has at long last launched version 2.0 of their alternative-Safari browser. Ever since the first beta last summer, Mac tech writers in the know (me included) have been extolling its virtues, waiting anxiously for a version with all of its features intact. Although the 2.0 version released today still has a few small screws loose, I could easily write a whole new article describing some of its cool new features and the polish its put on the ones revealed in beta. Chief among the new features I love are

• The full-screen mode, which comes with a mouse-activated menu at the top of the screen that lets you navigate to other websites, change font size, and other basics.
• The final look and feel of the new HUD-style panels is awesome, although the “action gear” icon at the bottom of each is still out of comission.
• The RSS reader tool, which could still use some polish but has some nice alternative features not found in Safari.
• The final configuration and content of the Page Info window is tops in its class! You’ll find that the “links” pane now neatly and powerfully ties each item in its list to the actual page, so as you select a link, the page scrolls to that point. If the link has an image, the image is shown in the information pane below, along with the full HTML of the link–including any javascript. Awesome! I also highly approve of the way the image browser pane turned out. The DOM browser is pretty basic, and I would highly encourage the Shiira folks to figure out how to integrate WebKit’s page inspector into Shiira—it likewise is the best around (well, neck and neck with Firebug for Firefox).
• The PageDock is even better than originally, and Shiira still has the very best “Tabs Expose” feature of any browser around.
• The Shiira folks have wisely updated some of the underlying WebKit components, as a result of which Shiira now speaks “ContentEditable” like 95% of the other browsers in use. (See my recent article on this topic if you don’t know why that’s important to Mac users.)

I’m going to try running Shiira instead of WebKit for a day or two. At the moment, my chief gripes from very limited use (since last night) are that

• Shiira doesn’t integrate with Inquisitor, the awesome Cocoa search plugin for Safari,
• Shiira doesn’t have a built-in JavaScript debug tool or a DOM/CSS inspector like WebKit does,
• Shiira hasn’t incorporated WebKit’s CSS3 support bits. As a result, it can’t do things like rounded corners, drop shadows, multicolumn text, and the rest. (See this CSS3 Preview site to check them out.) The main CSS3 feature I use daily is resizable textareas… indispensible if you’re trying to get text entry work done in a browser.
• The browser’s feedback showing it’s loading the page is a bit weak… It relies on the PageDock icon “filling with water”, but if the icon is quite small, it’s hard to notice. I prefer Safari’s use of the address bar for this.

In any case, I’m glad to see Shiira returning back to life as a truly excellent, native Cocoa alternative WebKit-based browser for Mac OS X.

Ajaxian » Performance test results show strong WebKit outcome Ajaxian posted a nice report on a distributed study of the relative browser performance on Dojo's charting system yesterday, and immediately the naysayers started naysaying. "Safari is a piece of crap. WebKit is so buggy..." and the like. I suppose if WebKit keeps coming up at the top of the heap on these kinds of tests, eventually Safari/WebKit will earn more respect, but probably not until a lot of the bozos who are so critical actually buy themselves a Mac. By the way, the test is strictly speaking a measure of relative performance at rendering SVG code, not overall browser speed or javascript parsing. (Although WebKit excels at those, too.)

Adobe launches Apollo, its web application runtime for the desktop I was too busy last week to report this in a timely manner, but it's potentially big news: Last October, Adobe announced that it would use Apple's open-source WebKit code (on which Safari is based) for a new web application runtime for desktop software, and it's now fulfilled that promise. Apollo can be downloaded in first-release alpha form from Adobe's Labs website, and there's one example application built on the platform that you can also try. Apollo installs as a framework on Mac OS X, and it's also available for Windows. Adobe intends Apollo to be a framework for building web-based applications for the desktop, and I don't know too much more at the moment, but do intend to find out. It sure seems odd to peer into the Apollo framework folder and find the WebCore and JavaScriptCore frameworks, which are the heart of WebKit itself!

A quiet revolution has taken place for Mac OS X Safari users, but I haven’t seen anyone celebrate it… and I’ve looked! There isn’t even a mention of this dramatic change in Safari’s powers on the Surfin’ Safari blog, where the open source team that’s evolving the WebKit rendering engine used in Safari announce new features and updates. Lately, this team has implemented a number of really amazing features from the CSS 3.0 specification, and each has been trumpeted with some eye-popping examples. But not a word about this.

Well, I for one am celebrating the upgrade with this article and proclaiming to the world that finally, at last, Safari is gaining parity with the other modern browsers in letting users perform WYSIWYG editing whenever the application calls for it. Mac users like me who have simply done without rich-text editing in their WordPress blogs and Gmails, bristling with an unfamiliar envy at the vast majority of users who take this functionality for granted by now, can finally save ourselves some typing and edit in our web browser with the same ease we do in a word processor.

A Little Browser History

Since its debut in June 2003, Apple’s Safari web browser has had a hard time gaining respect among web developers. This has a little to do with its Mac OS X platform restriction, but it’s mostly because of incompatibilities in its underlying rendering engine that have taken its developers a long time to correct.

From the beginning, Safari was incompatible with a fairly large number of websites, but most of this was because those websites were poorly designed to work only in Microsoft’s Internet Explorer browser. Apple encouraged its users to report bugs, through use of a convenient toolbar button in Safari, and I’m sure its developers’ energy was consumed with bug fixes for the first year of its life—when they weren’t implementing novel functionality like a built-in RSS reader.

After Firefox 1.0 was released in November 2004, interest in that browser slowly began to turn the minds of developers away from pure IE compatibility to a more cross-browser mindset based on open standards. Thus, in 2005-06, Firefox began to eat significantly into IE’s market share, to the point that no one could ignore Gecko compatibility anymore. Most Windows-based developers are surprised to learn that the share of Safari also rose dramatically during that time (from 1.5% to 4.5%), though remaining at a much lower level than Firefox (which rose from less than 4% to more than 13%). In mid-2005, Apple open-sourced WebKit, the core rendering engine used by Safari, and since then, interest in—and respect for—Safari has steadily increased. (Note to those who know… the underlying HTML rendering engine in Safari is actually called “WebCore”, but it’s a distinction that would simply confuse this history and provides no useful information. If you want to learn more, here’s a nice, brief summary on the Apple developer website.)

Part of that newfound respect is due to the WebKit team’s vigorous pursuit of web-standards compliance, and this improved compliance with standards dovetailed perfectly with the shift away from developers’ reliance on IE’s non- and sub-standard implementations of CSS and JavaScript. Thus, by the time Ajax became a buzzword in 2006, consensus in the web developer community was strongly aligned with adherence to standards, and Safari was by then just as standards-compliant as the Mozilla browsers and Opera… and in some cases more so. (Safari was the first browser to pass the Web Standards Project’s Acid2 test in 2005.)

Safari Remains “contentUnEditable”

And yet, many developers continued to grumble about problems dealing with Safari in discussion forums and blogs. When pressed for the reason, it nearly always boiled down to one of two things:

1. The developer hadn’t worked with Safari in at least a year, or
2. The developer was frustrated at not being able to deploy a web-based rich text editor that would work in Safari.

As far as number 2 is concerned, you can count me among the developers who’ve had that little problem. I’ve worked on development teams to build several Intranet systems for web content management over the years, and early on, we just had to give up on Mac users. Ironically, the scripting functionality that lets a developer make any element of a web page editable with WYSIWYG editing controls originated with Internet Explorer, beginning in 1999. After a fair amount of public nose-holding, the Mozilla team incorporated the Microsoft specification into its browsers fairly early on, and most projects developing rich-text editors for browsers were able to achieve Mozilla compatibility several years ago.

Yet still Safari lumbered on with little or no acknowledgment of the admittedly non-standard (but still vital) “contentEditable” property. And so the browser continued to receive scorn, even as it was leading the browser pack in other areas of standards compliance and functionality. It’s true that Apple incorporated what turned out to be very buggy support for contentEditable in Safari in late 2004, starting with Mac OS X 10.3.9. But this implementation was apparently so unreliable that it probably just angered developers who tried to use it more than it impressed anyone. (To find out just how angry, try Googling the phrase “Safari contentEditable” some time…) Fortunately, the new implementation appears to me as a user to be the real thing!

The Wait Is Over!

So it was with a great deal of surprise and delight that I awoke one morning a couple of weeks ago and realized that the long wait was finally over! On one of the Apple rumors websites, I read that a key feature of the latest beta release of Mac OS X 10.5 (”Leopard”), is support for rich-text editing in Safari 3.0 that’s fully compatible with the “ContentEditable” specification.

But that isn’t the really exciting part for me personally. Since Safari 3.0 is simply incorporating the latest build of WebKit, I surmised that WebKit itself was probably now capable of handling standard rich-text-editing duties on the web. Perhaps all of those sites that couldn’t be made Safari compliant because Safari didn’t properly handle ContentEditable might now be opened to me without reaching for Firefox, Camino, or Opera!

At first I assumed that I’d have to turn on some silent default in WebKit to make this happen, as I did with the resize-textarea CSS 3.0 feature. Not the case. The latest WebKit nightly build can handle WYSIWYG editing with nothing more than a download.

Well, that’s not completely true, but only because many websites and WYSIWYG editing tools are hard-coded to not let Safari or WebKit use their tools. But nearly all of these can be “spoofed” into thinking WebKit is IE 6.0 or Firefox, and will then open their toolbox for me to use. About the same number of sites are built correctly—that is, to identify whether a given web client recognizes a given DOM property, rather than merely asking for its name and number—and would let me edit content with no spoofing at all. Among the badly coded pages is WordPress’ administration area (at least through version 1.5), and among the well coded sites is Google’s Gmail.

Not Something To Brag About . . .

For Mac users, this is huge news. We like to think our platform is the best there is, and that Apple is way out in front on new technologies and usability standards. But in this case, the Mac has been way behind for a long time, and it will be very pleasant to put this behind us.

I first started researching WYSIWYG editing tools in late 1999, and even though Safari and Mac OS X didn’t even exist then, finding WYSIWYG editing tools that would work on the Mac has been an ongoing struggle and source of embarrassment.

How could Apple have ignored such core functionality for so long? That’s a rhetorical question, but it’s a clear demonstration of the fact that Steve Jobs and the brilliant folks at Apple aren’t flawless by any means. I think I was on the early side of recognizing the key value to web-based content management of letting end users edit content using tools that mirrored what they were used to in a word processor. It was clear to me that if you want to spread use of the browser in an organization as a tool for managing content on your website or in a database, you have to give them something more than a course in HTML and a good book.

Given their druthers, they would return to Microsoft Word every time to do their editing. And why not? Why should a nontechnical user struggle to piece together an HTML table for her data, or be forced to type code to tease a bullet list out of her content, when this problem had already been solved in the computer interface? Of course, they shouldn’t, and support for WYSIWYG editing in the browser clearly had no champion at Apple for a long time.

The only other end-user technology that Apple, unfortunately, remains way behind the curve on is video screen capture. I hope someone there realizes that static screenshots no longer suffice for many purposes, and that the screencast is a tool of immense strategic importance for marketing and education uses in the 2007 World Wide Web. Yet Mac users still don’t have a free tool for simple video capture, as Windows users do. But the purpose of this article isn’t to grouse, so I’m not going to grouse further on this subject here.

Some Evidence for the Skeptics

For those of you who simply aren’t happy unless you can see what I’m talking about, as well as those who require physical (or at least visual) evidence of what I’m saying here, I’m providing a few screenshots that you can peruse at your leisure.

For the web developers out there who have built websites that shut Safari users out by name and number, now is the time to fix your site so that it asks the browser whether it understands the ContentEditable property. This will let folks like me who are using the nightly WebKit in, and will let the hordes who upgrade to Leopard see what they’ve been missing once Apple releases it. It will also let users of the WebKit-based shareware browser OmniWeb enjoy the new trick. OmniWeb incorporates WebKit code faster than Safari in most cases… or at least, on a different schedule… and the latest release supports WYSIWYG editing just as WebKit does. OmniWeb is the only WebKit-based browser I could find that does, however… the rest appear to use the core built in to Mac OS X 10.4 (”Tiger”).

For Mac OS X web users who’d like to start using Writely, Google Spreadsheets, and WYSIWYG editing in tools like WordPress and Gmail while staying in Safari or OmniWeb, by all means download the nightly WebKit browser or the latest OmniWeb release and start living life a little more fully!

From the Genii Software’s comprehensive list of web-based WYSIWYG editors, which they have been maintaining in recent years after “the list” started at the University of Bristol, I quickly tested the following tools which had online demos and were listed as supporting IE and Firefox but not Safari. Here’s a summary of the results when testing with WebKit (latest nightly build):

Free or Open Source:

• ConceptRTE. Worked when spoofed as IE 6.0.
• Cross-Browser Rich Text Editor (RTE). Worked fine without spoofing.
• FCKeditor. Couldn’t spoof.
• CMSimple. Worked fine without spoofing.
• TinyMCE. Worked fine without spoofing.
• Through The Web Rich Text (WYSIWYG) Editor. Worked fine without spoofing.
• whizzywig editor. Worked fine without spoofing.
• Xinha. Couldn’t spoof.

Commercial:

• Ektron eWebWP. Worked when spoofed as IE 6.0
• Rad Editor for ASP.Net. Worked fine without spoofing.
• WYSIWYG PRO. Couldn’t spoof with a recent enough client, but it’s clearly spoofable based on what happened when I spoofed as IE 6.0.

Web Kit DOM: Main Page This site is much deeper than it appears at first... in fact, the home page gives you no indication there's anything much at all. But start clicking the tabs: Namespaces, Classes, and Files, and you'll find yourself wandering through a Doxygen-created maze of documentation that tells you everything you ever wanted to know about how to make WebKit tick. Oddly, I haven't seen an announcement about this on the WebKit blog... of course, this is only version 0.1, so maybe they don't consider it "ready for prime time." But honestly, developers will froth at the mouth to get at info like this.

Surfin’ Safari - Blog Archive » CSS3 Multi-Column Support Storming right ahead, the WebKit team has now added support for CSS 3.0-specified multiple columns in the nightly builds. I gather that the Mozilla team has done something similar, although one of the commenters here declares that WebKit's implementation is superior. Being able to set text in multiple columns really enhances the page layout capabilities of web content. If we'd had this from the beginning, we never would have gone to table-based layouts! I can't wait to start using this one...

Surfin’ Safari - Blog Archive » Box Shadow Wow... this will save designers so much time! If you stop to think about the hours spent crafting decent-looking drop-shadows for boxes and the like... well, let's just hope this spreads to other browsers soon! And yes, this is already a CSS3 standard... it's just not something we've gotten used to using yet. I don't know if other browsers support it or not, but I know I'm gonna start using it as soon as Safari 3.0 is released!

Surfin’ Safari - Blog Archive » Introducing Text-Stroke Well this is certainly a useful addition to the type designer's bag of tricks when developing a web site design. I'm sure it'll be abused, but only after it's ported to Windows and all the PowerPoint-design hordes get hold of it. Now that the WebKit team's made this code available, it suddenly seems so obvious, I wonder why the designers of CSS 3.0 didn't think of it? Oh well, you can't think of everything, can you?

Creammonkey: Free Input Manager for Safari runs Javascript extensions

Originally downloaded 2/20/06. Many Safari users have gazed with envy at the plethora of add-ons for Firefox, though in the final analysis there are only 3 or 4 that I really wish would come to Safari. One was Greasemonkey… and now we have Creammonkey, which will try to fill those shoes… Worth a try!

Update 10/29/06. Well, eight months after launch, there are still only a tiny handful of scripts that work with Creammonkey. I’m going to watch it awhile longer, but if the usefulness quotient doesn’t go up soon, I’ll pack Creammonkey in. Now that SafariScript is available—with a lot more scripts behind it—Creammonkey may not make it anyway. The fatal flaw seems to be its lack of compatibility with the hundreds of Greasemonkey scripts that already exist. That’s probably not the developer’s fault, but it may doom the effort in the end.

p:OK, even though Creammonkey still isn’t anywhere near as useful for Safari as Greasemonkey is for Firefox, I’ve found at least two scripts that make me want to keep it around. The first one I stumbled on quite by accident… it’s a cool little script called Greased Lightbox, which adds the popular “lightbox” effect to any image you link to from the page. The site designer doesn’t need to do anything but add links to an image… which is quite typical on sites that show thumbnails with links to larger versions. The script’s page has some sample images you can test it with, and also suggests that Google’s image search is a good place to use it. Personally, I’ve been surprised to find how often Greased Lightning is invoked as I browse the web these days… The first time I saw it, I honestly thought it was another lightbox javascript that was being served from the site owner’s HTML page. Greased Lightning alone is worth installing Creammonkey for.

Yesterday, I went searching for more Greasemonkey scripts that are compatible with Creammonkey. Unfortunately, I didn’t find many. The large repository at userscripts.org turns up only a handful, and if you follow some of those links, you might find a few more. For example, this programmer’s site has a number of Greasemonkey scripts, and he believes some of them may work with Creammonkey. I installed a couple of them but didn’t have any success. (I didn’t have time to be exhaustive…)

Nevertheless, I did turn up one other very cool script that works great in Creammonkey: RSS Panel X. RSS Panel X reads the HTML page’s RSS meta tags and then parses and displays the linked feeds in a tiny floating, collapsible window that appears in surprising, bright pastel colors. The script also reads a selection of microformats you may have embedded on your page and adds them to the RSS feed info. I haven’t been able to get this script to work in “automatic” mode in the manner of Greased Lightning, so I added a bookmarklet to my Safari bookmark panel.

Creammonkey is free, has been improved to the point that it no longer degrades Safari’s performance, and now has at least two really useful scripts that lets it show what it can do. Here’s hoping more will be coming along as time goes on.

Version as tested: 0.8.

Quartz Composer Programming Guide: Webpages and Widgets This is pretty cool... I don't think many Mac users know that you can run most Quartz compositions in your browser nowadays, if you're using a late-model version of Safari or WebKit on Mac OS X 10.4.7 or later. Now Apple is trying to educate us on how we can make those compositions interactive using JavaScript. This document explains how to embed a composition in HTML and how to manipulate it using JavaScript.

Protopage News Blog » Protopage V3 released As the find print notes, the Protopage developers "we highly recommend [that Mac users] use either the Firefox or Opera browser for the best Protopage experience." Nevertheless, this is progress, and Safari users no longer get a "no welcome" sign when they try this Web 2.0 personalized home page service out.

Jeffrey Zeldman Presents : Safari better than Firefox? You may not even have noticed the type rendering glitches that afflict Firefox, but clearly they were contributing to your subliminal opinion that Safari simply looks better than Firefox. This guy's blog post does a great job of pointing the glitches out and attempts to explain the underlying problems in Firefox. In some ways, this is no surprise. The Mac has always emphasized excellent typography, which is one of the things that drew print designers to it in the first place. If you've never come to expect great type-handling (as Windows users haven't), you would never even notice the difference. But discerning Mac users can tell. (I hypothesize that one of the reasons Firefox sucks at type is that it doesn't use the Cocoa frameworks... but you could test this by trying the same pages in Camino.)

qooxdoo 0.6.2 released Great news... This is the second post tonight that celebrates an Ajax toolkit's upgrade to add Safari/WebKit support! In addition to Google, Safari/WebKit is now on the qooxdoo developers' radar screen, even if they're avoiding full support for Safari 2.0. Safari 3.0 isn't that far away, and most Mac developers are using WebKit by now anyway. I'll be adding qooxdoo to the list of Ajax frameworks to re-review the next time I update the Scorecard.

Google Web Toolkit Blog: GWT 1.2 Released with Full Mac OS X Support This is good news for WebKit/Safari developers... GWT end-products worked on Safari, but apparently you couldn't actually do development on WebKit/Safari without Google telling you "that's not supported..." Now, it is, and good thing too! Of course, as a JavaScript developer I always found GWT a little odd as a tool for building Ajax web apps. (GWT is designed for Java developers who don't want to learn JavaScript.) I'll be interested to see if GWT 1.2 is a little more robust in its embrace of and support for JavaScript.

Streampad blog » Back button now in use! (Getting history working in Safari) Here's yet another attempt (and a success?) to get back-button functionality working in Safari for Ajax pages. The developer has a test page for this at http://www.streampad.com/test/historyMan.php as well as a good technical description. I do hope the WebKit guys wake up and realize this is a real pain for people trying to develop Ajax apps for Safari...

Working with the WebKit Nightly Builds This article on working with WebKit has some general guidance as well as some specific examples pertaining to the Canvas tag and embedded WebKit instances.

Inquisitor is Like Spotlight for the Web

Originally downloaded 3/3/06. When I first tried this last year, it just didn’t work well enough to pay for. But it still sounds like a great idea, and I’ll be happy to see whether this new version meets the promise.

Update 11/12/06. Well, Inquisitor 2.5 didn’t impress me enough to pay for it, partly because the demo version didn’t reveal the full functionality… which was probably a mistake on the developer’s part. Either that, or Inquisitor 3.0 has so many more features that it’s something I am definitely using happily in place of AcidSearch as a replacement for Safari’s toolbar search field. Not only that, the developer has made Inquisitor 3 available as freeware! This makes Inquisitor a real bargain and nearly a no-brainer.

For those of you who haven’t tried Inquisitor, it’s a Mac OS X InputManager plugin that lets you define alternative search sites for Safari, implements a very visually slick instant-search capability, including customizable autocomplete, and provides search suggestions a la Google Suggest. You can have the suggested terms appear either above or below the results, and you can define how many suggestions and results you get (although you’re limited to 6 results, which is my only significant complaint at this point). For the default search, you can choose between Yahoo and Google, but you can define any number of other sites to search if those don’t cut it.

Inquisitor installs as a preference pane in Safari, providing a compact, convenient way of customizing its behavior. When setting up additional search sites, you can define a shortcut key for each one, and the results list itself can be navigated with the keyboard. So, feast your eyes on the pretty picture of Inquisitor’s search results, and then go get Inquisitor, install it, configure it, and try it out for yourself. For now, it’s only available for Safari, though I suspect the developer will make a Firefox-compatible version available sooner or later, since he had done so for version 2.5.

Version as tested: 3.0 Beta 1 (v34).

TUAW Reports That Adobe Apollo uses WebKit According to TUAW.com, Adobe has decided to use WebKit (the open-source parsing engine that's the basis for Apple's Safari browser) as the HTML rendering engine for its forthcoming Apollo runtime software. Now, keep in mind that Apollo is so new that it's not even mentioned on the Adobe Labs website, which is where all of Adobe's products-in-development are being staged in their early days. But apparently Apollo will be a client for future applications built using Flash, HTML, and JavaScript. Presumably using some tool that Adobe will be providing. From what I've read, no one knows much except Adobe, who has been giving some Apollo demos for the past couple of months. In any case, it's nice to hear that a major software vendor other than Apple may be getting on board the WebKit bandwagon and off of the IE one.

Inquisitor 3. Spotlight for the web.

This is great news! I’ve tried Inquisitor a few times and never found it to be superior in functionality to AcidSearch, which is free. Inquisitor is definitely sexier in appearance, but I couldn’t justify paying for that. Besides, it wasn’t nearly as flexible as AcidSearch. The latest version of Inquisitor, though, is not only free, but it’s also much improved. It now sports a full preference pane inside Safari’s preferences window, which adds a number of useful new customizations. The results list is also much better. Perhaps some of these tools were always there, but only if you paid for the software. In any case, I may be making Inquisitor a permanent addition to my list of Safari add-ons here soon… I’ll try it out for awhile first. Oh, and Inquisitor’s interface is sexier than ever, too.

Cooliris: Why Click?

Originally downloaded 10/14/06. OK, I’ll bite. Cooliris is an extension to web browsers (supports IE, Firefox, and Safari) that pops up a preview of web pages when you hover the mouse pointer over hyperlinks. Since it’s free, I’m definitely curious to see how well it performs.

Update 10/29/06. Cooliris is indeed a cool browser plugin, but personally I find it a bit too aggressive and intrusive. Having used it now for a couple of weeks, I find that it pops up without warning, and I hardly ever intentionally use its magic powers. Occasionally, it’s really pissed me off. For example, I find that when I log into Digg.com (for example) from a Cooliris window, my main browser window doesn’t acknowledge the login. Why this should be so is totally mysterious to me… since I understand the way cookies work, it makes no sense unless the Cooliris window isn’t actually being served from the same host as the “regular” Digg page. In any case, it’s a real time-waster to think you’ve logged in only to find you have to do so again.

Bottom line is, I don’t need Cooliris. I find that it doesn’t load “previews” of pages so much as tries to transfer browser activity from the main window to its own… and its in that process that Cooliris goes from being a help-mate to being a nuisance.

Version as tested: 1.3b.

The title of this article is deliberately provocative: I don't know the answer to the question, and I don't really care. But having been there with Firefox many times, all I can say is that Safari add-ons like SafariStand make me grateful that I don't have to find out. For me, it's much easier to utilize and keep track of one extension rather than keeping, say, six or more in sync and up-to-date.

Our culture is generally dominated by a "more is More" attitude, so that the browser with the most plugins is believed by definition to be the best horse to bet on. This is the same argument some Windows users have made for years with respect to their choice of operating system: I want to use the computer that has the most software to choose from. This argument is proven empty when you actually sit down and compare the quality of Mac software in a given functional category versus that of Windows software (don't take my word for it: Actually do it yourself sometime), and that emptiness carries over to the issue of browser plugins. Certainly, there are some software categories that you legitimately need access to a Windows PC for. But if you notice, nearly all such categories cover business, rather than personal, requirements, and they're for very narrow fields of interest indeed. The only personal software category where the Mac actually lags Windows is gaming, and I predict that the gap in gaming titles won't be nearly so large a year or two from now as it is today.

As far as the supposed dearth of plugins for Safari in comparison with Firefox, SafariStand is an excellent case-in-point. There are other excellent multifunction Safari add-ons (Saft, PithHelmet, Safari Extender, for example), but I'm highlighting SafariStand because it's not only great, but also free. After all, if a Safari user finds they are starting to buy plugins, they really should consider paying for a browser that has dozens of plugins already built in, like OmniWeb. Being the cheapskate I am, I like free things, and SafariStand is one of my favorite freebies for Safari. Besides, most Firefox extensions are free, so it seems only fair to restrict this plugins conversation to those that Safari users can add without paying extra.

In this article, I'm going to focus on just a couple of the best bits from the latest SafariStand beta, which are too wonderful to remain obscure from the Safari-loving hordes. But very briefly, here is a list of the main functions that SafariStand adds to Safari. To gather these functions into Firefox would require the gathering of a half-dozen or more separate extensions, each of which would have to be authorized and kept up to date, etc.

1. Option to restore your last workspace, or any of the pages you had open, on launch.
2. Add sidebar with thumbnail tabs.
3. Customize search engines available in the standard Google search form.
4. Automate "find" function without having to type Cmd-F.
5. Add color labels to your bookmarks.
6. Enable site alteration, customizing allowable plugins, images, JavaScript, style sheets, and more for any website.
7. Colorize the HTML source window, and make it editable.
8. Reorder tabs in a window (this is a native feature of Firefox and will be one in Safari 3.0).
9. Use the "Stand Bar", a floating palette with searchable bookmarks and history, as well as customizable SafariStand folders and RSS feeds.
10. Configure your "Bookmark Shelf," a floating palette that lets you build and access saved "workspaces," which are lists of sites you open up in a browser session and want to save for later use.
11. Access one of the best "Page Info" stores now available for any browser.
12. For any site you're visiting, easily see a list of all the cookies the site has set, examine their contents, and/or delete one or more of them.

Believe me, that's not the entire list... but I think you get the idea. SafariStand is free, is continuously being developed, and works seamlessly and quietly with Safari. You access SafariStand's settings either by the "Stand" menu that's added to the top-level menubar, or via one of two new icons you can add to your Safari toolbar. (If you try SafariStand, be sure to customize your Safari toolbar in order to add at least the SafariStand Actions Menu icon... it's the only way to access the new Page Info window, which I'll describe in a moment.)

Yet Another Improvement To Browser Tabs

The two features I want to provide more information about just showed up a few weeks ago in the latest beta release. One is a really useful, but simple, enhancement to SafariStand's thumbnail-icon sidebar that actually makes this tool usable for me. A couple of months ago, I went into detail about the design of the forthcoming Shiira 2.0's graphical tabs, comparing them with those in the new OmniWeb 5.5. As it turns out, as much as I like Shiira's thumbnail tab implementation, SafariStand's innovation is a brilliant improvement. I hope the Shiira developers are paying attention!

The main problem I've had with thumbnail tabs up to now is that if you make them small enough so that they don't consume too much screen real estate, you can't (or rather, I can't...) distinguish them clearly enough to be useful. You might as well click on the tab to see what page the tab is for, since the teeny icon is too muddy to be recognizable. You could make the tabs big enough to see the thumbnail, but then you're eating up valuable screen space. (An approach some browsers have tried, including Opera and the forthcoming Safari 3.0, is to enable tooltip-like page previews when you hover the mouse over your tabs. This is another great way of letting users distinguish tab content, although it arguably takes more effort than well-implemented thumbnail tabs.)

What SafariStand's developers have done is to add a cropping tool that lets you select the portion of web pages you want to see represented in the thumbnail. This lets you tell the browser to make a thumbnail of only a certain rectangular portion of a given web page. Since most web pages have their main graphical identification in the upper left-hand corner, you can now basically tell the browser to "blow up" that portion into your tiny thumbnail. This also lets you define how high the thumbnails will be, since you can define the height and width of the rectangle to be "iconized."

This is very cool indeed. It's also the kind of feature that a small movie can describe better than words, so check out the accompanying QuickTime animation if you're having trouble visualizing this functionality.

The new SafariStand sidebar has also been cleaned up in small ways that bring it up to date with the latest and greatest Mac OS X software: You now have the light-blue background from Mail, Ecto, iTunes, and dozens of other Mac apps, and you have the "new" standard drag bar that you can use to resize the sidebar. The new sidebar preferences let you decide whether the drag bar goes at the top of the sidebar or at the bottom. All in all, I really, really like the new sidebar. I also like the fact that I can use it while still keeping my regular Safari tab bar, because I like it, too... for different reasons.

"Page Info" Goes Graphical

The second big news in SafariStand is the "Page Info" window. I swear these developers must have read my raves about Shiira's new "Page Info" window back in August, because the new SafariStand window bears a striking resemblence to the one planned for Shiira 2.0. I find this new window invaluable, since as a developer it lets me very easily identify and peruse all the components of a given web page.

Inside the new window, you've got a screen with the basic page information: File size, referrer, user-agent string, and server headers. Next, a pane showing the page's "Sub Resources," a list similar to Safari's standard "Activity" window.

Then we get to the really good parts. First, a pane listing all the CSS files used in the page. Like Shiira's, just click on one, and the CSS file's contents can be browsed in the pane below. The list of the page's JavaScript resources works the same way. Both of these are the easiest way I've seen of quickly peeking at the scripts and CSS instructions used for a web page.

Finally, SafariStand's Page Info window has a paneful of the page's images. Here, rather than simply mimicking Shiira's excellent implementation, SafariStand's developer has improved on it. Where Shiira's window gives you a list of filenames, which you can then click to see each image in the lower pane (the same model used for CSS and JavaScript files), the latest SafariStand provides an instant preview of all the page's images, arrayed as in a Finder window set to Icon View. You also get a slider at the top of the window, which lets you set the scale factor for the icon view, so you can make the images larger or smaller. Click on an image, and a form at the bottom of the pane fills in information about it: Its filename, dimensions, and file size.

This is again so great, I had to capture a quick screencast of the way it works. Hopefully it's clear enough that you can get an accurate picture of how the window works.

Making Safari The Best That It Can Be

Now, it would be great if Apple would simply build some of these features into Safari. What I hear so often is that users think Safari simply can't do this thing or that thing... when I know for a fact that it can. You just have to find the right plugin. And there's a plugin for nearly everything you really want Safari to do. No, you can't have weather forecast information displaying in your status bar, and there's nothing quite like the Scrapbook you can use with Firefox. But honestly, there's probably more free stuff you can get for Safari than you realize.

To begin exploring, start with Jon Hicks' great compilation of Safari add-ons at PimpMySafari.com. Here, you'll find over 50 great plugins for Safari, as well as an extensive collection of "bookmarklets," which are little JavaScripts you can add to your bookmark bar to perform a variety of useful tricks. (Hicks also maintains a similar site for Camino, Firefox's native Cocoa cousin that like Safari is viewed as "plugin poor" compared with Firefox and Mozilla. )

In a quick inventory of my own Safari add-ons, here's what I'm currently using in addition to SafariStand:

• SafariBlock, an excellent ad-blocking tool comparable to Firefox's AdBlock extension. It can block Flash as well as image content, is free, reliable, and very easy to use.
• The aforementioned Safari Extender, a $10 plugin that adds a variety of functions to your contextual menu in Safari.
• Acid Search, a free plugin that adds extensive search engines and customization to the Google search bar, as well as find-as-you-type.
• Safari Tidy, a terrific free plugin that validates web pages for (x)html compliance using HTML Tidy, and puts error and warning messages in your status bar. It also does some great upgrades to Safari's standard "View Source" window.
• SafariScript, a terrific extension that takes advantage of the fact that Safari can do a heckuva lot with AppleScript that other browsers simply can't. The developer's website is a wonderland of great scripts that you can add to your new Safari Script menu, including some which are full-fledged plugins themselves.
• WebDevAdditions, a plugin that corresponds roughly with Firefox's terrific Web Developer extension. It adds an array of menu items and contextual menus that let you parse, poke, and peek at a web page's structure, design, and functionality. It's gotten steadily better since it was first introduced in mid-2005.

I highly recommend all of these add-ons to Safari, but if you're intrigued, be sure to pay a visit to PimpMySafari.com, where you'll find plenty more where those came from, with even more being added each month. You'll certainly find a prominent link to SafariStand as well! With all of these riches, there really is no need for Safari users to look enviously at the more than 1,500 extensions available for Firefox. After all, a huge number of the Firefox extensions merely cover functionality that Mac OS X "Tiger" users can get through Dashboard widgets (which are just little web pages, after all). And how many Dashboard widgets are available now, a year and a half after they were introduced? That's right... almost 2,400 as of today. Believe me, widgets are a heckuva lot more fun than browser extensions, and they're available when your browser isn't running, too.

Uh-oh, you got me started on widgets... So, just to keep this in perspective, if you don't have Tiger and want widgets, Konfabulator is now free and living at Yahoo. Wouldja believe there are now over 3,200 Konfabulator-style widgets at Yahoo's widget portal? Like the Apple-style widgets, nearly all of these are free for the taking.

If that weren't enough, Google is now in the widget business, and though fledgling at this point, has a gallery with hundreds of little web widgets that you can add to your browser to do nearly anything you can think you might want to do on the web.

Now, I don't know about you, but that's more than enough "stuff" I can get nowadays to make accessing web content easier and more enjoyable on my Mac, no matter which browser I'm using. And isn't your ability to access content and services on the web faster, easier, and more fun the final measure of success for whatever web-browsing tools you use?

AppleInsider: Apple-Google collaboration may deliver new Safari tie-ins This interesting report from Apple Insider hints at several specific new Safari capabilities in Leopard that may result from Apple's recent collaborations with Google. The one mentioned in the report is a possible enhancements to Safari's authentication capabilities that would let Safari leverage Google's database of "phishy" websites or malicious URL's.

delicious2safari: Import your deli.cio.us bookmarks into Safari

Originally downloaded 6/1/06. This looks like a neat little app that gives you yet another way to use your delicious bookmarks. You can import them organized into folders (by tag) or not, and use them wherever you like in Safari. I have so many delicious bookmarks now that browse is not an option… only search will do. If this lets me search them faster than the deli.cio.us site itself, it’ll be worth it!

Update 10/9/06. Naw… just not good. I’ve now got all my del.icio.us bookmarks replicated here on Mars, and there are numerous fast ways for me to search them. Putting them in Safari would just gum up Safari, which I don’t really use for bookmarks much anymore… O, how times change.

Version as tested: 1.2.1.

SurfRabbit: The Web, The Way You Want

Originally downloaded 1/26/06. What a great idea! It’s an extension of the idea of using custom style sheets, but has an interactive tool for actually changing columns and other content blocks around. Can’t wait to try it! It’s only for Safari and Shiira.

Update 2/6/06. When first trying SurfRabbit (version 1.0.1), some really strange things started happening to my browsing sessions. Rather than spend time trying to debug the problem, I turned SurfRabbit off.

Update 10/6/06. SurfRabbit still strikes me as a potentially marvelous tool that goes way beyond ad-blockers and such to let the end user see the content they want… rather than the irrelevant content the publisher foists on you. However, when I tried it again today after many months, I wasn’t able to customize any sites at all. SurfRabbit comes with prebuilt “Rabbits” (customized websites) for a lot of the sites I visit—particularly Mac-related sites like MacSlash, AppleInsider, MacRumors, MacDailyNews, etc.—and those do seem to work. But I can’t seem to get access to the tools SurfRabbit provides for building new “Rabbits.” I sent an inquiry to the developer, and we’ll see how that goes. I’m not giving up on it yet…

Version as tested: 1.2.1.

SafariScript: You're missing extensions for Safari?  Here they are! Originally downloaded 10/4/06. With all the great Applescripts available for Safari, you'd think Apple would have done this first... or made it an option.  But at least someone thought of it... in fact, it's the developer who did similar favors for Camino.  There's also a nice script repository onsite.  Oh, and the developer says you can define keyboard shortcuts for any of the scripts! (Gee, I wonder if they'll work in Safari 3.0?)

Version as tested: 1.2.