Does an element need to be inside the viewport?

[JonnyBurger]

Can the following element be captured or can it not because it is outside of the croppable area?

<div style="top: -999999px; left: -999999px; height: 100px; width: 100px; background: green; position: absolute;">

It would be useful if it is possible! For image and video editor, the media is often bigger than the browser viewport (let's say a 5MP image or a Full HD video).

[eladalon1983]

Capturing content of unlimited dimensions is not practical from an implementation standpoint. Allowing each user agent (browser) to implement its own limitations is bad for interoperability. Limiting to the intersection of the element's bounding box with the viewport gives a clear and simple definition that's sufficient for the vast majority of use-cases, and which can be implemented consistently between browsers.

[markafoltz]

The answer to the original post is currently "no" and that is made explicit in the spec; step 3 of Applying the restriction transformation.

I think it would be useful to keep this open to note the use case for capture outside the viewport, however.

[bradisbell]

Being unable to capture stuff outside of the viewport makes this API useless for pretty much any use case I can think of.

I want an off-screen iframe that I can postMessage data to, that is rendered with alpha channel to a MediaStream or similar, so that it can be composited onto other video and output as video. Even better would be to capture audio for that iframe and redirect it to a MediaStream. Essentially, we just need a captureStream for an iframe.

This feedback has been given in many places previously, by myself and several others working in similar spaces. It's very frustrating that these nice specifications keep popping up, and then become wrecked along the way with seemingly arbitrary restrictions.

What can us non-Googler non-W3C-dues-payer folks do? We appreciate the efforts made by several to include us in open discussions and meetings (shoutout to @eladalon1983), but the actual decisions always seem to be made elsewhere at other times. Often by the time anyone has heard of the new feature, it's already too solid to change.

Every artificially-limited API does irreparable harm to the web-as-a-platform. New APIs have significant implementation cost but a much higher modification cost. Let's be real, the likelihood of revisiting decisions such the "restriction transformation" is near zero.

[hrgdavor]

I have a use case in mind that could be related to this, but would love some feedback if it can be done well without.

When creating an editor like figma for example does with huge ammount of elements, it becomes necessary to optimize the rendering that it can support those huge documents. taking a snapshot of an document and using it as thunbmail when zoom out happens sounds like something useful for such case.

There are things done in the backend with headless browsers, for testing, for thumbnail generation it would be sad if this snapshoting of elements would be pushed to backend (ofc google, MS, AWS really like selling cloud compute) when it can happen on the client.

I may not be explaining it well enough, but there are many use-cases for taking element snapshot that would open the gates to many new cool applications, instead only focusing on conferencing apps (zoom, meet, wahtever).

I really find it hard to accept that you really are sincerely covering "wast majority" of use cases. Spec could define size as 1x,2x of screen size to be max and allow much more freedom, it does not have to allow infineite. Even for conferencing apps this is silly, as you would be limited by ui elements from generating shapshot size of whole viewport (I may be wrong, and misunderstanding, as I have not read the spec).

I apologize if I made false claims here(I am very interested in the spec, and in sucha cases I easily get abrasive), since I do not know spec in depth, and hope you can answer some of my concerns even if from your point of view it is obvious in the spec.

One glimmer of hope would be if I could use parent element to transform scale. And when taking snapshot of the element I get full resolution of it, this way I could at least have a chance to snapshot elements, and generate thumbnails. I did this trick with openlayers and it's canvas to generate maps larger (in pixels) than the viewport.

I hope I am making sense here, not sure if I conveyed my concerns well here. Could some the performance issues that concern me be helped maybe with inert attribute ?

[eladalon1983]

Hi @bradisbell. These APIs are debated at such forums as the WebRTC WG and the Screen Capture Community Group. You are very welcome to join the latter (joining link). Note the two upcoming meetings next week, whose details are here.

useless for pretty much any use case I can think of.

I understand and appreciate the general sentiment here, but I think you're not 100% intellectually honest in this message. Surely you can see that these APIs are focusing use cases that you simply don't share? Otherwise, why would we have gone to the trouble of specifying and implementing them? I am sure you can think of use cases beyond those which you happen to have. And if not - here is one concrete example for the current API.

Of course, we aim to build APIs that are optimally useful for as wide an audience as possible. Please work with us to get there, and kindly understand our perspective when convergence is not achieved.

artificially-limited API

I don't believe any of the restrictions are artificial, and I would gladly discuss each and every design decision. Some decisions might be outdated, some might even be misguided; but nobody is imposing limitations for entertainment's sake, I assure you.