Allow webauthors to customize what controls are shown for HTMLMediaElement

[avayvod]

The full explainer is here: https://docs.google.com/document/d/1dVPuL8UznIyhYn1KCnaMT7GRJFvDerSgqaUQhSiiY3Y/edit#heading=h.lqqvomsdg9jx

TL;DR allow websites do something like:

<video controls="nofullscreen nodownload"></video>

var v = document.querySelector("video");
v.controls;  // true
v.controlsList; // "nofullscreen nodownload"
v.controlsList.add("noremoteplayback"); 
v.controlsList; // "nofullscreen nodownload noremoteplayback"

CC @jernoble @foolip @mounirlamouri

I'm happy to prepare a PR.

[domenic]

This seems like a pretty cool idea. What are the main open issues you are thinking need to be discussed and agreed upon between vendors? (We'd need multi-vendor interest before a pull request can be accepted, but working on one is never a bad idea to concretize things.)

From skimming the doc my impression is that the open questions are:

• What are the keywords? The doc doesn't seem to have a comprehensive list. So far I spotted nofullscreen, nodownload, noremote, but the doc kind of implies that there might also be noplay, nopause, nofastforward, etc.?
• Will safelisting be included in the initial proposal, or only blocklisting?
• What is the exact behavior if you blocklist all controls the UA offers?

Also pinging @annevk and @travisleithead to see if they can find some Gecko/Edge people for their take on this proposal.

[avayvod]

Hi Domenic!

Thanks for the feedback.

The MVP would be just supporting three keywords: nodownload, noremoteplayback, nofullscreen - so blacklisting only, and only for these specific features.

Keywords unsupported by the UA would be ignored when added/set.
DomTokenList.supports() would be used for detection of whether keyword is supported or not.

Whitelisting is a potential addition we didn't want to take off the table because it potentially helps more pages use the default controls (supporting even one play/pause button across browsers could be tricky considering various edge cases).

However it brings issues like conflicts between white- and black- listing the same features (more of a spec issue) or keeping the unmaintained sites up-to-date as new features and controls come along (more of a practical issue). Thus I'd say whitelisting support is lower priority than blacklisting.

Finally, if the site blacklists all controls I don't think it's any different as not setting controls at all. However, it means that if the UA adds a new control that's shown by default, it will be shown.

[Yay295]

Would this include context-menu options, or only the options directly visible on the screen?

[avayvod]

Just the media element's controls.

[mounirlamouri]

/CC some Media Mozilla folks @cpearce @cpeterso @jyavenard @kentuckyfriedtakahe

[foolip]

I think this is a nice and simple proposal 👍

As with classList/className, there will be two IDL attributes reflecting the same content attribute, which is unusual, but it makes good sense both when looking at the markup and the API.

[jernoble]

I don't see how this proposal is necessary. There is no example in the explainer of a situation in which it would be confusing to have a play button, timeline, audio controls, but not a fullscreen button. It's much more likely that this feature will be used by sites like YouTube to disable a highly useful feature (fullscreen) in their embedded player.

This feature would make our users' playback experience objectively worse, not better.

[avayvod]

@jernoble

Hi Jer,

Could you please clarify why there needs to be an example when it's "confusing to have a play button, timeline, audio controls, but not a fullscreen button"?

Note that the websites already can disable all the media controls already and implement their own and they do. There might be obligations to content owners w.r.t download or remote playback or some buttons might just not make sense, like the volume button for a video-only looped animation.

I argue that because the websites have to use the custom controls already even if they just need to disable one button and also because making custom controls work well across browsers and devices is hard, the user experience can only be better if the websites instead use the default controls with the selected button set.

To summarize, there's nothing added in the proposal that the websites can't achieve already with custom controls, it would just make it easier for web developers without breaking users with bad custom controls implementations.

[jernoble]

@avayvod

Could you please clarify why there needs to be an example when it's "confusing to have a play button, timeline, audio controls, but not a fullscreen button"?

Because that's your proposed use case? Without such an example, there's no justification for adding this feature.

Note that the websites already can disable all the media controls already and implement their own and they do

And that's exactly why this proposal is entirely unnecessary.

[I]t would just make it easier for web developers without breaking users with bad custom controls implementations.

Indeed, but if sites want to add maladaptive playback behavior (by disabling platform features like fullscreen playback) they should be forced to do the heavy lifting themselves.

[jernoble]

Additionally, the use case for "noremote" is already covered in the Remote Playback API: Disabling Remote Playback.

[mounirlamouri]

@jernoble, this proposal isn't pushed by the fullscreen use case. Actually, I added nofullscreen to the proposal for completeness because it is one of the button user agents add without any control from the website. Some websites might find the button out of place. For example, an animated gif presented as a video or an ad might not really need a fullscreen button. Requesting websites to re-implement the entire controls to get ride of one part doesn't sound very optimal for the platform.

The intent behind the feature is that every time we've added buttons in the native controls we got feedback from websites interested to disable them. We believe that it shows an interest to use the native controls but still be able to control the user experience. We considered something similar for remote playback but finally ended up adding an attribute to disable the feature (more powerful than disabling the button). We recently received strong feedback when Chrome added a download button to its native controls: for various reasons websites didn't like/want the button.

There are other features that browsers are starting to implement such as picture in picture (Opera, Safari, Firefox) and we believe there might be similar push back from websites to remove the button from the native controls. We want to be proactive and have a solution for websites interested to disable the feature.

We do not believe that switching to custom controls is the solution when a website wants to customise part of the native controls. Native controls can be a better experience for the users than custom controls because they are tailored for the browser (custom controls have to be cross-browser), the platform (custom controls might not always work well in all form factors), and they follow accessibility rules. Native controls also receive new features (remote playback, picture in picture, ...) when they become available to the platform. Finally, native controls allow a browser to create an opinionated user experience for their users.

Note that the proposal doesn't require all user agents to support the removal of all the keywords. The supports() method on the DOMTokenList can be used to feature detect the support of a given keyword. If WebKit doesn't want to allow websites to disable the fullscreen button or the download button, it can simply advertise so via the supports() method.