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.

[jernoble]

@mounirlamouri

We want to be proactive and have a solution for websites interested to disable the feature.

And we (Apple) receive more complaints from our users about "fullscreen / picture-in-picture don't work on this website" than we do from websites wanting to disable those controls. In the end, we are a User Agent, not a Website Agent.

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.

I agree! And it's especially irksome when websites refuse to add support for those platform features in their custom controls.

Finally, native controls allow a browser to create an opinionated user experience for their users.

And in my opinion, the default controls should always have a fullscreen button (and a Picture-in-Picture button).

[jernoble]

Additionally, I think this example is very disingenuous:

@mounirlamouri

For example, an animated gif presented as a video or an ad might not really need a fullscreen button.

An animated gif has much less need for a timeline slider or a pause button than it does a fullscreen button. But you're not proposing allowing websites to remove those.

Anecdotally, I literally used both fullscreen and remote playback from the default controls for a "gifv" video yesterday. Your proposal would allow websites to (much more easily) break that use case.

[graouts]

It seems that at least part of the motivation behind this proposal is to better serve content that is encoded as a video but is not a "traditional" linear video, but rather an animation GIF-like looping video, or something else.

With that in mind, why not let content authors specify the nature of the video content and let the user agent provide a desirable set of controls to match? This is not an actual proposal, but something like

I'm not in support of an API as suggested here, I think it's rife for abuse by content authors who could disable useful features that the end-user relies on. If what we're after is to provide a better set of controls for certain type of video content, I think a descriptive approach rather than an API can get us where we want.

[avayvod]

@graouts how would we decide what video content types to support? It's better for the web platform to provide tools to the web authors to do what they want vs. limiting them to what the UA thinks is best.

Based on the conversation above, it seems like Mounir and Jer would prefer different sets of controls for "animation" content type which would result in the web being less predictable for the web developers in the end.

@jernoble disableRemotePlayback does more than just remove the button, it disables the whole feature.

One of the reasons for a generic approach is that we could keep adding ```disableDownload`` and so on but that doesn't scale well.

W.r.t. no volume and seek, the proposal allows that, although we're might not ship it in the MVP in Chrome.

Also note that the proposal doesn't prevent the UA from providing some other UI to trigger the feature, like context menu or the browser chrome - so UA can allow users to override the site's choice.

[jernoble]

@avayvod

@jernoble disableRemotePlayback does more than just remove the button, it disables the whole feature.

Indeed, it does. The only reason to spec both of these separately, then, is for the extremely narrow use case where:

1. A website wants to use the default controls.
2. But doesn't want to allow those controls to initiate remote playback.
3. But does want to provide a custom UI for initiating remote playback.

So beyond the obvious problem that such a website would provide an objectively worse user experience than just allowing the remote playback button to appear in the default controls, and that such a website could just implement their own custom playback controls, why is this use case worth speccing?

[jernoble]

Also:

@avayvod

It's better for the web platform to provide tools to the web authors to do what they want vs. limiting them to what the UA thinks is best.

The web platform does provide web authors the ability to do what they want: custom controls.

[avayvod]

@jernoble

But does want to provide a custom UI for initiating remote playback.

Not necessarily. I think the website might not want to advertise remote playback support at all because, for example, it's a 6s video-only looped stream or a 240p mobile optimized video that will look terrible on a 4K TV. At the same time, for such content in particular, I doubt the website would have external obligations to forbid remote playback at all via other means if the user really wants that.

Similar argument can be applied to fullscreen: on large screens the site might use "nofullscreen" to avoid showing users content in low quality.

The web platform does provide web authors the ability to do what they want: custom controls.

Here I argued against the predefined content types proposal that would not follow the extensible web principles. The original proposal doesn't go against the extensibility, it expands the customization of media controls, potentially helping the web developers to bring better experience to users with less overhead.

[jernoble]

@avayvod

Not necessarily. I think the website might not want to advertise remote playback support at all because, for example, it's a 6s video-only looped stream or a 240p mobile optimized video that will look terrible on a 4K TV. At the same time, for such content in particular, I doubt the website would have external obligations to forbid remote playback at all via other means if the user really wants that.

1. From the user's point-of-view, not providing a button for initiating remote playback is effectively disabling the feature entirely.
2. This entire line of argument is problematic. "It might look bad" is not a valid justification for disabling a UA-provided feature. The correct answer to "it might look bad when displayed remotely/fullscreen" is to switch to a higher-quality stream, not to disable remote playback or fullscreen.

[mounirlamouri]

@graouts your assumption that we are mostly targeting video as images is incorrect. As said above, the main reason why we are pushing this is for websites that do not want a download button in their controls. The other buttons are added because we believe that they might be interesting for websites to customize. The list was basically taken from the list of all the buttons that are currently added by Blink in the native controls with the exceptions of closed captions (for obvious reasons). Removing volume button, the slider and all could be added but we didn't add it in the examples because we don't think it makes sense to add them to the spec if no browser intends to implement it at the moment. Blink has no interest for this as of yet. We would be happy to add any keywords that are interesting to other user agents.

@jernoble I and the Chrome team understand that users want access to the new features of their platform. The comment you made about picture in picture is true and we definitely hear the same feedback when native controls receive new features in Chrome too. Chrome Android shows a huge overlay cast button for this. Firefox picture in picture current experiment is also an overlay. However, we believe that to improve the platform, we must provide a way for websites to better customize the native controls. Otherwise, a website that is slightly opinionated about their controls would need to reimplement their own, making any improvement of the platform very hard to incorporate.

As much as I agree that websites shouldn't disable a UA provided feature, they already can by simply not exposing controls and expose their own instead. Chrome metrics currently show that on desktop native controls are rare and on mobile, usage of native controls is shrinking. The situation we want to avoid is that the opinionated native controls the browser provide only affects an insignificant fraction of media played on the Web. We believe that one path that will help this goal is to offer flexibility for websites that have specific needs.

[foolip]

@jernoble, would you be comfortable with adding a "download", "watch later", "watch offline" or similar feature to Safari's controls without a way to remove them? This is the situation that Chrome for Android is now in, having added a download feature and getting rather a lot of negative feedback from web developers.

[philzepeda]

I strongly urge this functionality to be added - particularly the MVP proposal of nodownload, noremoteplayback, no fullscreen (though nodownload would be the most crucial). As a content publisher, forcing a download button with no ability to disable/hide is a blocker for using a raw HTML5 video element. This is problematic for any content publisher, whether it's a large media site or a small blogger/creator. And not everyone has the resources to create and implement their own custom controls, so you have no added a barrier to entry for these people to use native HTML5 video.

All of the comments so far seem to be one-sided from the viewer's point of view, and not taking the creator of the content or website into account.

[graouts]

I don't have an objection over nodownload but I really think options affecting fullscreen, remote (AirPlay for macOS and iOS) or detached (picture-in-picture for macOS and iOS) playback shouldn't be given as an option unless the spec also guarantees that the user agent also provides ways for the user to opt into respecting those options, but by default disregarding them such that users aren't negatively affected.

As you note @philzepeda, I do have a bias over protecting end users here because I think content providers already have other avenues to customise controls and already often provide their own, branded controls. I realise that not all content providers have the same resources to achieve this, although there are some great off-the-shelf solutions to create custom controls at a low technical cost, but user experience is paramount in my opinion.

[avayvod]

@graouts

shouldn't be given as an option unless the spec also guarantees that the user agent also provides ways for the user to opt into respecting those options, but by default disregarding them such that users aren't negatively affected.

I don't see something like a user setting in a spec, except for maybe a recommendation note. Whether this to be an opt-in or opt-out seems like a product decision. The proposal as is allows feature detection of each keyword using DOMTokenList.supports() which could return false if 'nofullscreen' is ignored.

No controls can usually be overridden with the default context menu, I don't see why that could also be a way to override the site preference.

The real risk we're trying to address is well summarized by @mounirlamouri (and I apologize for diverting the discussion towards the single animated GIF example): the more features we add to the default controls, the more incentives there're for web authors to disable all of them and use custom controls. It might be that at some point adding new buttons to the default controls won't make sense at all because of very low usage. The proposal is about finding the middle ground.

[philzepeda]

@graouts agreed, nodownload is the one I see as most important/beneficial.

[jernoble]

So far, the only concrete use case provided is that site authors want to disable the download button; something that is itself not specified and is in fact only implemented by one browser, Chrome. The other two proposed values of the controlsList ("noremote" and "nofullscreen") either already have a specced mechanism, or have no concrete use case, respectively.

What's left, then, is a proposed specification where the only valid value is controls="nodownload", the only browser it would affect is Chrome. So why isn't this just a <video x-chrome-nodownload> attribute?

[foolip]

@jernoble @kentuckyfriedtakahe, from previous comments it's clear that you'd be more comfortable with a specific attribute like disabledownload. Would this be acceptable even with a reflected disableDownload IDL attribute, or is it predicated on making it impossible to feature detect?

If a feature-detectable disabledownload is more palatable, would establishing a pattern of such attributes be acceptable too? In other words, if we see evidence of web authors putting their videos inside allowfullscreen-less iframes just to get rid of the fullscreen button, we'd add a disablefullscreen attribute.

What I'm trying to tease out here is if the friction of adding more knobs looks like a feature to you, or if it's some other aspect (like feature detection) that's the primary sticking point.

[avayvod]

@jernoble

I don't see a counter argument to my statement quoted below:

But if the UAs force web developers to switch custom controls, they will all switch sooner or later because there's no other option and they often have hard content restrictions to support. And then all the UAs will be able to do is to invest into custom controls libraries and all changes to the default controls will be useless.

Do we agree on this and if not, why?

[jernoble]

@foolip I don't see why this feature needs to be feature-detectable. It's clear that Chrome wants it to be, but I haven't seen argument presented besides "we know best". That said, I would be more comfortable with a feature-detectable nodownload attribute if Chrome managed to make their download button feature-detectable in the first place. Otherwise, the nodownload attribute places an ongoing burden on UAs who never had a download button.

re: disablefullscreen, why would allowfullscreen on an iframe apply to native fullscreen controls?

[jernoble]

@avayvod No, I don't agree that, by not allowing sites to blacklist individual native controls, every site will implement custom controls. And even if this were true, it doesn't follow that the best way to combat this scourge of user-hostile custom controls is to make native controls user-hostile as well.

Let me pull out this piece specifically:

[...] there's no other option and they often have hard content restrictions to support.

Can you give an example of a "content restriction" which would require the content not be viewed in fullscreen mode? More likely, sites have revenue reasons for blocking fullscreen: native fullscreen strips off overlay advertising. I'd argue that the overwhelmingly common use case of this feature would be to extract revenue from users through ads. Do we agree on this?

[avayvod]

@jernoble w.r.t. feature detection @domenic presented the following arguments in the blink-api-owners-discuss thread (option 2 is having a non-feature detectable attribute):

it cannot be used from popular web frameworks like React (used notably by Facebook, which is one of the potential consumers of this API). React and other frameworks like it have no way to directly set attributes, only properties. Since option 2 breaks with the tradition that all attributes are reflected as properties, it cannot be used in such settings.

Also:

Can you give an example of a "content restriction" which would require the content not be viewed in fullscreen mode? More likely, sites have revenue reasons for blocking fullscreen: native fullscreen strips off overlay advertising. I'd argue that the overwhelmingly common use case of this feature would be to extract revenue from users through ads. Do we agree on this?

I imagine the restriction to be 'no ads - no video for your page'?
I think our proposal could allow UAs to ignore the page preference in favor of the user (as an example, if the page specifies nofullscreen but the screen is considered to be small). WDYT?

No, I don't agree that, by not allowing sites to blacklist individual native controls, every site will implement custom controls.

Could you support this belief?
What would the best way to combat the scourge of user-hostile custom controls be then?

[jernoble]

@avayvod re: React, we shouldn't make permanent design decisions based on the inability of one JavaScript framework to work with common web technologies. I consider React's inability to set attributes to be a bug in React.

I imagine the restriction to be 'no ads - no video for your page'?

That's not a content restriction. The content owners want their content to be seen; the page owners want their ads to be seen. These two things are in conflict. So restricting fullscreen playback would be a business decision by the site (by requiring their ads to be seen atop the content). A content restriction would be, e.g., "the content license restricts playback outside of the UK", "only through a CDM supporting a certain level of robustness", or "only over an HDCP-protected playback path".

Could you support this belief?

Sure. We don't allow disabling individual controls now, and there are still websites that use native controls. QED.

What would the best way to combat the scourge of user-hostile custom controls be then?

I dunno, perhaps by making native controls better? Then, websites benefit, users benefit, and everyone's happy!

[Yay295]

Since no-one's mentioned it yet, I've used custom controls not because I wanted to restrict functionality, but because the native controls just don't fit the webpage's theme. I don't think this is something that can be fixed either, because if you let websites change how the native controls look, it defeats the purpose of having distinguishable controls. My point is that even if you work something out here, some websites will still use custom controls just to make them look different.

[avayvod]

@jernoble

Sure. We don't allow disabling individual controls now, and there are still websites that use native controls. QED.

Safari didn't allow custom controls until playsinline was added either (on phones at least)? What will happen when Safari actually tries to add a new feature to the controls?

I dunno, perhaps by making native controls better? Then, websites benefit, users benefit, and everyone's happy!

Better in what way? It's not easy to make everyone happy. I'm sure users are happy to be able to download videos when they don't have access to cheap and fast internet while websites are not very happy about the high visibility of it. I don't know much about Safari's history but x-webkit-airplay was presumably added for similar reasons: does AirPlay feature makes controls more useful - yes, would it make websites switch to custom controls if allowed at the time without the opt-out attribute - very likely.

That's not a content restriction.

Fine. The site will still switch to custom controls if they want ads to work. In fact, switching itself to custom controls to disable something in the default controls doesn't look very hard. Making the custom controls work well probably is. As a result, users suffer.

@Yay295

I've used custom controls not because I wanted to restrict functionality, but because the native controls just don't fit the webpage's theme

We'd love to add a functionality allowing customizing default controls in other ways later - perhaps by specifying the color theme somehow. That's out of scope of this issue though I'm happy to gather requirements separately.

[jernoble]

@avayvod

Safari didn't allow custom controls until playsinline was added either (on phones at least)?

But it has always allowed custom controls on iPad and desktop, and sites still use native controls there as well.

I don't know much about Safari's history but x-webkit-airplay was presumably added for similar reasons: does AirPlay feature makes controls more useful - yes, would it make websites switch to custom controls if allowed at the time without the opt-out attribute - very likely.

Well then, some history:

Actually, the x-webkit-airplay attribute only incidentally disables the native AirPlay button; it disables AirPlay completely for that element, and it's necessary even for videos with custom controls due to the way AirPlay routing works on iOS: the user can choose a global route which affects all video playback. Opting out of AirPlay with x-webkit-airplay="deny" keeps the video from automatically routing to the remote display when the user chooses a non-local route. The fact that it also disables the AirPlay button is only a side-effect of disabling remote playback.

So switching to custom controls wouldn't solve this issue in the absence of a "disable remote playback of this element" feature.

(As an aside, in this case, there is an actual content restriction use case, since some content will be licensed only to be playable on the user's local machine, and the license explicitly disallows playback on a remote machine on which the user has not explicitly logged in with their credentials.)

The site will still switch to custom controls if they want ads to work.

And we should not add to the HTML spec features whose only use case is to make advertising more valuable.

[avayvod]

@jernoble

So switching to custom controls wouldn't solve this issue in the absence of a "disable remote playback of this element" feature.

Right. I wonder what the ratio would be between initiating remote playback directly from Safari vs by changing the default route somewhere and navigating to the video later. In case of download, the context menu option is obscure enough while the button in the default controls is apparently too visible.

And we should not add to the HTML spec features whose only use case is to make advertising more valuable.

More valuable by how much? I'd say the cost of switching to the custom controls is not high nowadays so the feature wouldn't make it easier to disable the fullscreen button if the site wants ads.

Within the subset of the websites using ads that care about hiding the fullscreen button, the choice for the UA is between having some control over the user experience and not having it at all.

[foolip]

Warning, side discussion ahead:

@jernoble

re: disablefullscreen, why would allowfullscreen on an iframe apply to native fullscreen controls?

The discussion for Blink is a bit spread out, but it started with an Intent to Remove for the allowfullscreen exemption in the web-exposed video-specific fullscreen APIs, triggered by questions from Microsoft. That didn't work out, and responding to feedback from Vimeo I wrote "I agree, the native controls shouldn't have any powers that sites don't have." Although not mentioned, I was also concerned about using transparent or almost-transparent video elements to go fullscreen without the user deliberately interacting with the native video controls.

So, as it stands, it's now possible to disable the fullscreen button by embedding in an iframe, even a same-origin one. That's not the case in Safari I presume, sorry for not being clear.

(None of this shows that there's a demand for a fullscreen-disabling attribute or token, however.)

[zendive]

I came to this thread by following chromium issue tracker id 650174.
As a front-end developer, I received a task to hide download functionality from video control panel for the same reason mentioned by @philzepeda.
The lack of standard at this point made me:

1. to disable context-menu entirely (yes, only because of one item) - harming the UX
2. to "slide" that download button "under the carpet" out of view - breaking future compatibility (like where will appear next 2018'yr button, on left or right side, or maybe they make it multiline?)

If nodownload will be implemented, and I want it to be, that's a partial solution to deny resource download from UI, there are a context menu, dev-tools, various download-me extensions. I think content providers should work on their own "proof of ownership" mechanisms similar to CORS.

I see another perspective to current proposal, is that it can remove the clutter from control panel by leaving space to the most relevant controls, from the web-autor opinion, like play and seek only. Cause adding more buttons in the future will make much less space for seek-bar, leaving it in some cases barely useful.

About the switching to custom controls elements. Since the beginning of <video> tag era, UA vendors suddenly received an area in user context with vendor specific look and feel without standard CSS rules to customize it. The battle for using native controls has been lost for those sites from the beginning. Web creators tend not only to make site functioning in the same way cross the browsers, but to look the same.

[shhhhhigne]

@zendive - note this does not propose a nodownload attribute. It adds a controlsList attribute which will allow content authors to remove items from the default controls.

As @avayvod notes above, controlslist="nodownload" will remove the download button from the default controls but it will not remove the download item from the context menu, so if this is implemented you will still have to "harm the UX" by disabling the context menu completely.

[ghost]

This API is a design smell of the native media player.

Developers want to hide some button which is visual presentation, but can't pierce the replaced element to do so, eg:
audio::-webkit-media-controls-download-button{ display:none; }
Unfortunate also that it isn't css, because as a last resort the user can always disable stylesheets, and blow all the designers terrible choices away.

From a designer's perspective however, the native player is never an option because it has literally zero flexibility or extensibility, and is hostile to custom controls. It catastrophically sucks.

This already played out with native form elements. They're ugly and inflexible, so developers replaced them, and now ARIA allows arbitrary bundles of divs to be assigned official roles as form elements.
If I could tag/extend my pile-o-divs as an audio player, and the browser presents the correct context menu, that would be design and user friendly.

Mostly harmless, but clutter.

[jimmywarting]

I think the hole idea with "customize what controls are shown" is a good idea. Wether it be a DomTokenList, attributes, white/black-listing or properties. It doesn't mather to me so much how you do it just that you can do it is that mather to me.

What I would also like to have is the possibility to add a custom controllers too. It is part of one reason why i go all custom instead of native. Which is a shame since I like the native controllers and i have to re-implement everything else to get something extra like a quality picker

[jeblackiii]

@mounirlamouri

As much as I agree that websites shouldn't disable a UA provided feature, they already can by simply not exposing controls and expose their own instead. Chrome metrics currently show that on desktop native controls are rare and on mobile, usage of native controls is shrinking. The situation we want to avoid is that the opinionated native controls the browser provide only affects an insignificant fraction of media played on the Web. We believe that one path that will help this goal is to offer flexibility for websites that have specific needs.

This is the wrong solution. The right way to eliminate this incentive is to prevent websites from blocking the use of native controls if the user wants them. Users should always be able to right-click a video and select "Show Controls", and they should also be able to use the context menu to pause/resume, mute, download, and do other video-related things. These are some of the problems that need to be solved:

1. Websites that block the context menu by superimposing a transparent overlay.

Browsers should respond by including the items for a video in the context menu, regardless of whether it is the top element.

2. Websites that block the context menu using the contextmenu event.

The usual solution to this is shift+right-click to bypass the blocking. However, this UI is not very discoverable. A better solution would be to ask user permission when a site wants to use this event. The contextmenu attribute for adding items to the menu should be undeprecated or replaced, and web authors should be encouraged to use it instead.

[mounirlamouri]

Users should always be able to right-click a video and select "Show Controls"

Users can do that in most browsers but the experience is usually poor as they overlay with the website's controls.

Browsers should respond by including the items for a video in the context menu, regardless of whether it is the top element.

I don't think this is a real solution to this problem. It will help the minority of users that are aware of the context menu.

A better solution would be to ask user permission when a site wants to use this event

Virtually no users would understand what that means.