-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Vote: Adopt spec by Screen Capture Community Group #3
Comments
(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. Tango.Controller.and.Highlighter.mp4 |
I support adopting the Element Capture specification. |
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. |
I support adopting the Element Capture specification. |
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. 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. |
@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? |
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. |
The recommended procedure is:
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 gets a DOM subtree. For cropping, there is Region Capture.
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...?) |
Thanks @eladalon1983 for your suggestion. |
Element capture has its use case. it is different as region capture. Up for it. |
I support adopting the Element Capture specification. |
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. |
Is it OT now, we would like to do a experiment of capturing a Whiteboard case, which embedded in a page. |
I highly support adopting this specification. We at Engageli intend to use it for our session recorder, and for collaboration tools. |
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. |
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:
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.
The text was updated successfully, but these errors were encountered: