Intent to Prototype and Ship: noplaybackrate in HTMLMediaElement.controlsList

141 views
Skip to first unread message

François Beaufort 🇫🇷

unread,
May 26, 2021, 12:08:40 PMMay 26
to blink-dev

Contact emails

fbea...@chromium.org 

ste...@chromium.org


Explainer

https://github.com/wicg/controls-list/blob/master/explainer.md

Spec

HTML Spec PR: https://github.com/whatwg/html/pull/6715

Preview: https://wicg.github.io/controls-list/html-output/#attr-media-controlslist-noplaybackrate


TAG review

N/A. This is adding another value to an existing attribute, so not a significant change to the API shape.


Summary:
Offers a way for the website to enable/disable the playback speed control exposed by the browser in native media controls.


Motivation:
With browser vendors adding playback speed control to their native media controls, developers want to control the visibility of this new control.


Using the existing HTMLMediaElement.controlsList attribute, developers can enable/disable the visibility of the playback speed control with the new token “noplaybackrate”.


// Playback speed control is visible.

<video controls>


// Playback speed control is hidden.

<video controls controlslist="noplaybackrate"></video>


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

Yes

Demo link

https://googlechrome.github.io/samples/media/controlslist-noplaybackrate.html


Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1211336


Measurement

The HTMLMediaElementControlsListNoPlaybackRate WebFeature will track the presence of the "noplaybackrate" token.


Risks


Interoperability and Compatibility
This new token does not change the overall status of native media controls customization API interoperability or compatibility. 


Signals from other implementations (Gecko, WebKit): 

Gecko: No Signal [1]

WebKit: No Signal [1]

Web / Framework developers: No Signal (An internal business partner would like to completely get rid of the three-dots menu to save screen real-estate).


[1] Both Gecko and Webkit are unlikely to object to this specifically, but object to the overall native media controls customization API as a whole, hence it doesn't make sense to bug them with specific questions on this. See https://github.com/whatwg/html/pull/2426

Activation:

It should be fairly trivial for developers to adopt this feature thanks to DomTokenList.supports() which can be used for detection of whether the “noplaybackrate” token is supported or not.

const video = document.querySelector('video');

if (video.controlsList.supports('noplaybackrate')) {

  video.controlsList.add('noplaybackrate');

}


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

We’ll try to add tests to check DomTokenList controlsList behaviour as there was none in https://wpt.fyi/results/html/semantics/embedded-content/media-elements


Entry on the feature dashboard

https://www.chromestatus.com/feature/5092414224072704


François Beaufort 🇫🇷

unread,
May 27, 2021, 12:10:48 PMMay 27
to blink-dev
WebKit actually expressed opposition to this feature. See https://github.com/whatwg/html/pull/6715#issuecomment-848110291

Chris Harrelson

unread,
May 27, 2021, 4:24:20 PMMay 27
to François Beaufort 🇫🇷, blink-dev



Signals from other implementations (Gecko, WebKit): 

Gecko: No Signal [1]

WebKit: No Signal [1]


WebKit actually expressed opposition to this feature. See https://github.com/whatwg/html/pull/6715#issuecomment-848110291

I agree that there isn't a need to email webkit-dev again given this opposition. However: (*)

What about Mozilla though? Is there an official Mozilla standards position issue for this API? If not, please file one.

Also, was the original feature reviewed by the TAG? If so, please link to the TAG review. If not, then I think it would benefit from one.

(*) While I'm not implying you personally have to do something as part of this intent: it seems like the concern raised here (the download example in particular) could be worked out somehow to everyone's satisfaction. For example, maybe we could present evidence that the risk mentioned there does not happen in practice, because developers don't in reality use .supports() as a proxy for "safe to show without unauthorized download risk".

Web / Framework developers: No Signal (An internal business partner would like to completely get rid of the three-dots menu to save screen real-estate).


[1] Both Gecko and Webkit are unlikely to object to this specifically, but object to the overall native media controls customization API as a whole, hence it doesn't make sense to bug them with specific questions on this. See https://github.com/whatwg/html/pull/2426

Activation:

It should be fairly trivial for developers to adopt this feature thanks to DomTokenList.supports() which can be used for detection of whether the “noplaybackrate” token is supported or not.

const video = document.querySelector('video');

if (video.controlsList.supports('noplaybackrate')) {

  video.controlsList.add('noplaybackrate');

}


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

We’ll try to add tests to check DomTokenList controlsList behaviour as there was none in https://wpt.fyi/results/html/semantics/embedded-content/media-elements


Entry on the feature dashboard

https://www.chromestatus.com/feature/5092414224072704


--
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/CAPpwU5LS9U_17YP_9V0U1%2B_j-SVWUzdWWWp_gZeED4whiNUCbw%40mail.gmail.com.

François Beaufort 🇫🇷

unread,
Jun 3, 2021, 6:02:36 AMJun 3
to Chris Harrelson, blink-dev
On Thu, May 27, 2021 at 10:24 PM Chris Harrelson <chri...@chromium.org> wrote:



Signals from other implementations (Gecko, WebKit): 

Gecko: No Signal [1]

WebKit: No Signal [1]


WebKit actually expressed opposition to this feature. See https://github.com/whatwg/html/pull/6715#issuecomment-848110291

I agree that there isn't a need to email webkit-dev again given this opposition. However: (*)

What about Mozilla though? Is there an official Mozilla standards position issue for this API? If not, please file one.

 
Also, was the original feature reviewed by the TAG? If so, please link to the TAG review. If not, then I think it would benefit from one.

The original feature was not reviewed by the TAG in 2017. I've now filed one at  https://github.com/w3ctag/design-reviews/issues/643

(*) While I'm not implying you personally have to do something as part of this intent: it seems like the concern raised here (the download example in particular) could be worked out somehow to everyone's satisfaction. For example, maybe we could present evidence that the risk mentioned there does not happen in practice, because developers don't in reality use .supports() as a proxy for "safe to show without unauthorized download risk".

FWIW I've found no occurrences of "controlsList.supports" when searching HTTP Archive with BigQuery.

Chris Harrelson

unread,
Jun 3, 2021, 3:20:03 PMJun 3
to François Beaufort 🇫🇷, blink-dev

Yoav Weiss

unread,
Jun 3, 2021, 3:22:10 PMJun 3
to blink-dev, Chris Harrelson, blink-dev, François Beaufort
LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.

Daniel Bratell

unread,
Jun 3, 2021, 3:23:46 PMJun 3
to Yoav Weiss, blink-dev, Chris Harrelson, François Beaufort

LGTM3

/Daniel

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/18a64f87-3d6d-48ac-9439-5a7d5c48c79en%40chromium.org.
Reply all
Reply to author
Forward
0 new messages