Intent to Implement and Ship: Implement :playing, :paused pseudo-classes

[Jaeyong Bae]

Contact emails
jdrag...@gmail.com

Feature summary
The :playing pseudo-class represents an element representing an audio, video, or similar resource that is capable of being “played” or “paused”, when that element is “playing”.
The :paused pseudo-class represents the same elements, but instead matches when the element is not “playing”.

Motivation
Which collectively address the use case of a custom "play/pause" media control which should appear as a play button or as a pause button depending on the current play state of the associated media element.

Is this feature fully tested in Web Platform Tests?
No, not yet.

Tracking bug URL
https://bugs.chromium.org/p/chromium/issues/detail?id=1176947

Spec link
https://www.w3.org/TR/selectors-4/#video-state

TAG Review
Not needed since it's an existing spec discussed.

Interoperability and Compatibility Risks
Compatibility:
For the <audio> element Chrome already exposes this state internally by means of a class .state-playing / .state-paused on the ::-webkit-media-controls pseudo element.

Interoperability:
Firefox: No signal
Safari: No signal
Edge: No signal
Web developers: No signal

Link to entry on the Chrome Platform Status
https://chromestatus.com/features/6299876096737280

[Anne van Kesteren]

On Tue, Apr 13, 2021 at 2:47 AM Jaeyong Bae <jdrag...@gmail.com> wrote:
> Spec link
> https://www.w3.org/TR/selectors-4/#video-state

This looks like a neat feature, but unfortunately this isn't
sufficient. The HTML Standard needs to define when this matches the
relevant elements in terms of their internal state as it does for
:checked et al as well.

[Manuel Rego Casasnovas]

Apart from working on the spec side as mentioned by Anne, it looks like
we have ask for signals to other vendors (https://bit.ly/blink-signals)
and investigate web developers signals (https://goo.gle/developer-signals).

On to top of that we need to work on the WPT tests before shipping.

Maybe it's worth implementing this behind a runtime flag and send and
intent to ship once the other issues are solved. WDYT?

Cheers,
Rego

[Romederful]

This looks like a neat feature, but unfortunately this isn't

sufficient. 

Thanks Anne! I understand what you said. Ack.

2021년 4월 13일 (화) 오후 4:04, Anne van Kesteren <ann...@annevk.nl>님이 작성:

[Romederful]

Maybe it's worth implementing this behind a runtime flag and send and

intent to ship once the other issues are solved. WDYT?

Sounds good to me. First, I try to implement this behind a runtime flag! 
Thanks for your opinion. Rego.

2021년 4월 14일 (수) 오후 8:25, Manuel Rego Casasnovas <re...@igalia.com>님이 작성:

[Mike West]

Great! We discussed this briefly in the API owners' meeting, and decided to consider this an "Intent to Prototype" thread. Landing an implementation behind a flag, and proceeding with specification sounds great!

We're looking forward to an eventual "Intent to Ship"! 

-mike

--
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/CAOhF%3Dqyk%3DzBdB3Lbe7B%2BnLDGjU7Mbkn%3D2emPMdFtLENci%3DHFDA%40mail.gmail.com.