HTMLMediaElement controlsList

[beaufortfrancois]

Ya ya yawm TAG!

I'm requesting a TAG review of "HTMLMediaElement controlsList" to offer a way to control the native controls elements/buttons that are being shown by the user agent in order to be able to remove some features that do not make sense or are not part of the expected user experience or only allowlist a limited amount of features.

• Explainer¹: https://github.com/WICG/controls-list/blob/gh-pages/explainer.md
• Specification URL: https://github.com/whatwg/html/pull/6715 | https://wicg.github.io/controls-list/html-output/#attr-media-controlslist
• Tests: N/A at the time of writing
• Security and Privacy self-review²: https://github.com/WICG/controls-list/blob/gh-pages/security-privacy-questionnaire.md
• GitHub repo: https://github.com/WICG/controls-list
• Primary contacts (and their relationship to the specification):
  • François Beaufort (@beaufortfrancois), Google
  • Tommy Steimel (@steimelchrome), Google
• Organization(s)/project(s) driving the specification: Google
• Key pieces of existing multi-stakeholder review or discussion of this specification:
  • Intent to Prototype and Ship: noplaybackrate in HTMLMediaElement.controlsList in 2021
  • Intent to Implement and Ship: native media controls customization API in 2017
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status):
  • https://www.chromestatus.com/feature/5092414224072704
  • https://www.chromestatus.com/feature/5737006365671424

Further details:

• [x] I have reviewed the TAG's Web Platform Design Principles
• The group where the work on this specification is currently being done: WICG
• The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): unknown
• Major unresolved issues with or opposition to this specification:
  • https://github.com/whatwg/html/issues/2293#issuecomment-275749536
• This work is being funded by: Google

You should also know that...

• Chrome has shipped "HTMLMediaElement controlsList" in 2017.

We'd prefer the TAG provide feedback as:

🐛 open issues in our GitHub repo for each point of feedback

[LeaVerou]

Existing discussions for anyone digging in:

• https://github.com/whatwg/html/issues/2293
• blink-api-owners discussion
• Chrome's intent to ship

I see the first and the last are mentioned in the first post, but I think (?) not the second one, which is a very good discussion.

[plinss]

I want to take a step back here and ask what user need this is solving? I understand that site owners often want to restrict what users can do with media, but this seems to almost always be at the expense of the user, e.g. restricting the ability to download smells like DRM, restricting the ability to go fullscreen is an accessibility issue, etc.

I accept that site authors do restrict controls today, and they do it in ways that are even worse for the user, but isn't that a dark pattern? And are we doing the right thing by making dark patterns easier?

[torgo]

We discussed today bringing some more feedback into this issue from other implementers and other stakeholders. The lack of multi-browser support is worrying as well.

[hober]

From Gecko, we could ask @padenot for thoughts. For WebKit, @jernoble's been pretty vocal on this issue.

I wonder if @joncallas at the EFF knows who we should talk to over there about this.

[jernoble]

Hello TAG! The TL;DR of my feedback is that the primary use case for this feature ("nodownload") is Chromium-specific, and that ancillary use cases ("nofullscreen", hypothetical future controls) are both user-hostile and unnecessary.

• "nodownload": The explicit use case is to remove a button from the default media controls provided by Chromium and only by Chromium (edit: it has been pointed out that Opera on Android also provides a download button). If this were its own attribute, it could be safely ignored by other UAs–much like the playsinline attribute–but as the current proposal requires a new, separate attribute, the primary, Chromium-only use case does not itself justify the addition of controlsList.
• "nofullscreen": This use case is, IMO, both user hostile and unnecessary. The justifications provided for blocking the ability for users to take a video (with controls) into a fullscreen mode are all user-hostile. Sites that really, really want to block fullscreen can rely on UAs adhering to the existing "fullscreen" Feature Policy.
• hypothetical future additions: This is the opposite of a use case, IMO, and "making it easier to standardize new tokens in the future" begs the question that those additions would be useful, desirable, and not user hostile in the first place. On the contrary, for each of the existing controls in WebKit's native controls, selectively removing those controls would be user hostile: we do not want sites to easily, e.g., prevent users from muting audible content, prevent users from pausing content, prevent users from skipping ahead or backwards, or prevent users from entering picture-in-picture mode.

Since the existing use cases are either UA-specific, user hostile, and/or unnecessary, and hypothetical future use cases are both hypothetical and hypothetically user hostile, we do not support the controlsList proposal.

[LeaVerou]

If we are bringing in folks that have been vocal on other discussions about this feature, we should probably invite @avayvod and @foolip to represent the reasoning for this feature, as I personally found their arguments in other discussions quite compelling, and it is only fair to have representation from a variety of stakeholders and viewpoints.

[liberato-at-chromium]

Hello, all. First post, please point out but forgive any rough edges in my etiquette. :)

Also, for full disclosure (and in case my username isn't clear!), I work on chrome as my day job.

Anyway, this option seems, to me, like a way to allow sites to continue to use native controls rather than custom controls. That seems like a win for the user.

In particular, if a site wants to prevent download / fullscreen / mute / whatever, it can always do so simply by not requesting the native controls. Then the user is more or less stuck with whatever the site provides via js. Even providing the user with the option to enable the default controls isn't guaranteed to work; it's easy for the site to block them.

On the other hand, if the site is willing to use the native controls, but prefers turning some of the features off by default, then it seems like a solid win for the user over the alternative. The UA has enough information to let the user override the site's preference, and the controls should continue to work the way they always do.

Whether the site's goal is pseudo-DRM or just space management on a tight layout, I'm not sure it matters. "native" vs "custom" seems like the key difference to my (admittedly) untrained eye.

[beaufortfrancois]

I may add that the controlsList attribute provide hints as specified in the spec PR.

For instance, Chrome allows users to show all controls in <video> and <audio> elements, including the ones hidden with the controlsList HTML attribute from a "Show All Controls" context menu. See https://twitter.com/quicksave2k/status/1422941722993115141

[Malvoz]

(Off topic)

@beaufortfrancois:

Chrome allows users to show all controls in <video> and <audio> elements

Unless browsers decide to include media elements in the default focus order (regardless of the presence of the controls attribute) I don't think there's a way for keyboard-only users to open that context menu.

[atanassov]

Hi @beaufortfrancois, thank you for your patience working with us for so long. We see a lot of good arguments either way and on the back of many discussions we unfortunately couldn't come to consensus. We are not encouraging nor discouraging further work on this feature. This is to say that at this point we feel we are at the point of diminishing returns and are moving forward with closing the review. Again, thank you for working with us and as always, please let us know if you need any further help.