Intent to Implement and Ship: CSS pseudo-class ":picture-in-picture"

[François Beaufort]

Contact emails

fbea...@chromium.org, mlam...@chromium.org

Explainer

https://github.com/WICG/picture-in-picture/pull/120

Spec

Specification: https://wicg.github.io/picture-in-picture/#css-pseudo-class

Summary

A CSS pseudo-class is added to help web developers customize media player when video enter and leave Picture-in-Picture.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

This feature will be supported on all platforms that currently support the Picture-in-Picture API.

Risks

Interoperability and Compatibility

This feature is an addition to the existing Picture-in-Picture API that has only shipped in Google Chrome yet. If this feature would not be adopted (even though it’s part of the spec) web developers could still listen to the video JavaScript events “enterpictureinpicture” and “leavepictureinpicture” to be notified when a video element enters and leaves Picture-in-Picture.

Note that the Fullscreen API already has support for a CSS pseudo class as well.

Edge: Public support

Firefox:  No signals

Safari: No signals

Web developers: Positive

Ergonomics

N/A

Activation

This feature will be covered by developer documentation at https://developers.google.com/web/updates.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

Yes. They will be added to https://wpt.fyi/results/picture-in-picture

Link to entry on the feature dashboard

https://www.chromestatus.com/features/6259534815297536

[Emilio Cobos Álvarez]

On 27/03/2019 16:33, François Beaufort wrote:
> Contact emails
>
> fbea...@chromium.org <mailto:fbea...@chromium.org>,
> mlam...@chromium.org <mailto:mlam...@chromium.org>

>
>
> Explainer
>
> https://github.com/WICG/picture-in-picture/pull/120
>
>
> Spec
>
> Specification:https://wicg.github.io/picture-in-picture/#css-pseudo-class

The pseudo-class definition in that PR mentions the retargeting
algorithm in order to tell whether the pseudo-class matches.

If I understand correctly, the implication is that all closed shadow
hosts will match the pseudo-class as well, right?

That looks a bit weird to me, though :fullscreen is defined like that
too... Do you know about the reasoning for that?

-- Emilio

> Summary
>
> A CSS pseudo-class is added to help web developers customize media
> player when video enter and leave Picture-in-Picture.
>
>
> Is this feature supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?
>
> This feature will be supported on all platforms that currently support
> the Picture-in-Picture API.
>
>
> Risks
>
> Interoperability and Compatibility
>
> This feature is an addition to the existing Picture-in-Picture API that
> has only shipped in Google Chrome yet. If this feature would not be
> adopted (even though it’s part of the spec) web developers could still
> listen to the video JavaScript events “enterpictureinpicture” and
> “leavepictureinpicture” to be notified when a video element enters and
> leaves Picture-in-Picture.
>
> Note that the Fullscreen

> <https://fullscreen.spec.whatwg.org/#:fullscreen-pseudo-class>API

> already has support for a CSS pseudo class as well.
>
>
> Edge: Public support

> <https://github.com/WICG/picture-in-picture/pull/120#issuecomment-476873377>

>
> Firefox:  No signals
>
> Safari: No signals
>
> Web developers: Positive
>
>
> Ergonomics
>
> N/A
>
>
> Activation
>
> This feature will be covered by developer documentation at
> https://developers.google.com/web/updates.
>
>
> Is this feature fully tested by web-platform-tests

> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>?

> Link to test suite results from wpt.fyi

> <https://wpt.fyi/results/?label=experimental>.
>
> Yes. They will be added tohttps://wpt.fyi/results/picture-in-picture

>
>
> Link to entry on the feature dashboard <https://www.chromestatus.com/>
>

> https://www.chromestatus.com/features/6259534815297536
>
> --
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to blink-dev+...@chromium.org
> <mailto:blink-dev+...@chromium.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/14d6c7e0-3478-4e93-bbea-a5c6411231b2%40chromium.org
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/14d6c7e0-3478-4e93-bbea-a5c6411231b2%40chromium.org?utm_medium=email&utm_source=footer>.

[Hayato Ito]

Hi Emilio,

That's a good question. I think these :pseudo-class should work for both open and closed shadow roots because we'd prefer consistent behavior between custom elements (which has a closed shadow tree) and built-in elements.

For example, :focus should work for <video> elements or any other focusable built-in elements in Blink, even though, in technically, the most *deepest* focused element is an element in a closed shadow tree which a built-in element hosts.

We'd prefer consistent behavior as much as possible so that we can explain the platform by custom elements + (closed) shadow trees.

I know some people might claim that "this is a violation of encapsulation", however, given that no one has such a claim for built-in elements, I think this behavior makes sense. 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1865abec-5cc7-164f-3e09-dc01eef4cacf%40mozilla.com.

--

Hayato

[flo...@rivoal.net]

I see no problem with implementing this as an experiment, but if you feel it is ready to ship in production, it should probably exit incubation first and get broader review in a proper Working Group, maybe a pass through the TAG, etc. As it stands, the only +1 documented in this intent to ship is from Edge, which is also using blink, so that's not going very far in terms of cross vendor support.

This is not to say that there's anything wrong about the feature itself, but I think it would benefit from being socialized a bit more with other browsers vendors and the broader community before shipping.

—Florian

[Emilio Cobos Álvarez]

On 28/03/2019 03:48, Hayato Ito wrote:
> Hi Emilio,
>
> That's a good question. I think these :pseudo-class should work for both
> open and closed shadow roots because we'd prefer consistent behavior
> between custom elements (which has a closed shadow tree) and built-in
> elements.
>
> For example, :focus should work for <video> elements or any other
> focusable built-in elements in Blink, even though, in technically, the
> most *deepest* focused element is an element in a closed shadow tree
> which a built-in element hosts.
> We'd prefer consistent behavior as much as possible so that we can
> explain the platform by custom elements + (closed) shadow trees.
>
> I know some people might claim that "this is a violation of
> encapsulation", however, given that no one has such a claim for built-in
> elements, I think this behavior makes sense.

Is there an HTML spec issue for such proposal for :focus? Is this really
an issue for :focus given we have :focus-within, which works on the flat
tree?

I don't think such behavior makes sense for :fullscreen (nor for
:picture-in-picture). For example, the fullscreen spec defines an
user-agent stylesheet[1] that would break the layout of any shadow host
containing the fullscreen element if such a thing was implemented. I
don't think that's desirable nor makes much sense.

Also, it doesn't seem to make much sense to me to match :fullscreen for
some shadow host that has arbitrary content apart of the fullscreen
element, but maybe I could be convinced otherwise?

In any case this looks like a maybe broader issue that should probably
be discussed in the HTML or CSS specs.

-- Emilio

[1]:
https://fullscreen.spec.whatwg.org/#user-agent-level-style-sheet-defaults

> On Thu, Mar 28, 2019 at 1:01 AM Emilio Cobos Álvarez <emi...@mozilla.com
> <mailto:emi...@mozilla.com>> wrote:
>
> On 27/03/2019 16:33, François Beaufort wrote:
> > Contact emails
> >
> > fbea...@chromium.org <mailto:fbea...@chromium.org>

> <mailto:fbea...@chromium.org <mailto:fbea...@chromium.org>>,
> > mlam...@chromium.org <mailto:mlam...@chromium.org>
> <mailto:mlam...@chromium.org <mailto:mlam...@chromium.org>>

> <mailto:blink-dev%2Bunsu...@chromium.org>
> > <mailto:blink-dev+...@chromium.org
> <mailto:blink-dev%2Bunsu...@chromium.org>>.

> > To view this discussion on the web visit
> >
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/14d6c7e0-3478-4e93-bbea-a5c6411231b2%40chromium.org
> >
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/14d6c7e0-3478-4e93-bbea-a5c6411231b2%40chromium.org?utm_medium=email&utm_source=footer>.
>
> --
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1865abec-5cc7-164f-3e09-dc01eef4cacf%40mozilla.com.
>
>
>
> --
> Hayato
>
> --
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to blink-dev+...@chromium.org
> <mailto:blink-dev+...@chromium.org>.
> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFpjS_1LZfm1FMNeeUbGscJSDjp_JAodQatd-b6cOeKqZTas6w%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFpjS_1LZfm1FMNeeUbGscJSDjp_JAodQatd-b6cOeKqZTas6w%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Emilio Cobos Álvarez]

A potentially more reasonable definition for these pseudo-classes, if
you want that behavior, has to account for the tree you're matching
rules against, and the stylesheet origin of the rules.

For example, I'm pretty sure a change to :focus like what you're
proposing would be rather incompatible, since the default user-agent
rules for focused elements like:

:focus { outline: 1px solid dotted }

Would start matching all shadow hosts that contain a focused element.

But again, that's not something that I'd be confident in shipping
without more agreement with other engines.

-- Emilio

[Hayato Ito]

On Thu, Mar 28, 2019 at 11:50 PM Emilio Cobos Álvarez <emi...@mozilla.com> wrote:

On 28/03/2019 15:22, Emilio Cobos Álvarez wrote:
> On 28/03/2019 03:48, Hayato Ito wrote:
>> Hi Emilio,
>>
>> That's a good question. I think these :pseudo-class should work for both
>> open and closed shadow roots because we'd prefer consistent behavior
>> between custom elements (which has a closed shadow tree) and built-in
>> elements.
>>
>> For example, :focus should work for <video> elements or any other
>> focusable built-in elements in Blink, even though, in technically, the
>> most *deepest* focused element is an element in a closed shadow tree
>> which a built-in element hosts.
>> We'd prefer consistent behavior as much as possible so that we can
>> explain the platform by custom elements + (closed) shadow trees.
>>
>> I know some people might claim that "this is a violation of
>> encapsulation", however, given that no one has such a claim for built-in
>> elements, I think this behavior makes sense.
>
> Is there an HTML spec issue for such proposal for :focus? Is this really
> an issue for :focus given we have :focus-within, which works on the flat
> tree?

The spec is here. This section is not upstreamed to WHATWG HTML yet. I've found this issue.

My previous response was based on the assumption that there is an agreement on :fullscreen pseudo-class's current phrasing, however, it doesn't seem so.

>
> I don't think such behavior makes sense for :fullscreen (nor for
> :picture-in-picture). For example, the fullscreen spec defines an
> user-agent stylesheet[1] that would break the layout of any shadow host
> containing the fullscreen element if such a thing was implemented. I
> don't think that's desirable nor makes much sense.
>
> Also, it doesn't seem to make much sense to me to match :fullscreen for
> some shadow host that has arbitrary content apart of the fullscreen
> element, but maybe I could be convinced otherwise?
>
> In any case this looks like a maybe broader issue that should probably
> be discussed in the HTML or CSS specs.

It appears that we started a broader discussion here.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/eae4ba93-164a-e39e-69ca-681488fef4b7%40mozilla.com.

--

Hayato

[Mounir Lamouri]

Hi Florian,

I think your comment mostly applies to the Picture-in-Picture API, not to the CSS pseudo-class. The API has already launched in Chrome and has support from Microsoft, Mozilla, and Apple. We have had discussions around it multiple times (FOMS, TPAC, informal media f2f).

Furthermore, Blink launch process does not require APIs to be part of a working group and WICG with decent browser support is considered as good. This said, we are looking into having the API join a WG.

-- Mounir

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a3c6c4fb-31d9-4d45-be45-c4bb342750a7%40chromium.org.

[Rune Lillesveen]

On Thu, Mar 28, 2019 at 3:22 PM Emilio Cobos Álvarez <emi...@mozilla.com> wrote:

I don't think such behavior makes sense for :fullscreen (nor for
:picture-in-picture). For example, the fullscreen spec defines an
user-agent stylesheet[1] that would break the layout of any shadow host
containing the fullscreen element if such a thing was implemented. I
don't think that's desirable nor makes much sense.

Also, it doesn't seem to make much sense to me to match :fullscreen for
some shadow host that has arbitrary content apart of the fullscreen
element, but maybe I could be convinced otherwise?

Yes, wouldn't that be targeted more naturally with ::part?

E.g.:  movie-app::part(video):fullscreen {}

Note: Apparently, :fullscreen doesn't work with ::part() in Blink. Reported https://crbug.com/953648

[Chris Harrelson]

(API owner hat off in this response)

I don't think that :picture-in-picture should automatically apply to the shadow host chain (*). I suggest removing retargeting from that spec and also for the spec definition of :fullscreen.

Rune's suggestion about using :part also makes sense to me.

Chris

(*) Posted some thoughts at https://github.com/w3c/webcomponents/issues/804

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuPfeTK2gYAXEZT88CO%3DOxjYrSL%2B92WSL8GspQ-QvQ_8pqV3A%40mail.gmail.com.

[François Beaufort]

Thank you everyone for your feedback and answers!

I'm sending a spec PR at https://github.com/WICG/picture-in-picture/pull/126 that removes retargeting.

I'll also pinging fullscreen spec owners at https://github.com/whatwg/fullscreen/issues/149.

You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/X-qPSmdSR_g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9fZ6VVwhoiNAkgwWP6w3-xOQzy1HEL2G5HhNRBuSvu_g%40mail.gmail.com.

[Daniel Bratell]

Looks like nobody responded. Maybe mlamouri can take a look?

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEZxfGMtq8HpBjFjdkGVCt5e_Kb33O1-UzPpEjxULDkSD4LNkg%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */

[Mounir Lamouri]

The Picture-in-Picture spec has been updated.

[Chris Harrelson]

Great!

LGTM1

Would be good to also have a WPT test exercising the absence of retargeting, if there isn't already.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2B-LeH9YJn3wwJTF7QcjgHp7Ntsn-ZnwksN-%3DotQN4HNknwTXA%40mail.gmail.com.

[Yoav Weiss]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9ObSVmjePAO5JMUJQRCzi00VoHLCf%3DfvLwJdjYHKNyVw%40mail.gmail.com.

[Daniel Bratell]

LGTM3

/Daniel

[beaufort...@gmail.com]

Thank you. See answer inline.

On Friday, April 26, 2019 at 10:25:10 PM UTC+2, Daniel Bratell wrote:

LGTM3

/Daniel

On Fri, 26 Apr 2019 20:57:25 +0200, Yoav Weiss <yo...@yoav.ws> wrote:

LGTM2

On Fri, Apr 26, 2019 at 8:37 PM Chris Harrelson <chri...@chromium.org> wrote:

Great!

LGTM1

Would be good to also have a WPT test exercising the absence of retargeting, if there isn't already.

I've added one.

 

To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuPfeTK2gYAXEZT88CO%3DOxjYrSL%2B92WSL8GspQ-QvQ_8pqV3A%40mail.gmail.com.

--
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/X-qPSmdSR_g/unsubscribe.

To unsubscribe from this group and all its topics, send an email to blin...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9fZ6VVwhoiNAkgwWP6w3-xOQzy1HEL2G5HhNRBuSvu_g%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEZxfGMtq8HpBjFjdkGVCt5e_Kb33O1-UzPpEjxULDkSD4LNkg%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2B-LeH9YJn3wwJTF7QcjgHp7Ntsn-ZnwksN-%3DotQN4HNknwTXA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9ObSVmjePAO5JMUJQRCzi00VoHLCf%3DfvLwJdjYHKNyVw%40mail.gmail.com.

[Chris Harrelson]

On Thu, May 2, 2019 at 12:38 AM <beaufort...@gmail.com> wrote:

Thank you. See answer inline.

On Friday, April 26, 2019 at 10:25:10 PM UTC+2, Daniel Bratell wrote:

LGTM3

/Daniel

On Fri, 26 Apr 2019 20:57:25 +0200, Yoav Weiss <yo...@yoav.ws> wrote:

LGTM2

On Fri, Apr 26, 2019 at 8:37 PM Chris Harrelson <chri...@chromium.org> wrote:

Great!

LGTM1

Would be good to also have a WPT test exercising the absence of retargeting, if there isn't already.

I've added one.

Thanks!

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/012f8b0f-0844-4339-b84a-3853f76064f4%40chromium.org.

[François Beaufort]

Originally planned[1] to be shipped in Chrome 76, the ":picture-in-picture" CSS pseudo-class was disabled[2] in the same milestone as we thought we may need to revisit the design based on new features coming into the Picture-in-Picture API.

This is not the case anymore. For this reason we'll ship it in Chrome 110.

Note that the ":picture-in-picture" CSS pseudo-class has been implemented by Safari[3] since.

[1] https://chromiumdash.appspot.com/commits?commit=eb334058998fda433c4c910bf36d665082b30434
[2] https://chromiumdash.appspot.com/commits?commit=ac1159c89f4a93414d477fc47548afa563b0c612
[3] https://wpt.fyi/results/picture-in-picture/css-selector.html?label=experimental&label=master&aligned

[Yoav Weiss]

I think that reviving this 3.5 years later warrants getting LGTMs again, as the landscape may have changed.

With that said, LGTM1, as it seems this would now be catching up with Safari.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/afbe6975-b438-470c-890a-b05219c127bcn%40chromium.org.

[Mike West]

LGTM2, for the same reason.

That said, there are a number of open bugs against the repository. Have you done any triage against them to see whether any might be compatibility issues in the future? 

-mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUYJ%2BbcoRcR5EovQ%3Dy4iDseNGaKtPpbN-8MVouTZ%3DanGw%40mail.gmail.com.

[François Beaufort]

On Wed, Dec 7, 2022 at 10:23 AM Mike West <mk...@chromium.org> wrote:

LGTM2, for the same reason.

That said, there are a number of open bugs against the repository. Have you done any triage against them to see whether any might be compatibility issues in the future? 

Thanks for the reminder Mike.

I went through all of them (triage was overdue) and I'm happy to report there's no foreseen compatibility issue with this pseudo class.

[Mike Taylor]

Thanks for the triage effort. LGTM3.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPpwU5K5m%3DKS-FeYh9q2N2V0fX7EqTgP2Bg%2B7F-H2t3R-Lgd%3DA%40mail.gmail.com.