Re: [w3ctag/design-reviews] Early design review: Document Picture-in-Picture (Issue #798)

Hi @steimelchrome thank you for bearing with us.  We're picking this back up today and trying to get you some useful feedback.

We're concerned about spoofing. There's some language in the spec about this now - great - but there is no discussion in the explainer about possible abuse cases and mitigations against those abuse cases - that would be very valuable. Also the language in the spec just says UAs need to provide "enough UI" which is a bit vague. Is there any non-normative language that could be added here to elaborate on the kind of UI that should be provided? Also, could you confirm that the PiP window will only be opened as a direct result of user action?

We're concerned about accessibility. Specifically the explainer doesn't mention how focus management is expected to work. How will users move between the PiP window and the main document?

We are still concerned that from an author perspective, this introduces a feature that is very related to `window.open()` but solves subtly different problems. We saw the part in the explainer about this, but it may be useful to decompose the problem into the parts where `window.open()` behavior conflicts with what is desired here, and examine whether these primitives may be useful for `window.open()` as well. Based on the differences mentioned in the explainer, that does seem to be the case:
- a window that does not outlive its opener is definitely a useful concept for `window.open()`, in fact if we were to design `window.open()` today I'd argue it should be the default!
- Feature testing `window.open()` features is also a more general problem.

Decomposing this into lower level functionality that can be integrated in `window.open()` would also address the spoofing concerns as well.
An important question we need clarity on is, is there something that makes this functionality fundamentally incompatible with `window.open()` or is it about managing design & implementation effort?

@steimelchrome thanks for sending @domenic’s [comment](https://groups.google.com/a/chromium.org/g/blink-dev/c/JTPl7fM64Lc/m/OfBZRdjEAAAJ) (though it took some effort to track down in that long thread)
> Re: modernized window.open(): Domenic gave some input on this in the intent to ship: [groups.google.com/a/chromium.org/g/blink-dev/c/JTPl7fM64Lc](https://groups.google.com/a/chromium.org/g/blink-dev/c/JTPl7fM64Lc)

> There is some TAG feedback that seems to wish this was part of window.open() or some other more-general API, but I think that advice is not correct, and the current API design is good, due to the singleton-per-top-level-traversable nature of a document PiP window. In my opinion this makes the window.documentPictureInPicture entrypoint, with its requestWindow(), window, and onenter properties, a good API for the use case.

We'd love if you or @domenic could elaborate on this, as we're a bit unclear on the argument being made (what is singleton-per-top-level-traversable-nature?).

Can you please let us know the current status and any response to these issues?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/798#issuecomment-1881548518
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/798/1881548518@github.com>