Intent to Prototype and Ship: noplaybackrate in HTMLMediaElement.controlsList

[François Beaufort 🇫🇷]

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 🇫🇷]

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

[Chris Harrelson]

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 🇫🇷]

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.

I've just filed https://github.com/mozilla/standards-positions/issues/534.

 

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]

Thanks!

LGTM1

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

[Yoav Weiss]

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@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.

--
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]

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.