Consider single frame snapshotting use-case

[Zubnix]

The idea is to support a good solution for the plethora of slow and hacky solutions that currently exist:

• http://cburgmer.github.io/rasterizeHTML.js/
• https://github.com/PixelsCommander/HTML-GL
  • https://gist.github.com/PixelsCommander/a0b5882139cbb8a1781c#file-proposal-md
  • http://pixelscommander.com/javascript/state-of-html-content-rasterization-draw-html-to-canvas-image/

The current element-capture proposal could provide an excellent solution with no additional changes to its current API proposal, but only on the condition that it provides an option to do raw [passthrough] video encoding (including alpha channel support) and the option to produce only a single frame (perhaps by setting the desired fps to 0?).

[JonnyBurger]

I would want this as well - more popular examples are html2canvas https://html2canvas.hertzen.com/ and Remotion https://remotion.dev (by me).

Capturing images from the video stream is not a good solution, becauseMediaRecorder compresses the picture.

[eladalon1983]

For those interested - @Zubnix and I have also discussed this over https://github.com/WICG/proposals/issues/73.

I think that the Element Capture API produced here would not be the ultimate replacement for a dedicated screenshot API. One reason is that for screenshots, the browser should ideally prompt the user to grant permission for a single frame. An API built on top of video cannot do that.

I think that Element Capture is a great stopgap measure for screenshots, using a combination of (1) preferCurrentTab or getViewportMedia, and (2) Element Capture. But ultimately, I think we'll want to build a separate, dedicated API for screenshots. (Likely this will be easier for browsers that have already put in the work to support Element Capture, as Chrome is already doing.)

For those interested, I have previously proposed a screenshots API version of gVM. We're reviving work on gVM, so it'd be a good time to also revive discussions of screenshots there.

including alpha channel support

Another way in which a non-video API is required, differentiating the screenshots use-case from the video use-case that Element Capture targets.

[markafoltz]

This should work, if applications can live with the restrictions:

1. The need to use the preferCurrentTab picker flow to initiate capture.
2. The lack transparency-capable format. Even though Chrome now supports RGBA tab capture, currently there's no way I'm aware of to force Chrome to produce it from getDisplayMedia.
3. Cooperation from the site from which you're capturing screen shots. It will need to mint tokens, attach them to elements and pass them to your application.

The main advantage of a dedicated screenshot API would be additional guardrails around the capture process. For example we could immediately terminate capture after the screenshot is taken, and allow the user to preview the screenshot before sharing it with the site.