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

192 views
Skip to first unread message

Jaeyong Bae

unread,
Apr 12, 2021, 8:47:32 PM4/12/21
to blink-dev
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

unread,
Apr 13, 2021, 3:04:16 AM4/13/21
to Jaeyong Bae, blink-dev
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

unread,
Apr 14, 2021, 7:25:28 AM4/14/21
to Anne van Kesteren, Jaeyong Bae, blink-dev
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

unread,
Apr 18, 2021, 1:12:43 AM4/18/21
to blink-dev, Anne van Kesteren
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

unread,
Apr 18, 2021, 1:13:29 AM4/18/21
to blink-dev, Manuel Rego Casasnovas
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

unread,
Apr 23, 2021, 12:33:40 PM4/23/21
to Romederful, blink-dev, Manuel Rego Casasnovas
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.
Reply all
Reply to author
Forward
0 new messages