Gecko has a really nice css feature called -moz-element (https://developer.mozilla.org/en/CSS/-moz-element) that can be used to apply a _live_ view of a dom subtree as the background of another element.

People have done some awesome stuff with this, such as reflections, transition effects, and even recreating the blurred aero skin, by combining it with svg effects.

http://hacks.mozilla.org/2010/08/mozelement/ https://developer.mozilla.org/media/uploads/demos/D/a/David%...

And what's even cooler, this has been added to the CSS3 draft spec, so it might actually soon be implemented in the other layout engines! http://dev.w3.org/csswg/css3-images/#element-reference

Are these screenshots though?

I thought the point of a screenshot was to capture how the page/screen has been rendered by an actual browser/platform. Isn't this a different rendering? If the quirks aren't rendered then the use is limited.

The original question was to know how Google was driving their G+ feedback feature. In the context of capturing user feedback, the point of a screenshot is to relay information about the state of the user's environment to someone else, without the need for physical proximity.

In my experience, users who report feedback are typically concerned more with the data on the page than how the page itself looks when it's rendered. In these cases, a screenshot acts as proof and can immediately focus the problem without requiring a lot of written description. Among users who have non-trivial feedback about a website, the likelihood of their being able to clearly and concisely describe their problem is vanishingly small, and removing the friction of attaching screenshots to their issue reports is immensely helpful.

If you haven't seen it yet, the "Shooter" addon for firefox basically does this same sort of thing (screenshot of page by using the canvas). https://addons.mozilla.org/en-US/firefox/addon/shooter/

The only real bug I've seen in it is the use of white as the default background color in pages, with all page styles (and css files) loaded on top... This means it's (properly?) ignoring the user defined page background color.

Code that runs with access to the chrome can "cheat" and just use

https://developer.mozilla.org/en/Drawing_Graphics_with_Canva...

Try using their console: http://html2canvas.hertzen.com/screenshots.html

Very impressive! Can someone explain how _exactly_ does it work? Has the author implemented a renderer inside JavaScript?

He explains on its GitHub page[1]—"the script renders the current page as a canvas image, by reading the DOM and the different styles applied to the elements."

[1] https://github.com/niklasvh/html2canvas#readme

Wow, that's impressive. Works really well.

I used this for our screenshot app as well :) It's really nice. Some quirks, but those are hardly noticeable.

Nifty but still not convinced that is how Google is doing it.

How do you handle iframes with content external to the domain?

They use a proxy for that (though currently its not implemented properly - example: they are directly sending /background-image urls as /proxy/url("someimage") - so not loading). But I think this is a nice base to build on. All that needs to be done is render more css properties and send url("") for images properly.