-
Notifications
You must be signed in to change notification settings - Fork 4
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
getViewportScreenshot (younger sibling of getViewportMedia) #2
Comments
How about <input type="file" accept="image/*" capture="viewport"> ? That'd be consistent with what we have for camera (i.e. there's no We could keep the same security requirements. |
It seems to me like a mostly stylistic change from the API proposed by me, so I'd be generally fine with it. But it looks a bit sub-optimally ergonomic to me. Consider an application that has an API comprised mainly of buttons. It would want to add yet another and set its handler to call newApiForScreenshotsBySomeName(). With your suggestion, they'd have to instead instantiate a new |
For my purposes I would love to give getViewportScreenshot a DOM node to take screenshot of to further minimize what is actually captured, similar to how requestFullscreen displays a specific part of the document. What I really want to get rid of from getDisplayMedia are all the options for the user to make mistakes and capture the wrong thing. I want to present them with one thing and have them go yes or no. I'm not against giving the user the option to trim or black out stuff if they want to, as long as it doesn't give any extra steps if you don't want to. In my main purpose the result is saved to the user's computer, but I realize the security question can't say "Save", since the browser doesn't have a simple way to enforce it. Using the input tag feels like a throwback to Opera Mini where type="file" would always just open the camera and then upload the result. The less active HTML is the better in my opinion. Have it deal with layout and content, and move everything event based to JavaScript. |
Using
getViewportMedia
to obtain a single screenshot is a useful use-case that has already garnered some interest from Web-developers. However, some issues exist, motivating a variant ofgetViewportMedia
to be specified, subject to the same security-gating. Those issues are:getViewportMedia
is called, the user agent does not know ahead of time how many frames will be consumed by the application before the track is stopped. The user agent will therefore employ language that informs the user that the application is seeking permission to capture a video of the current tab.getViewportMedia
on such user agents will consistently miss a portion of the viewport for no good reason. (This may even push some applications to attempt using getDisplayMedia and full-window capture - a perverse incentive.)For those reasons, I propose that after we finalize
getViewportMedia
, we add to the same document a specification ofgetViewportScreenshot
.Fine details:
MediaStream
, of course.The text was updated successfully, but these errors were encountered: