Html: 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?

[domenic]

With that phrasing, it seems analogous to playsinline, which we went out of our way to standardize unprefixed for Safari's sake, even though it only applied to them. I don't think telling Chrome to use a nonstandard prefixed attribute is fair given that precedent.

[jernoble]

Fair enough. Still, wouldn't it make more sense to have a single attribute, "nodownload" rather than a class-list like attribute?

[jernoble]

Actually, no I take that back. We were trying to remove a prefix on an existing attribute that, admittedly, was only supported on our browser. Google is trying to add something that could be a prefixed attribute that is only supported on one browser. The situations have parallels, but they are not analogous.

But, like the playsinline attribute, the nodownload attribute could be specified as a note, that a user agent may use it as a hint not to display a download button.

[domenic]

Yes, I think there's a good discussion to be had as to whether controls="" was overgeneralizing if nodownload is the only important use case. I'll pop out of the thread now and leave that discussion to the rest of you. I hope some of the pinged Mozilla folks can pop in to provide a third perspective :).

[avayvod]

@domenic @jernoble
Disabling the download buttons repeats the remote playback pattern. controls="noremoteplayback" would work for Chrome in the past but we did disableRemotePlayback because of how AirPlay works on iOS.

We expect to get requests for controls="nopictureinpicture" too when we support it so having a generic solution seems better than adding a new attribute for each feature.

Jer made good arguments for "novolume" or "noseek" above which I personally have no objections to implementing in Chrome.

[jernoble]

That's exactly what I'm afraid of; the feature creep of adding more and more "no" options to this attribute. There's precisely one concrete use case so far: "nodownload". And it only applies to Chrome.

Jer made good arguments for "novolume" or "noseek" above which I personally have no objections to implementing in Chrome.

I most certainly did not. I said that there were better use cases for "novolume" than "nofullscreen". Not that those were good use cases, but they were better than the low bar set by "nofullscreen". Animated GIF presentations are already possible by leaving out the "controls" attribute entirely.

[foolip]

the only concrete use case provided is that site authors want to disable the download button; something that is itself not specified

The spec doesn't enumerate all allowed controls, but it expand on "User agents may allow users to view the video content in manners more suitable to the user" to mention downloading/offline viewing, although I don't think that would really affect this discussion.

It's worth noting that Chrome isn't the only browser with a download button, Opera for Android also has one, or did when I worked on it.

A nodownload attribute (reflected as noDownload for feature detection) would solve the same problem, but if there is a fair chance that more buttons are added in the future that sometimes don't make sense, controlsList seems slightly preferable.

The difference is perhaps in the amount of friction in making more controls removable, is that a fair way to frame you concern, @jernoble?

[mounirlamouri]

The difference is perhaps in the amount of friction in making more controls removable, is that a fair way to frame you concern, @jernoble?

For what it's worth, I assumed while writing this proposal that different browsers would have different buttons in their controls and would allow some of them to be removed and not others, this is the reason why I wanted each keyword to be feature detected. @jernoble I wasn't able to find why this solution doesn't solve the issue of the user agent being able to enforce some user experience.

[jernoble]

@mounirlamouri, even this feature detection option is problematic. As it stands, this spec would require WebKit to adopt "nodownload", even if we don't have a download button in our native controls. Consider: A website which doesn't want their content downloaded might refuse to display a <video> tag unless DOMTokenList.supports('nodownload') returns true. Suddenly, a feature which we do not support (a download button in the native controls), has induced a code change and an on-going maintenance burden.

[Yay295]

That sounds like a problem for the website, not for the browser. I'm sure they'll complain, but you don't need to bend to their every whim.

[hober]

For what it's worth, I assumed while writing this proposal that different browsers would have different buttons in their controls and would allow some of them to be removed and not others.

This was not obvious to me when I read the explainer. I didn't realize these are hints that the UA has discretion to ignore.

[jernoble]

@Yay295 The problem isn't the website; it's the website's users. Users will work around the problem by switching browsers.

[foolip]

@jernoble, regarding https://github.com/whatwg/html/issues/2293#issuecomment-275749536, is the following also of concern?

if (!('disableRemotePlayback' in video)) {
  alert('no video for you!')
}

This and the DOMTokenList.supports('nodownload') example you gave is not so far fetched, but should we deliberately make feature detection impossible to avoid this? It wouldn't really help for features/bugs that are in one UA only, for example I recall that way back when Opera (Presto) didn't block the context menu on preventDefault(), some site instead just blocked with UA sniffing.

So, what are we to do with features that are largely useful but which some sites really don't want?

[jernoble]

@foolip, the difference between the two examples is that, in the nodownload case, there's no way to feature-detect the presence of a download button in the native controls. So sites which want to block Chrome pre-adoption of nodownload but allow Chrome post-adoption will end up blocking Safari as well. Unless they do UA sniffing, that is, in which case, what's the point of the feature detection in the first place?

[jernoble]

Also:

So, what are we to do with features that are largely useful but which some sites really don't want?

Perhaps the right answer here is to anticipate those questions before shipping said features, rather than asking the community to agree on an emergency spec fix.

I don't really object to adding something like nodownload. The implementation isn't well thought out, e.g., the potential to break other UAs stated above. But it seems reasonable to spec a way for websites to hint to the UA that they'd prefer not to have a download button.

What I really object to is cramming in a bunch of not-entirely-related features into the same spec, because, as an extension point, it might hypothetically make such changes easier in the future.

[mounirlamouri]

@jernoble I'm not sure if you are saying that the download button aspect seems like a reasonable use case to you in the context of this proposal or if you want this proposal to be only about download? I would really prefer the former even if that means we reduce the initial proposal to something we can agree on and iterate from here.

[jernoble]

I'm saying that the use case of: "websites should be able to control whether their content is easily downloadable" seems valid. I don't think that single use case justifies your proposal, given that there are much simpler solutions available.

Put more broadly, I disagree that "web authors should be allowed to customize what controls are shown for HTMLMediaElement". The actual issue at hand is "web authors should be allowed to request that their HTMLMediaElement content not be downloaded."

[kentuckyfriedtakahe]

The fallout from adding a download button are evidence that default controls are problematic. Making the default controls customisable seems like a very deep hole and not somewhere I'm inclined to dig. We would be better off focusing our efforts on improving libraries for custom controls.

Perhaps Chrome can just fix their immediate problem with some kind of nodownload hack or simply remove the button. Downloading seems obscure in the modern web.

[mounirlamouri]

@kentuckyfriedtakahe download is a major feature request from emerging markets. It's not something users of emerged markets care much about indeed but I wouldn't say that it shouldn't be part of the modern web. We need to have an experience that matches everyone's use cases.

Regarding the general proposal, we had a discussion about this and would like to propose to drop the controlsList property if that can smooth things out. It would make the feature non-detectable for now and would allow for an easy removal if it happens to be seriously at risk. Later, controlsList could be added back if the community asks for it. Alternatively, if the usage is very low, we might consider dropping the feature entirely without breaking content. WDYT?

[zcorpan]

In general there is plenty of precedent for allowing web developers to disable specific features that we in general think are useful for end users.

• Text selection (CSS user-select: none)
• Context menu (addEventListener('contextmenu', e => e.preventDefault()))
• Remote playback, as noted earlier (x-webkit-airplay="deny", x-webkit-wirelessvideoplaybackdisabled, disableremoteplayback)
• etc

It appears there is agreement that disabling easy-download should be possible, but disagreement about other controls. Correct? If so, I think we should leave the controls attribute alone, and add a new nodownload boolean attribute. That is trivial for anyone to implement, whether they support "easy-downloading" or not, which seems like a good thing to get universal adoption of web developer-visible API and interoperability.

[jernoble]

So it looks like Chrome is moving ahead with landing support for controlsList: https://codereview.chromium.org/2657723002/. @mounirlamouri, your last comment here said:

Regarding the general proposal, we had a discussion about this and would like to propose to drop the controlsList property if that can smooth things out.

Have you changed your mind?

[avayvod]

Hi Jer et al,

We discussed the options in a couple of Blink-specific mailing lists: chrome-facebook and blink api owners discuss.

The conclusion was we shouldn't do something that's not feature detectable. Given that and the expected need for more attributes, we've sent an intent to ship with the original proposal despite the feedback above from WHATWG. The intent discussion is here: intent to ship.

We don't know 100% what the actual approved result will be (the trend seems to go towards a separate DOMTokenList attribute that doesn't affect controls), but I'm updating the changelist nevertheless for it to be ready to land before the branch point in case the intent is approved.

Would you be favorable towards a separate attribute that is exposed as a DOMTokenList compared to controls="nofoo nobar"? I expect websites rely on the new attribute presence as an indicator that download button (and other new features) is used by the UA and not disabling video playback if the attribute is not implemented (vs. checking if nodownload is supported).

[jernoble]

@avayvod That is incredibly disappointing and frustrating. So far, the only positive feedback for this feature has been from Google employees, where the only presented use case is Chrome-only. I assume, then, that you're going to prefix this attribute with -chrome?

[avayvod]

@jernoble I'm sorry you feel this way.

I don't think though that the feedback we've got so far from other browser vendors was equally negative. Here's my summary of the feedback:

1. Adding something feature detectable will force other browsers into implementation as web authors will block the video playback unless the feature is supported (@jernoble).
2. Why add anything extra if web authors can just do custom controls (@jernoble, @kentuckyfriedtakahe).
3. disableDownload attribute should be good enough (all?)
4. Reusing the controls attribute is worse than adding a new one (@zcorpan).

I believe that the fear of losing video sites in 1 is not justified (even less so if we ship a new attribute). Making the feature non-detectable will make it unusable by popular JS libraries, on the other hand, so addressing this concern is not very useful.

I disagree with the all-or-nothing position on default vs custom controls, but in the end it's a higher level vision question which I don't think UAs must agree on. Chrome wants to invest in the default user experience and doesn't want the majority of the Web to switch to custom controls. Safari even enforced default controls on phones until recently (and still does in fullscreen?) so I'd think our goals aligned; however giving web authors a binary choice doesn't seem like a good strategy to me as the majority will eventually choose custom controls for one reason or another and improving libraries will be the only tool we've got left to provide good experience to the users (at this point we'd have basically no influence on the user experience regarding media playback and media usage, esp. on mobile where browser UI outside the page is limited in space).

Chrome will need similar controls-disabling attributes in the future. I believe whether it's a single attribute or not shouldn't matter to the UAs not implementing it as long as it's feature detectable. Also disableDownload sounds more like disableRemotePlayback in a sense it should disable downloads altogether, not just one control. That's definitely not Chrome's goal and not the web authors request so far. It'd rather be something like disableDownloadControl and disableFooControl and disableBarControl. Thus something like a DOMTokenList is our preference.

Finally, controls vs a new attribute argument I'm willing to accept based on the Intent to Ship thread.

So my point is, as long as the change can be feature detected, other UAs don't have to implement it. Safari and/or Firefox may change their vision on custom vs default controls in the future and then our proposal hopefully will make more sense for them to implement. Opera doesn't seem to really oppose customization of controls.

We also hope to get public feedback from Edge once we have WICG repo for our proposal.

Given the above, we're not going to prefix the attribute.

[zcorpan]

This affects Opera as well since we have a download button in the controls, as can be seen in http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4910

While we think users should be able to download videos easily (hence the button), we don't oppose this proposal.

As to my comment about controls vs new attribute, I assumed that the goal was to have the API implemented everywhere even if the browser doesn't have a download button. If that is a non-goal then it is not so relevant.

[avayvod]

It is the ultimate goal to have any spec change adopted by as many browsers as possible. The API allows sites to feature detect what keywords are supported.

My point was that the API doesn't enforce other UAs to implement it, especially if it's not exposed via the controls attribute but rather via something new like controlslist.

[jernoble]

@avayvod Well, you and @mounirlamouri asked for feedback on your proposal, a consensus formed that a nodowload attribute was a sufficient compromise for the use case provided, and you decided to ignore that feedback. So at this point, if you want to ship a controlslist attribute, it will be outside of any specification.

[jernoble]

@zcorpan Yes, I'm not objecting to the nodownload attribute, but rather the controlslist (et. al) and specifically the nofullscreen token. Not only will WebKit refuse to implement this, we will vigorously object to it being added to the spec. It is specifically user-hostile, and has no articulable use case.

[jernoble]

@avayvod

I disagree with the all-or-nothing position on default vs custom controls, but in the end it's a higher level vision question which I don't think UAs must agree on. Chrome wants to invest in the default user experience and doesn't want the majority of the Web to switch to custom controls. Safari even enforced default controls on phones until recently (and still does in fullscreen?) so I'd think our goals aligned;

Indeed! I'm very invested in making sure our native controls are great! Which is precisely the reason I object to this proposal. Your proposal actively makes the native controls less useful for the end user.

Chrome will need similar controls-disabling attributes in the future.

Nothing is stopping Chrome for adding support for this. (Indeed, you haven't even waited for feedback before filing an intent-to-ship.) But to enshrine this behavior in a spec requires a much higher bar than just "Chrome needs this".

[avayvod]

@jernoble

Indeed! I'm very invested in making sure our native controls are great! Which is precisely the reason I object to this proposal. Your proposal actively makes the native controls less useful for the end user.

Well, in the current world you won't be able to make native controls greater by adding something web developers won't like but users need (like a download button, or a pip button, or something else new and exciting) without web developers switching to custom controls. And once they switch, they will switch forever. So either you add new features but reduce the share of the websites they can be used at or you don't add new features and don't make the native controls better. What's the compromise here? A new disable attribute for each feature? Why not have something more generic then?

I also feel you object to the fullscreen button specifically more than to the rest of the proposal.

(Indeed, you haven't even waited for feedback before filing an intent-to-ship.)

I believe we've got clear feedback here already. What other feedback do you think we should be looking for? We ignored the consensus here because we believe a list API is a better path forward and arguments presented against it are not convincing.

But to enshrine this behavior in a spec requires a much higher bar than just "Chrome needs this".

I understand it will not make it into HTML spec here. For now, we plan to add a spec extension in a WICG repo to document what'll be shipping.

[jernoble]

@avayvod

Well, in the current world you won't be able to make native controls greater by adding something web developers won't like but users need (like a download button, or a pip button, or something else new and exciting) without web developers switching to custom controls.

As you said earlier in this thread, adopting custom controls is a significant barrier. (In fact, that was one of your justifications for adding this API in the first place.). If websites want to make objectively worse experiences for their users (such as disabling PiP) they have to do the heavy lifting themselves.

I also feel you object to the fullscreen button specifically more than to the rest of the proposal.

Well, since that's a third of your proposal, I think it's pretty important. Also, I'm extremely worried about your example above of "a pip button". Is that next? Maybe nomute, so ad-bearing video sites can keep their users from muting pre-roll ads?

We ignored the consensus here because we believe a list API is a better path forward and arguments presented against it are not convincing.

You can do whatever you'd like in Chrome (obviously). But I hope you understand that consensus is usually required to get changes made to a spec.

[avayvod]

As you said earlier in this thread, adopting custom controls is a significant barrier. (In fact, that was one of your justifications for adding this API in the first place.). If websites want to make objectively worse experiences for their users (such as disabling PiP) they have to do the heavy lifting themselves.

Right. 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.

[kentuckyfriedtakahe]

@avayvod

We ignored the consensus here
because we believe a list API is a better path forward and arguments
presented against it are not convincing.

The funny thing is that I find jernoble's arguments convincing. At least
you got the consensus you were after on the blink mailing lists.

Right. 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.

Chrome is driving sites away form custom controls here. This is a
discussion about how to ameliorate the problem.

Can you explain how adding Chrome only button customisations encourages
sites to use custom controls?

[avayvod]

@kentuckyfriedtakahe

The funny thing is that I find jernoble's arguments convincing.

What arguments exactly? That websites will block video playback in Safari (and Firefox) if they don't support disabling download button while not supporting the download button?

Or that the usage of the default controls is preserved by making it impossible to customize?

I find both arguments hard to believe: if the choice in front of a web developer is between implementing custom controls or not providing some content to the user because of content restrictions, they will implement custom controls, and users will be lucky if they will be using a well-written library. However it means that inevitably the default controls will lose their importance in delivering new features to users and providing good default user experience.

Chrome is driving sites away form custom controls here. This is a
discussion about how to ameliorate the problem.

Hm, this discussion is about fixing the problem of sites being driven from the default towards (not from) custom controls. The download button introduced in Chrome is the current reason this is happening. However, I don't think removing it is good for users, especially in the places where internet is expensive and offline media consumption is very common. We should've come up with a solution before launching it but we can't change the past and the solution would very likely look the same as what we want to do today.

Can you explain how adding Chrome only button customisations encourages
sites to use custom controls?

Again, my point is the opposite (did you mean default controls when you wrote custom controls here and above?).

Adding customization will encourage sites to keep using the default controls because they will be able to tweak the default controls how they need. Chrome-only might be okay for now as it's the Chrome's download feature that currently drives the websites away from the default controls but in the long term other UAs might add a feature (download or something else) that will force custom controls on the users by leaving the websites no other choice but to switch.

[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.

1. 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.