Vote: Adopt spec by Screen Capture Community Group

[eladalon1983]

This issue collects votes for the Screen Capture Community Group to adopt the Element Capture spec.

The recommended format for casting your vote is to use one of the following:

1. I support adopting the Element Capture specification.
2. I support adopting the Element Capture specification; we at {company} intend to use it soon for {purpose}.
3. I object to the adoption of the Element Capture specification. My list of blocking-issues is {list-blocking-issues}.

Mentioning which company you work with, and whether you have a specific use-case in mind for this API, helps browser vendors set the prioritization of implementing this API. For some browser vendors, such "Web developer signals" are taken into account when deciding whether an API is ready to be shipped.

[brianshultz]

(2) I support adopting the Element Capture specification; we at Tango intend to use it soon filter out elements during screen capture

As a founder of Tango, a company that helps users to automatically generate documentation with perfectly cropped screenshots, I can't emphasize enough how instrumental this specification would be for our product and user experience. Our platform is recognized as one of the 12 Chrome Store favorites, and we're eager to continue innovating.

One feature our users absolutely love is the orange box highlighter that guides them during the recording process. However, the inability to adjust the orange box on their screenshots after the fact has become one of the most frequent requests from our users. Additionally, our controller, which appears at the bottom of the screen (similar to Loom). See the demo below.

We've attempted to hide the orange box and controller right before taking screenshots, but the numerous edge cases related to screenshot timing, resolution, device latency, and more make this a challenging endeavor. While we've considered using html2canvas and similar libraries, they simply don't provide the reliability we require for our use-case. This is why the Element Capture proposal would be a game-changer for us, and we would enthusiastically become early adopters.

https://user-images.githubusercontent.com/18270111/227675962-3aaeb6f9-251b-4e67-bc24-a63a68f94702.mp4

[alvestrand]

I support adopting the Element Capture specification.

[happylinks]

I support adopting the Element Capture specification. We could in the future use this to do cleaner screen captures in our chrome extension. We'd let the user "inspect" the page and pick the part they'd want to capture more specifically.

[AdamJaggard]

I support adopting the Element Capture specification.

[fideltian]

i like the idea of Element Capture. But it seems limited on capturing Dom element. Zoom supports user-drawed rectangle to do the region capture while sharing a screen.

Why not supporting the API to all kinds of capturing. for example. const stream = await navigator.mediaDevices.getDisplayMedia(); Then add a API to return the position of the display stream in the whole desktop. [(x,y),(width, height)]

Then cropTarget could be any rectangle [(a,b),(width,height)]

In the end, do the crop of the stream based on the overlap of the two rectangles.

And the position of the display stream with in the whole desktop, it is very useful in later remote control or annotation.

[eladalon1983]

@fideltian, that sounds like a possible extension to Region Capture, which is concerned with cropping, but not with occlusions. It sounds out-of-scope for Element Capture, whose focus is capturing DOM subtrees. Or wdyt?

[fideltian]

yea. it is more alike region capture. But i think the two (region capture and element capture) could be unified as one? Element capture is to get a cropping region of DOM subtrees? and then use region capture to do that?

And if there is a element not belongs to a Dom subtrees, but a floating window/div covers the area of a Dom's view. What will happen? the floating window/div will not be included? if that in meeting case, it is concerned that the view is not the same between the presenter and the viewers?

[eladalon1983]

The recommended procedure is:

1. File issues.
2. Use this issue to vote. When rationalizing a vote, one should reference other issues as necessary.

But i think the two (region capture and element capture) could be unified as one?

If you file an issue with a concrete proposal, I'd be happy to elaborate there why this approach was not taken. (Briefly - if you add new parameters to existing methods, then old implementations silently ignore them, which is a footgun.)

Element capture is to get a cropping region of DOM subtrees?

Element Capture gets a DOM subtree. For cropping, there is Region Capture.

And if there is a element not belongs to a Dom subtrees, but a floating window/div covers the area of a Dom's view. What will happen? the floating window/div will not be included? if that in meeting case, it is concerned that the view is not the same between the presenter and the viewers?

I don't understand this paragraph. Could you please file an issue and explain in more detail what it's about? (It sounds like a request for clarification of Region Capture vs. Element Capture...?)

[fideltian]

Thanks @eladalon1983 for your suggestion.

4

[fideltian]

Element capture has its use case. it is different as region capture. Up for it.

[arnaudbud]

I support adopting the Element Capture specification.

[pirate]

I support adopting the Element Capture specification; we at ArchiveBox intend to use it soon for capturing login modals, cookie popups, and other elements that hinder internet archiving so they can be shared with a human for manual handling.

[fideltian]

Is it OT now, we would like to do a experiment of capturing a Whiteboard case, which embedded in a page.

[MatanYemini]

I highly support adopting this specification. We at Engageli intend to use it for our session recorder, and for collaboration tools.

[eladalon1983]

Is it OT now

Yes, Element Capture is in origin trial right now. You can register for the experiment here.

Please note that the current experiment will be running until June 24. The experiment will then be stopped for 3 weeks, after which the experiment will be restarted come July 15 (requiring new tokens), lasting until the end of m132.

[markafoltz]

@eladalon1983 I move to close this issue, as the voting wrapped in in May.

[eladalon1983]

Sure. We could ask for feedback to be filed as distinct issues filed. That will be neater.