Formalize the restriction transformation

[eladalon1983]

This PR formalizes what restrictTo() does a bit better, but does not yet go all the way. (Hence some TODOs.)

---

Preview | Diff

[markafoltz]

Some initial comments to align this with parts of view transitions, which has some of the same requirements. And some other thoughts which are tangential to this specific PR.

What are you thinking should happen if an element violates some of the conditions that make it capturable? It seems like with region capture, only the capturing application gets an indirect signal that the capture is failing (i.e. no new frames are produced).

From an ergonomics point of view, it may be worth having some signal back to the captured application as to why capture is not working. We could probably wire up some debug messages in devtools, but a more explicit API in script could also be an option.

[eladalon1983]

Some initial comments to align this with parts of view transitions

At the moment, I see view transitions as an implementation artifact of Chrome, and not a requirement we should consciously add to the spec. I think that if we phrase the spec correctly, theoretical implementation may choose to render twice, or to force all other stacking contexts to become transparent, or to use any other approach - so long as the result is identical.

From an ergonomics point of view, it may be worth having some signal back to the captured application as to why capture is not working.

The captured application is not necessarily even aware that it's being captured. Consider:

• TLD (top-level document) embeds ED (embedded document).
• ED sends a CropTarget.
• <5 minutes later meme>
• TLD calls gDM(preferCurrentTab: true) or even getViewportMedia().
• TLD uses the CropTarget it previously got.

I think it's up to the capturer to inform the capturee, if necessary. I think the browser should not tell the captured application that it's being captured.

[eladalon1983]

@baylesj, could you please also take a look?

[eladalon1983]

I've made significant changes to this PR, so PTAL, @mfoltzgoogle and @baylesj.

[baylesj]

@baylesj, could you please also take a look?

Overall looks good to me. Is there a straightforward way to view this as rendered and styled HTML to check that part of it?

[eladalon1983]

@baylesj, could you please also take a look?

Overall looks good to me. Is there a straightforward way to view this as rendered and styled HTML to check that part of it?

Check out these two links.

[khushalsagar]

Discussed offline, we'll file a csswg issue to resolve the question on implicit vs explicit rendering constraints.

[eladalon1983]

Thanks for the review everyone!

Mark, apologies for not waiting for an official LGTM, but I think all of your comments have been addressed, and I'd like to send an i2p for this earlier. If you have any more open issues, I'd be happy to deal with them in follow-up PRs.