… or “Hey, dawg, we heard you like Safari so we put your Chrome in your Safari so you can Safari when you’re done Chroming!”

I tend to do desktop surfing with Google Chrome because I do a lot of “open 10 tabs at the same time” stuff on our Drupal multi-site and Safari’s not very good at that. Sometimes, when it’s time to head downstairs for lunch or by the fireplace for some iPad surfing, I find myself wanting to take a few things I had open in Chrome with me on the iPad. I used to use Pinboard, but Safari’s new reading list is more convenient and doesn’t clutter up Pinboard with short-lived links, so it’s cool that there’s an AppleScript command to add things to it:

And here’s one that does the same thing with the selected NetNewsWire headline:

Hook them up to the actual apps to taste.

I made the mistake of writing a quick Automator workflow that created a Service Menu item to do the same thing with any selected URL in any app, but when I went to try out my new service I noticed Apple had already thought of that. Easier to go into System Preferences and create a shortcut for it.

If you don’t mind the extra keystrokes, you could also just ⌘l then ⌘c to get Chrome’s current URL and use the service, no need for AppleScript at all, but I wrote it all before I realized Apple had done it for me.

What about Firefox?

No real scripting support because Firefox is lame like that and always has been. You can get the current Firefox URL by using AppleScript to press ⌘l then ⌘c:

Yuck.

Google Chrome Market Share Surges, Apple’s Safari Dead In Water, Microsoft’s IE Drowning:

The more important story here is potentially that Google’s Chrome is gaining share much faster than Apple’s Safari. This highlights the power of Google’s ‘open source’ software model, as compared to Apple’s integrated hardware-software combo. The software versus hardware/software model, of course, is what doomed Apple in its first battle to the near-death (against Microsoft). So it’s worth watching this one closely.

I’m going to return to my point from a couple of days ago instead of savaging the excerpt.

Chrome’s rendering engine is WebKit. That’s an Apple project. Apple took KHTML, spruced it up (such that I know of one Linux site where Konqueror breaks but Konqueror-using-Webkit works), and made it open source. Google liked what it saw and borrowed it for Chrome.

If the author of that excerpt were to be confronted with this fact, he or she might backpedal by pointing out that Apple is a tiny bit open but Google is super-open, and the uptake numbers reflect that. Such backpedaling would require additional politeness on our part, because that’s entirely not the point. The point is this:

It isn’t a bad thing for Apple that Chrome is doing well using WebKit. In fact, it’s a really, really good thing: Apple can continue to serve its customers as it sees fit, Google can continue to serve its customers as it sees fit, and neither has to pay a price for the other’s popularity in terms of the way its customers experience the Web. Both get an outstanding, standards-compliant rendering engine that runs on every major desktop platform, is amenable to being wrapped in a wide variety of toolkits, user agents and form-factors, and helps ensure that we won’t ever have to worry about a single vendor trying to lock the Web up with a bunch of proprietary, non-standard extensions and quirks. Chrome’s gain is every Safari user’s gain and vice versa.

If we want to talk about what in this story is worth watching closely, it’ll be in the ways Apple and Google interact around the WebKit project, and how two companies that are on a collision course in a couple of different spheres (besides the heavily commoditized browser market) manage to relate to each other in a case where they share a mutual interest. Might as well include Adobe in the companies to watch despite bitter disagreements: It uses WebKit to render HTML in Air.