Paul Hammond

Hi—I built that extension! Thank you for using it. You can view the source code here:

https://github.com/mrcoles/full-page-screen-capture-chrome-extension

It’s malware & spyware free. I built the extension to take a screen cap of a seating chart that I built as a web page for my wedding—since all the other extensions at the time were broken. Why a web page for my seating chart? IDK, I wanted to play with CSS3 columns, alas I should have used photoshop…

I have been contacted by people who want to buy the extension, but it seems too dangerous, since they could easily install their own malware—I wonder if anything like this happened to “Awesome Screenshot”? My own conscience and, more importantly, my personal brand is too important to me to sell it.

In terms of the permissions, when I built it, I had to ask for those permissions in order to make it work. If you find any changes to chrome permissions that let me ask for fewer, please let me know or, better, submit a pull request.

Also, instead of PhantomJS, if you have a Mac, try out `webkit2png`, which works great as long as you don't need to login or interact with a page before the screenshot:

http://www.paulhammond.org/webkit2png/

If you need technical details, implementing it is quite simple. For generating screenshots on an Ubuntu machine, you just need a script called webkit2png.py http://www.paulhammond.org/webkit2png/ and XVFB (fake X server).

After that, taking screenshots is as simple as firing this command on shell:

xvfb-run --server-args="-screen 0, 1024x768x24" python webkit2png.py -o google.png -F javascript -w 2 http://google.com/

Even though it is resource-intensive operation, I decided to generate screenshots on our own servers over using an existing service because I didn't find a satisfactory screenshot generation API that captures full-page screenshots (as opposed to just thumbnails).

Next feature is to implement nicely formatted PDF reports. But my initial research says it is a VERY hard task! (That's because VWO charts are all JavaScript powered)

The author recommends two ways to target rules at IE: 1) create new stylesheets for each version of IE, or 2) CSS hacks that only IE understand/ignores.

But I prefer to use a different approach: conditional classes on the body tag. For example:

<!--[if lt IE 7 ]> <body class="ie6"> <![endif]-->
<!--[if IE 7 ]> <body class="ie7"> <![endif]-->
<!--[if IE 8 ]> <body class="ie8"> <![endif]-->
<!--[if !IE]><!--> <body> <!--<![endif]-->

Then you can write IE-specific rules without CSS hacks:

body div#container { background-color: white; }
body.ie6 div#container { background-color: red; }

And all your related styles can be grouped together in the same file.

via http://paulirish.com/2008/conditional-stylesheets-vs-css-hacks-answer-neither/ and http://www.paulhammond.org/2008/10/conditional/

I built exactly this once, was fun to set and forget and look back on it in a few months. It calculated the diff and you could see obvious spikes when big changes were rolled out. You saw a lot of big spikes on say Apple.com when new products were announced or marketed, whereas Reddit.com was always changing and couldn't detect any meaningful patterns.

It also had ffmpeg in the backend that would create a timelapse for you on demand. I built it when we rolled out our some rebranding/homepage changes on GitHub.com and nobody really knew off the top of our heads when exactly the last time we updated it was. Git only tracked code changes, no visual changes.

It was originally built on top of http://www.paulhammond.org/webkit2png/