I was always interested if the service that, for example, WebSnapr provides is practically useful. Having snapshots of a linked pages looks very cool indeed, but does not really provide much information, at least for me.

But recently I have found a nice use case for a similar service. For tables in my IoC Frameworks posts, I was using parts of a Zoho spreadsheet embedded through an iframe. However, Google Code wikis do not allow iframe embedding.

The easy solution was to use built-in wiki table markup, but in this case I would lose all color coding and ability to download the whole sheet as Excel. The interesting solution was to embed snapshot of an iframe, as an image. This would also allow me to solve the iframe problem for RSS readers that do not support them.

My original idea was to use Firefox or Chrome (via Chromium project) to do the snapshots, but I have not managed to use the Mono.Mozilla on Windows and I was too lazy to dive into Chromium.

IE was the simplest remaining choice, so using information from the great article of Peter Bromberg, I have built my own implementation of web snapshotting service. The main difference between my snapshots and other services is that my service can actually determine the correct size of the snapshot.

For example, this is a snapshot of my IoC frameworks table:

You can click it to see the source of the snapshot. As you can see, it has correct size (instead of being fixed to 1024×768 or another screen size). On an unrelated note, it is an updated version of framework comparison, now including LinFu (which was updated to pass all feature tests).

In Google Code it looks like this.

Additional interesting usage for this would be iframe-widget embedding to locations that do not support iframes. For example, it is possible to embed a list of RSS feed headers or twitter messages in Google Code using this technique.

You can svn-download source code from Google Code. It is really bare for now, no good error-handling and no resizing support (all snapshots are always displayed in full size). However it may be a good starting point.

Looking at this project, I think that it would be very interesting to have a .NET wrapper for Chrome APIs that would allow anyone to automate Chrome, which probably will make snapshot extraction much faster and not COM-reliant.

This may belong to Twitter.

1. Comic — nicely done, but how about some good words for work of other people (especially when influenced by it)?

   IE8

   • Process per tab
   • Private mode
   • Emphasis of domain name in the address bar

   Opera

   • Search shortcuts
   • Speed dial (but Google improved it)
   • Tabs on top of address bar (which is the sane way to do it)

   Firefox

   • Search/address bar 
   • JavaScript JIT (Firefox 3.1)

   I understand why Microsoft is not saying “just like Firefox”, however a lot of Google PR is about being friendly.

   Also, I was a bit surprised by the multiple references to tab crashes not crashing the application. Does somebody really encounter often tab crashes? Opera crashes in extremely rare cases, and it is possible to restore a session anyway.

2. Future? I still use Google Talk (and converted a lot of people), but it seems no one at Google cares anymore. There are at least three different Google Talk editions, with unrelated features (Labs Edition supports text conferencing, but not file sending).

   So it is interesting if Google is going to support Chrome if it does not get significant popularity. It is open-source, however, so my concerns may not prove important.

3. Process explorer is a fabulous feature, a must have for every other browser. However, aside from that, a good JavaScript debugger is important.

4. Chrome is a bit of a performance hog, not sure how it compares to Firefox, but it is definitely heavier than Opera, especially CPU-wise.

5. Not exactly Chrome-related, but why people seem to want a relational database in the browser (Gears, HTML5)? JavaScript structures are already extremely usable and easy to work with. They also abstract fast searching (hashes). Why not use a JSON storage stored in a browser-specific way, instead of putting SQL specification into HTML?

In general, Chrome may replace Opera for me, depends on how well it works with saved passwords (Firefox is way worse than Opera’s Wand), gestures and its overall performance.