Intent to Implement and Ship: native media controls customization API

301 views
Skip to first unread message

Anton Vayvod

unread,
Feb 27, 2017, 12:38:40 PM2/27/17
to blink-dev, Mounir Lamouri, dah...@chromium.org

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

crbug.com/685018


Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5737006365671424


Requesting approval to ship?

Yes.

Domenic Denicola

unread,
Feb 27, 2017, 12:44:39 PM2/27/17
to Anton Vayvod, blink-dev, Mounir Lamouri, dah...@chromium.org
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.

Anton Vayvod

unread,
Feb 27, 2017, 5:33:21 PM2/27/17
to Domenic Denicola, blink-dev, Mounir Lamouri, dah...@chromium.org
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.
 

Chen Zhixiang

unread,
Feb 27, 2017, 9:32:59 PM2/27/17
to blink-dev, mlam...@chromium.org, dah...@chromium.org
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....

Philip Jägenstedt

unread,
Feb 27, 2017, 11:34:48 PM2/27/17
to Anton Vayvod, Domenic Denicola, blink-dev, cwi...@google.com, Mounir Lamouri, dah...@chromium.org
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?

+Chris Wilson, any progress on hosting this in the WICG?

Anton Vayvod

unread,
Feb 28, 2017, 9:42:33 AM2/28/17
to Philip Jägenstedt, Domenic Denicola, blink-dev, cwi...@google.com, Mounir Lamouri, dah...@chromium.org
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).

Mounir Lamouri

unread,
Feb 28, 2017, 9:48:14 AM2/28/17
to Chen Zhixiang, blink-dev, dah...@chromium.org
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

Ian Kilpatrick

unread,
Feb 28, 2017, 4:43:42 PM2/28/17
to Mounir Lamouri, Chen Zhixiang, blink-dev, dah...@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?)

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

Anton Vayvod

unread,
Mar 1, 2017, 6:26:41 AM3/1/17
to Ian Kilpatrick, Mounir Lamouri, Chen Zhixiang, blink-dev, dah...@chromium.org
Hi Ian,

Comments inline:

On Tue, Feb 28, 2017 at 9:43 PM Ian Kilpatrick <ikilp...@chromium.org> wrote:
Is there a TAG review for this?

No. I'm happy to request it but wouldn't expect the review to happen anytime soon (for example, Remote Playback API issue was filed in November and there hasn't been any feedback yet: https://github.com/w3ctag/spec-reviews/issues/145). The API was proposed and discussed only in the past few weeks so we wouldn't have enough time to get the review feedback.
 
How difficult would it be to get broader consensus on the API?

Could you please clarify if you had any particular group in mind to get consensus with?

On the UA side, apart from getting public signals from Edge, I think we exhausted our options so far. If other UAs wanted to provide good default media experience as much as Chrome, I'd think we'd find a better consensus. Maybe it will change in the future but if we don't provide some option to web developers now, most of them will sooner or later switch to custom controls and switching them back will be too hard no matter how wonderful the API will be.

On the spec side, Domenic and Philip seem to like the API except for the attribute name and I presented arguments for why we think reusing the 'controls' attribute is the best option. Apart from that I think there's a consensus that the API has a positive ergonomic and platform impact and is the right path forward especially because we expect supporting and adding more keywords in the future.
 

(also api feedback, is there anyway to harmonise the API with other enable/disable features we already have? E.g. feature policy?)

I expect the API to be consistent with any conflict resolution mechanism for when the feature is both enabled and disabled (e.g. controls="download nodownlonad") when it's decided how.

I don't think using JSON to set the values makes much sense just to add/remove controls and having separate disable/enable attribute would be confusing as explained earlier in the thread.

Adding an HTTP header could be considered later too (e.g. for CDNs that don't control the content embedder but know enough about the content to justify customizing the controls).

Is there any other way the API could be harmonised with FeaturePolicy that I missed?


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.

Domenic Denicola

unread,
Mar 1, 2017, 9:10:04 AM3/1/17
to Anton Vayvod, blink-dev, Mounir Lamouri, dah...@chromium.org
From: Anton Vayvod [mailto:ava...@chromium.org]

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

While it may be confusing for some, I'd argue it won't be very confusing, because unlike the unprecedented proposal in this thread where one content attribute spawns two IDL attributes, such a dependency between two separate content attributes has plenty of precedent on the platform.

Off the top of my head, there's the dependency between <input>'s type="" and everything else, or <link>'s rel="" and most everything else besides href. That is, authors are already not making the mistake of doing <input min="10" max="20"> and forgetting type="number"; they are not making the mistake of doing <link href="..." as="script"> and forgetting rel="preload".

Similarly, asking authors to remember to add controls="" when doing controlslist="nodownload noremoteplayback" seems very reasonable. Whereas this intent asks them (or more problematically, the libraries they use) to be aware that, in Chrome only, setting `el.controls` to a Boolean value is no longer safe. In my opinion, that is much trickier.

Dimitri Glazkov

unread,
Mar 1, 2017, 11:51:49 AM3/1/17
to Domenic Denicola, Anton Vayvod, blink-dev, Mounir Lamouri, dah...@chromium.org
I share the desire for better ergonomics and agree that making dependent attributes is not a wholly satisfying solution.

At the same time, I am hesitant about the idea of reusing the "controls" attribute, because I need to have more assurance that we leave the path open for interoperability.

For example, https://github.com/w3c/webcomponents/issues/544 illustrates how extending the meaning of an existing, interoperable method could result in hurdles in the future. Since we're don't have support of all vendors with controlsList, I am worried that we could be creating a similar situation.

:DG<

Anton Vayvod

unread,
Mar 2, 2017, 12:22:33 PM3/2/17
to Dimitri Glazkov, Domenic Denicola, blink-dev, Mounir Lamouri, dah...@chromium.org
Thanks Dimitri and Domenic, your arguments seems very convincing.

I'm willing to update the proposal to use a 'controlslist' attribute in addition to the unmodified boolean 'controls' attribute. It will be a no-op if 'controls' is not set on the element.

FWIW, Opera clarified their point in the HTML spec issue and they seem to be supportive: https://github.com/whatwg/html/issues/2293#issuecomment-283659223. The conversation with Apple continues.

mark a. foltz

unread,
Mar 2, 2017, 6:31:24 PM3/2/17
to Anton Vayvod, Dimitri Glazkov, Domenic Denicola, blink-dev, Mounir Lamouri, dah...@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.

[Can upstream these into GitHub issues once the WICG repo is available.]

m.

Anton Vayvod

unread,
Mar 3, 2017, 5:53:00 AM3/3/17
to mark a. foltz, Dimitri Glazkov, Domenic Denicola, blink-dev, Mounir Lamouri, dah...@chromium.org
Thanks for the feedback, Mark. Comments inline:

On Thu, Mar 2, 2017 at 11:31 PM mark a. foltz <mfo...@chromium.org> wrote:
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...

I expect such differences to be rare, we could have separate keywords to cover each case and/or generic one that would cover all cases (e.g. novolume, nomute, novolumecontrols). The website can check via v.controlsList.supports(<keyword>) whether one is supported or not or just supply all keywords (e.g. in a tag) to cover all bases.

The initial set of 'nodownload nofullscreen noremoteplayback' seems to be noncontroversial with download supported by Chrome and Opera, remoteplayback by Chrome and Safari, fullscreen by any UA I know of.
 

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?

The idea is to only disable the controls on the default controls panel, not context menus or other ways. For remote playback, in particular, this would allow the page to implement the remote playback button of their own design (e.g. on the their own top bar with other custom buttons like share, playlist, etc) while still using the default controls for basic features like play and seek. In comparison to disableRemotePlayback attribute that prevents any way to remote the media element.
 

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.

Yes, the idea is the page can either specify what to enable/disable in the DOM setting the content attribute via a string or via script using DOMTokenList's add()/remove() methods.

Philip Jägenstedt

unread,
Mar 3, 2017, 10:56:36 AM3/3/17
to Anton Vayvod, Domenic Denicola, blink-dev, cwi...@google.com, Mounir Lamouri, dah...@chromium.org
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.

Anton Vayvod

unread,
Mar 3, 2017, 11:10:41 AM3/3/17
to Philip Jägenstedt, Domenic Denicola, blink-dev, cwi...@google.com, Mounir Lamouri, dah...@chromium.org
On Fri, Mar 3, 2017 at 3:56 PM Philip Jägenstedt <foo...@chromium.org> wrote:
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.

Are you talking about something like <video controls controlslist="play download"> ?

I think it means hide all controls that the UA can disable but the ones listed. So it's not about showing the controls usually hidden by default.
 

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.

Maybe showcontrols/hidecontrols? I'd prefer to keep one attribute. 

Mounir Lamouri

unread,
Mar 3, 2017, 11:19:05 AM3/3/17
to Anton Vayvod, Philip Jägenstedt, Domenic Denicola, blink-dev, cwi...@google.com, dah...@chromium.org
The idea of whitelisting is that it would indeed start from a blank page and shows the controls that the website is interested to have. Though, obviously, controls that wouldn't work wouldn't show up. It's meant to be a hint (we can rename controlslist to controlshint if it can help). We are not planning to push forward the whitelist approach yet though, we just want the door open in case of websites express interest.  I don't think there is much benefit in having two different token list given that it would be a lot inter dependency to deal with for developers.

-- Mounir

Philip Jägenstedt

unread,
Mar 3, 2017, 11:32:39 AM3/3/17
to Mounir Lamouri, Anton Vayvod, Domenic Denicola, blink-dev, cwi...@google.com, dah...@chromium.org
Right, I had forgotten that part of the plan, distorting it into an "add more controls" feature. Given this, I don't have a naming suggesting that's an improvement over controlslist. (Just controls would be a good name, but...)

At this point, something in the rough shape of a spec is a blocker. What's the tentative deadline for actually landing the code?

Philip Jägenstedt

unread,
Mar 3, 2017, 11:52:15 AM3/3/17
to Mounir Lamouri, Anton Vayvod, Domenic Denicola, blink-dev, cwi...@google.com, dah...@chromium.org
To clarify, the existing doc would suffice, it's not the content and format (Markdown, Bikeshed, whatever) that I'm thinking about so much as whether a WICG repo will be created. +Chris Wilson, I assume that involves asking around for support, or have you just been busy?

Not saying it will happen, but if we find ourselves hosting on someone's private github.io due to a lack of interest to even incubate the idea, that would be somewhat new territory. Doesn't mean we shouldn't do it, but that is what I hope we won't need to explore.

Anton Vayvod

unread,
Mar 3, 2017, 3:33:23 PM3/3/17
to Philip Jägenstedt, Mounir Lamouri, Domenic Denicola, blink-dev, cwi...@google.com, dah...@chromium.org
Thanks to Chris we've just got a repo: https://github.com/WICG/controls-list

Rick Byers

unread,
Mar 8, 2017, 10:01:12 AM3/8/17
to Anton Vayvod, Philip Jägenstedt, Mounir Lamouri, Domenic Denicola, blink-dev, Chris Wilson, dah...@chromium.org
Great, thanks for getting this into WICG.  Now can we file GitHub issues for the main points of contention?  No need to repeat all the arguments of course, just a short summary and links.  It's just important for transparency that it's easy for anyone to see what the main points of debate are around a design.

I support being aggressive in trying to solve the control customzation use cases even though other vendors don't seem interested at the moment.  But it's still important to what we can reasonably do to minimize the eventual interop risk.

Rick Byers

unread,
Mar 8, 2017, 12:34:42 PM3/8/17
to Anton Vayvod, Philip Jägenstedt, Mounir Lamouri, Domenic Denicola, blink-dev, Chris Wilson, dah...@chromium.org
I had a chat with Anton and Mounir offline that I wanted to summarize here.  IMHO there are two things missing here from a blink launch process perspective, which once resolved would lead me (personally) to approve this intent:
  1. Specifying precisely what we intend to ship
    In addition to the explainer motivating the feature, we need to say specifically what tokens we'll be shipping and describe what their behavior will be.  I suggested either a tiny spec, or a HTML pull-request (even though it's not likely to be merged), but I agree with Philip that the precise form doesn't matter - what matters is that the behavior is written down in enough detail that another implementation could match ours without reverse engineering (and developers docs could be written, etc.).  This also helps make it clear that this intent is not a blank check to ship whatever tokens we want here (adding new tokens to the list still requires a new intent as it constitutes a new API).

  2. Making it clear we understand and have considered the remaining objections
    TBH I hadn't processed the fact that Domenic's earlier objection was now addressed, but I think this is still important.  Personally I find this to be the main value of having a well maintained GitHub repo - the key debates (open and closed) are very transparent in the form of issues.  The main point of the intent process is not to ensure we're shipping the ideal APIs (IMHO no process can do that unfortunately), but that we've followed a healthy consensus process in deciding what to ship and what's likely to stick long-term.  Trade offs are required, but it's only blink API owners job to ensure that there had been adequate consideration of the trade offs (not that we personally agree with the specific resolution of each).  We often ship APIs with substantial open issues that track the places where more debate is potentially necessary to reach interop across browsers.  But step #1 is to clearly articulate and track what the outstanding points of debate are.
In the case of this specific feature, I think the future compat risk isn't too bad (we could likely change/unship this API in the future if there's a replacement that becomes more widely supported), and the importance/urgency to addressing the main use cases is very high (there's greater overall platform risk by not shipping something, given the workarounds available to developers).  So personally I believe that taking some interop risk and shipping this API is the right decision now.

Of course other API owners may disagree.  Giving the urgency, please speak up if there's more you'd like to see!

Rick 

Anton Vayvod

unread,
Mar 8, 2017, 5:46:47 PM3/8/17
to Rick Byers, Philip Jägenstedt, Mounir Lamouri, Domenic Denicola, blink-dev, Chris Wilson, dah...@chromium.org
Thanks Rick. I filed the issues in the repo summarizing the concerns and our conclusions (with links to the full conversations on GitHub or chromium.org for the full reference). I'll try to get a more formal spec change ready asap.

Anton Vayvod

unread,
Mar 9, 2017, 10:21:06 AM3/9/17
to Rick Byers, Philip Jägenstedt, Mounir Lamouri, Domenic Denicola, blink-dev, Chris Wilson, dah...@chromium.org
I've uploaded a PR to the HTML spec: https://github.com/whatwg/html/pull/2426
Let me know if there's anything else to address.

Dimitri Glazkov

unread,
Mar 9, 2017, 10:35:38 AM3/9/17
to Anton Vayvod, Rick Byers, Philip Jägenstedt, Mounir Lamouri, Domenic Denicola, blink-dev, Chris Wilson, dah...@chromium.org
LGTM1

Rick Byers

unread,
Mar 9, 2017, 10:54:33 AM3/9/17
to Dimitri Glazkov, Anton Vayvod, Philip Jägenstedt, Mounir Lamouri, Domenic Denicola, blink-dev, Chris Wilson, dah...@chromium.org
The main outstanding debate seems centered around this issue (noDownload vs. controlsList).  From a blink process perspective I think we've done all we can to try to reach consensus on this and it's fundamentally blocked by a difference in philosophy.  Hopefully more consensus can be reached long term (even if that entails us taking a breaking change later), but I don't see any reason to delaying further.

LGTM2

Jochen Eisinger

unread,
Mar 9, 2017, 11:06:30 AM3/9/17
to Rick Byers, Dimitri Glazkov, Anton Vayvod, Philip Jägenstedt, Mounir Lamouri, Domenic Denicola, blink-dev, Chris Wilson, dah...@chromium.org
lgtm3

Chris Wilson

unread,
Mar 9, 2017, 12:32:04 PM3/9/17
to Anton Vayvod, Alex Danilo, Rick Byers, Philip Jägenstedt, Mounir Lamouri, Domenic Denicola, blink-dev, dah...@chromium.org
Please work with Alex Danilo to put it on the HTML WG's radar as well.
Reply all
Reply to author
Forward
0 new messages