Contact emails
ava...@chromium.org, mlam...@chromium.org, dah...@chromium.org
Spec
https://docs.google.com/document/d/1dVPuL8UznIyhYn1KCnaMT7GRJFvDerSgqaUQhSiiY3Y/view
(we are pending a WICG repository to put the proposal into)
Summary
We propose extending the “controls” attribute of the HTMLMediaElement so that the website could enable/disable certain media controls without having to implement all the controls on its own. A “controlsList” property will be added reflecting the current value of “controls” similar to the “class” and “classList” on HTMLElement.
In the initial version we’d like to support the following keywords that can be set in a combination on the controls attribute:
- “nodownload” - hides the download button (without disabling downloads via context menu or dev tools)
- “noremoteplayback” - hides the remote playback button (without disabling remote playback itself so initiating remote playback via other browser UI or the API is still possible)
- “nofullscreen” - hides the fullscreen button (for example, YouTube provides an option for embedded players to disable the API, https://developers.google.com/youtube/player_parameters#fs)
Motivation
At the moment there are three buttons on the native controls that the web developers would want to disable for various reasons: fullscreen, remote playback and download. The only reliable way to do so is to disable the native controls completely by not using the “controls” attribute and implement their own. In practice this is tricky to implement and at the same time denies users access to any new features user agents deliver using the native media controls.
We’re trying to find a compromise that would allow web developers to have what they want but also won’t leave users with an out-of-date and buggy custom controls experience. We also want to ship a generic extensible and future proof solution that’s easy to maintain both from the spec and the implementation perspective. We do expect new features coming to the default controls, at least in Chrome.
After careful consideration of pros and cons, we believe that while this feature has some interoperability risk, it moves the web forward (in the Blink policy definition) better than any other solution we’ve considered.
Interoperability and Compatibility Risk
Interoperability risk is high, no other browser vendor supported the idea so far. It’s likely will never ship in other browsers in any foreseeable future unless web authors start using it a lot. The browser vendor disagreement was not based on technical limitations but the idea of having a generic API.
Compatibility risk is low as the API is small, is feature detectable, backward and future compatible so shouldn’t break existing websites and should be easy to remove.
Edge: No public signals
Firefox: Borderline negative (https://github.com/whatwg/html/issues/2293#issuecomment-276902614)
Safari: Negative (https://github.com/whatwg/html/issues/2293#issuecomment-275749536)
Opera: Positive towards customization but suggested to agree with other UAs (https://github.com/whatwg/html/issues/2293#issuecomment-278933507)
Web developers: Positive (https://bugs.chromium.org/p/chromium/issues/detail?id=650174)
Ongoing technical constraints
None.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
OWP launch tracking bug
Link to entry on the feature dashboard
https://www.chromestatus.com/feature/5737006365671424
Requesting approval to ship?
Yes.From: Anton Vayvod [mailto:ava...@chromium.org]
> Summary
> We propose extending the “controls” attribute of the HTMLMediaElement so that the website could enable/disable certain media controls without having to implement all the controls on its own. A “controlsList” property will be added reflecting the current value of “controls” similar to the “class” and “classList” on HTMLElement.
It's important to recognize that changing a Boolean attribute to a token list in this way is unprecedented and has negative consequences from the two interacting IDL attributes. For example:
<video controls="nodownload noremoteplayback">
// ... in some other library or part of the page ...
videoEl.controls = true; // this will clear the attribute, so now all controls show
Similarly, setting `videoEl.controls = videoEl.controls` will no longer be a no-op.
It is for this reason I'd urge a separate attribute, instead of trying to give dual meaning to the controls="" attribute.
I was expecting a deeper UI custom mechanism when i had seen this.But it turns out just a "Show or not" hints added as <video>'s attributes.This is not what i want, as a custom-embedder dev.I hope there is an “API”(which is not so adequate) to allow custom-embedder devs to custom the builtin <video> controls' UI appearance."API" maybe not accurate, but i hear W3C recently are pushing towards a "Web Annotation" spec which does not needs the page sites' allow....
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
Is there a TAG review for this?
How difficult would it be to get broader consensus on the API?
(also api feedback, is there anyway to harmonise the API with other enable/disable features we already have? E.g. feature policy?)
On Tue, Feb 28, 2017 at 6:47 AM, 'Mounir Lamouri' via blink-dev <blin...@chromium.org> wrote:On Tue, 28 Feb 2017 at 02:33 Chen Zhixiang <cten...@gmail.com> wrote:I was expecting a deeper UI custom mechanism when i had seen this.But it turns out just a "Show or not" hints added as <video>'s attributes.This is not what i want, as a custom-embedder dev.I hope there is an “API”(which is not so adequate) to allow custom-embedder devs to custom the builtin <video> controls' UI appearance."API" maybe not accurate, but i hear W3C recently are pushing towards a "Web Annotation" spec which does not needs the page sites' allow....An API for customisation of the appearance is something we are interested in. However, it has deeper compatibility and interoperability issues.If you want to customise the controls as a //content embedder, compatibility issues are less of an issue and I think we should discuss this. Feel free to reach out to Anton and I off-thread.-- Mounir
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
1. Is there any consensus as to the initial set of keywords and what they will mean across browsers, given potential differences in default controls available? For example, if one vendor decides to combine mute and volume into a single control, and another decides to render it as separate controls, how would that map to keywords? I suppose the page could feature detect from tokens...
2. Does blacklisting a control imply blacklisting all user gestures for the control, or will context-menu/long-press still provide access to downloads and remote playback?
3. Will modifications to the controlsList attribute affect existing controls? This could impact the ability e.g. of extensions to restore blacklisted controls, or for the control set to become context sensitive based on other gestures or content.
On Tue, Feb 28, 2017 at 11:42 PM Anton Vayvod <ava...@chromium.org> wrote:On Tue, Feb 28, 2017 at 4:34 AM Philip Jägenstedt <foo...@chromium.org> wrote:On Tue, Feb 28, 2017 at 5:33 AM Anton Vayvod <ava...@chromium.org> wrote:On Mon, Feb 27, 2017 at 5:44 PM Domenic Denicola <d...@domenic.me> wrote:From: Anton Vayvod [mailto:ava...@chromium.org]
> Summary
> We propose extending the “controls” attribute of the HTMLMediaElement so that the website could enable/disable certain media controls without having to implement all the controls on its own. A “controlsList” property will be added reflecting the current value of “controls” similar to the “class” and “classList” on HTMLElement.
It's important to recognize that changing a Boolean attribute to a token list in this way is unprecedented and has negative consequences from the two interacting IDL attributes. For example:
<video controls="nodownload noremoteplayback">
// ... in some other library or part of the page ...
videoEl.controls = true; // this will clear the attribute, so now all controls show
Similarly, setting `videoEl.controls = videoEl.controls` will no longer be a no-op.The unmodified websites will work as before when 'controls' is set to a bool value. We expect sites using the new feature that has code modifying controls to update the code so it uses the 'controlsList' property (or wait until the library they use is updated).
It is for this reason I'd urge a separate attribute, instead of trying to give dual meaning to the controls="" attribute.Using some other name (for instance, 'controlslist') would result in the websites doing something like:
<video controlslist="nodownload noremoteplayback"> which will not work because of the 'controls' attribute not being present. Or, if having 'controlslist' present means the same as having 'controls' present, removing 'controls' would not work anymore if there's 'controlslist'. Having such dependencies between the two attributes, no matter how we resolve it, will be confusing.I think there are some names for a separate attribute which wouldn't be confusing, for example::<video controls disablecontrols="download">Would you view that as worse than a single attribute?This is still a bit confusing and a no-op when 'controls' is not present.It also loses the ability to whitelist controls (and a counterpart 'enablecontrols' attribute would be even more confusing as controlslist).Looks like we're now (in earlier replies) converging on a separate attribute, that's good.Opting in to controls that are off by default strikes me as somewhat implausible, but could perhaps be useful if we want to remove controls and have a way for pages to ask for them back, like perhaps the volume controls.
On namig, I'd add that a controlsList IDL attribute was originally in analogy with class/classList, and not a common pattern for token list attributes. Unfortunately, other than controlslist, the best I can come up with is a disablecontrols and a future enablecontrols if needed. Bikeshedding ends here, but if other vendors aren't happy with naming, perhaps revisit.