Feedback request on the media controls customization API

[Anton Vayvod]

Hi Blink API owners!

We would like your advice about a feature we want to launch in M58. The feature would offer the ability for websites to customize the native media controls. In the short term it allows websites to turn off the download button but also has a long term goal to encourage websites to use native controls. We do not want websites to have to implement custom controls just because some of the default controls don’t make sense for their content. Both because it’s tricky to implement correctly and because it will not let users use future new controls until the site is updated.

We proposed a generic way for the websites to select which of the user agent’s native media controls (as in <video>’s controls attribute) should be shown. An issue was filed against the HTML spec that initially received a positive response from the spec owners (foolip@, domenic@) on a technical basis but then Apple and Mozilla expressed a disagreement about the problem we were trying to solve (native controls customization).

We are facing an uncommon challenge where other vendors disagree not on the technical solution but on the existence of the problem itself. We do not want to unilaterally launch a feature but we also believe that allowing native controls customization is an important step towards a better media experience on the Web, especially on mobile. We want Chrome users to have a great experience by default and encouraging websites to delegate it to the browser sounds like the best solution.

We received various, sometimes contradictory, feedback. A common suggestions is to add a new attribute to HTMLVideoElement to disable the download button and thus solve the immediate issue. We are not thrilled by this solution because it feels more like an ad-hoc fix, preventing us from achieving the larger goal outlined above. We already have added disableRemotePlayback recently and features such as picture-in-picture (available in Safari, Firefox & Opera) or VR (we can expect this to happen at some point) might also require opt-out from websites when they get added to the browser’s native controls. Furthermore, adding an attribute to disable download directly on the media element might provide the wrong impression that we are implementing some sort of content protection mechanism which isn’t the intent here (e.g. the context menu would still work).

An intermediate solution we have been designing with foolip@ (as an HTML spec editor and one of the Blink API owners) is to launch the feature without feature detection. In other words, controlsList would not be exposed. This would solve one concern Apple expressed and would allow for an easy deprecation path if we realise later that the feature isn’t very useful. This wouldn’t be conventional as we would ship a feature with a deprecation path in mind but might be the least aggressive path.

In summary, these are the options we have::

1. Implement and ship the MVP of the API as proposed.

2. Implement and ship the MVP of the API without feature detection.

3. Implement and ship an attribute to disable the download button.

Thanks,

Anton, John and Mounir.

[Philip Jägenstedt]

The main consideration here is whether a change like this will eventually be implemented in all engines, or if it will fall short of that and leave us wondering in 3 years whether to try removing or not.

In the specific case of a download button, it is not a given that this would become ubiquitous and push others to implement the same opt-out mechanism. Perhaps most plausibly, it might be overtaken by some page-wide or video-specific "save for offline" feature that people might want a different opt-out for.

Given that, and the skepticism from other vendors, I think it makes sense to plan for the outcome that this doesn't get much traction. It will make the API worse, and we shouldn't do it in general.

The option that would make this the easiest to remove while still keeping the door open to exposing this with a nicer API and allowing feature detection is, IMHO, option 2.

There is one downside that I hadn't thought about before. Setting video.controls = false would remove the attribute, so one couldn't toggle the controls on and off while preserving the opt-outs. This is unlike classList, where the mere presence of the class attribute is in itself not meaningful. Did you already discuss this, Mounir and Anton?

Other than that, I think that the only complaints I would anticipate with option 2 would be:

• We are making it impossible to ever overload the controls attribute to be anything other than a list of tokens. This seems fine.
• It's not possible to feature detect. (Which is kind of the point.)
• controls="nodownload" will start appearing in the wild, which is ugly in the same way that sprinkling playsinline attributes is ugly.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To post to this group, send email to blink-api-ow...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAOjek6rX9j_HSOarabhee1MY%2Bn65y2puMtvuQEu-iwds7WDqKA%40mail.gmail.com.

[Domenic Denicola]

On Wed, Feb 8, 2017 at 2:19 PM Philip Jägenstedt <foo...@chromium.org> wrote:

The main consideration here is whether a change like this will eventually be implemented in all engines, or if it will fall short of that and leave us wondering in 3 years whether to try removing or not.

In the specific case of a download button, it is not a given that this would become ubiquitous and push others to implement the same opt-out mechanism. Perhaps most plausibly, it might be overtaken by some page-wide or video-specific "save for offline" feature that people might want a different opt-out for.

Given that, and the skepticism from other vendors, I think it makes sense to plan for the outcome that this doesn't get much traction. It will make the API worse, and we shouldn't do it in general.

The option that would make this the easiest to remove while still keeping the door open to exposing this with a nicer API and allowing feature detection is, IMHO, option 2.

There is one downside that I hadn't thought about before. Setting video.controls = false would remove the attribute, so one couldn't toggle the controls on and off while preserving the opt-outs. This is unlike classList, where the mere presence of the class attribute is in itself not meaningful. Did you already discuss this, Mounir and Anton?

Other than that, I think that the only complaints I would anticipate with option 2 would be:

• We are making it impossible to ever overload the controls attribute to be anything other than a list of tokens. This seems fine.
• It's not possible to feature detect. (Which is kind of the point.)
• controls="nodownload" will start appearing in the wild, which is ugly in the same way that sprinkling playsinline attributes is ugly.

Another downside of option 2 is that 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.

 

On Wed, Feb 8, 2017 at 12:59 PM Anton Vayvod <ava...@chromium.org> wrote:

Hi Blink API owners!

We would like your advice about a feature we want to launch in M58. The feature would offer the ability for websites to customize the native media controls. In the short term it allows websites to turn off the download button but also has a long term goal to encourage websites to use native controls. We do not want websites to have to implement custom controls just because some of the default controls don’t make sense for their content. Both because it’s tricky to implement correctly and because it will not let users use future new controls until the site is updated.

We proposed a generic way for the websites to select which of the user agent’s native media controls (as in <video>’s controls attribute) should be shown. An issue was filed against the HTML spec that initially received a positive response from the spec owners (foolip@, domenic@) on a technical basis but then Apple and Mozilla expressed a disagreement about the problem we were trying to solve (native controls customization).

We are facing an uncommon challenge where other vendors disagree not on the technical solution but on the existence of the problem itself. We do not want to unilaterally launch a feature but we also believe that allowing native controls customization is an important step towards a better media experience on the Web, especially on mobile. We want Chrome users to have a great experience by default and encouraging websites to delegate it to the browser sounds like the best solution.

We received various, sometimes contradictory, feedback. A common suggestions is to add a new attribute to HTMLVideoElement to disable the download button and thus solve the immediate issue. We are not thrilled by this solution because it feels more like an ad-hoc fix, preventing us from achieving the larger goal outlined above. We already have added disableRemotePlayback recently and features such as picture-in-picture (available in Safari, Firefox & Opera) or VR (we can expect this to happen at some point) might also require opt-out from websites when they get added to the browser’s native controls. Furthermore, adding an attribute to disable download directly on the media element might provide the wrong impression that we are implementing some sort of content protection mechanism which isn’t the intent here (e.g. the context menu would still work).

An intermediate solution we have been designing with foolip@ (as an HTML spec editor and one of the Blink API owners) is to launch the feature without feature detection. In other words, controlsList would not be exposed. This would solve one concern Apple expressed and would allow for an easy deprecation path if we realise later that the feature isn’t very useful. This wouldn’t be conventional as we would ship a feature with a deprecation path in mind but might be the least aggressive path.

In summary, these are the options we have::

1. Implement and ship the MVP of the API as proposed.

2. Implement and ship the MVP of the API without feature detection.

3. Implement and ship an attribute to disable the download button.

Thanks,

Anton, John and Mounir.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To post to this group, send email to blink-api-ow...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAOjek6rX9j_HSOarabhee1MY%2Bn65y2puMtvuQEu-iwds7WDqKA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To post to this group, send email to blink-api-ow...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAARdPYeVA08roBvrP-m40%2Be-qgdUXORCdWanQ71tGvfPeckzog%40mail.gmail.com.

[Philip Jägenstedt]

On Wed, Feb 8, 2017 at 2:34 PM Domenic Denicola <dom...@google.com> wrote:

On Wed, Feb 8, 2017 at 2:19 PM Philip Jägenstedt <foo...@chromium.org> wrote:

The main consideration here is whether a change like this will eventually be implemented in all engines, or if it will fall short of that and leave us wondering in 3 years whether to try removing or not.

In the specific case of a download button, it is not a given that this would become ubiquitous and push others to implement the same opt-out mechanism. Perhaps most plausibly, it might be overtaken by some page-wide or video-specific "save for offline" feature that people might want a different opt-out for.

Given that, and the skepticism from other vendors, I think it makes sense to plan for the outcome that this doesn't get much traction. It will make the API worse, and we shouldn't do it in general.

The option that would make this the easiest to remove while still keeping the door open to exposing this with a nicer API and allowing feature detection is, IMHO, option 2.

There is one downside that I hadn't thought about before. Setting video.controls = false would remove the attribute, so one couldn't toggle the controls on and off while preserving the opt-outs. This is unlike classList, where the mere presence of the class attribute is in itself not meaningful. Did you already discuss this, Mounir and Anton?

Other than that, I think that the only complaints I would anticipate with option 2 would be:

• We are making it impossible to ever overload the controls attribute to be anything other than a list of tokens. This seems fine.
• It's not possible to feature detect. (Which is kind of the point.)
• controls="nodownload" will start appearing in the wild, which is ugly in the same way that sprinkling playsinline attributes is ugly.

Another downside of option 2 is that 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.

Thank you, that matters a great deal. It looks like WebKit's playsinline is reflected, so departing from that is probably not a good idea. When using the IDL attributes only, there's also this mistake waiting to happen:

v.controlsList = "nodownload"; // assuming [PutForwards=value] in IDL

v.controls = true; // sets the content attribute back to ""

What to do? If we make it a new reflected content+IDL attribute, we should expect to keep it in the long term, that it might not be added elsewhere, and not be overly surprised if people use it in silly ways that aren't strictly what we had in mind.

Is it worth thinking again about `video::download-button { display: none; }`, with display as the only property that can be changed? That does not commit us to doing full controls customization using CSS, and it does have the benefit that you don't have to add something to each video element individually.

[Mounir Lamouri]

> > - We are making it impossible to ever overload the controls attribute

> > to be anything other than a list of tokens. This seems fine.

> > - It's not possible to feature detect. (Which is kind of the point.)
> > - controls="nodownload" will start appearing in the wild, which is

> > ugly in the same way that sprinkling playsinline attributes is ugly.
> >
> >
> > Another downside of option 2 is that 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.
> >
>
> Thank you, that matters a great deal. It looks like WebKit's playsinline
> is
> reflected, so departing from that is probably not a good idea. When using
> the IDL attributes only, there's also this mistake waiting to happen:
>
> v.controlsList = "nodownload"; // assuming [PutForwards=value] in IDL
> v.controls = true; // sets the content attribute back to ""

(PutForwards=value is in the proposal's IDL)

> What to do? If we make it a new reflected content+IDL attribute, we
> should
> expect to keep it in the long term, that it might not be added elsewhere,
> and not be overly surprised if people use it in silly ways that aren't
> strictly what we had in mind.

Someone using `controlsList` and `controls` should easily figure out the
mistake. It might be trickier if/when user agents implement
`controlsList` but not all keywords, making the script work and look
fine in some browsers but not others. Though, it doesn't look like a
foot gun to me: documentation should simply tell developers to not use
`controls` if they use `controlsList` unless they want to disable the
controls with `controls=false;`.

> Is it worth thinking again about `video::download-button { display: none;
> }`, with display as the only property that can be changed? That does not
> commit us to doing full controls customization using CSS, and it does
> have
> the benefit that you don't have to add something to each video element
> individually.

I think it's worth considering style customisation for the long run but
it sounds like a greater compatibility landmine. My experience working
on form controls was that such CSS selectors depend greatly on how the
user agents implement their shadow DOM. Maybe just allowing to set
"display:none" on "::download-button" is simple enough but we would take
the risk to have a solution specific for one button that we could not
easily extend. And as explained in the original email, having a generic
extensible solution is a goal for us here.

This said, I would really like for us to allow styling. Having a way for
websites to have the native controls match their colour patterns would
be great. I would expect a lot of push back from other browsers about
this given the feedback for this simpler feature.

I talked to Rick about CSS customisation of the media controls during
BlinkOn and he seemed to think that we should probably do this from
script to increase the chances of compatibility. I'm not sure if that's
the right approach but I think it's a strong enough signal that we
shouldn't try to use new CSS selectors here.

-- Mounir

[Dimitri Glazkov]

Just wanted to check in on this. I looked over both this thread and the WHATWG bug thread, and I am not certain what y'all's current thinking is.

:DG<

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To post to this group, send email to blink-api-ow...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/1486720883.2681417.876602448.6ED5A783%40webmail.messagingengine.com.

[Philip Jägenstedt]

Good :)

 

> What to do? If we make it a new reflected content+IDL attribute, we
> should
> expect to keep it in the long term, that it might not be added elsewhere,
> and not be overly surprised if people use it in silly ways that aren't
> strictly what we had in mind.

Someone using `controlsList` and `controls` should easily figure out the
mistake. It might be trickier if/when user agents implement
`controlsList` but not all keywords, making the script work and look
fine in some browsers but not others. Though, it doesn't look like a
foot gun to me: documentation should simply tell developers to not use
`controls` if they use `controlsList` unless they want to disable the
controls with `controls=false;`.

Here I was assuming that React used at some point something like a dictionary { controls: true, controlsList: "nodownload" }, where it looks like separate attributes and it's not obvious that order could matter.

Turns out that the React syntax is actually something like this:

function MyVideo() {

  return <video controls="nodownload"/>;

}

In http://codepen.io/anon/pen/dNadXY?editors=0010 it looks like that won't work, the string is lost presumably because the reflected controls attribute is used, so one would probably have to extend React to this:

function MyVideo() {

  return <video controlsList="nodownload"/>;

}

(Assuming that it would map controlsList to controls when not supported.)

Anyway, enough about React I suppose...

> Is it worth thinking again about `video::download-button { display: none;
> }`, with display as the only property that can be changed? That does not
> commit us to doing full controls customization using CSS, and it does
> have
> the benefit that you don't have to add something to each video element
> individually.

I think it's worth considering style customisation for the long run but
it sounds like a greater compatibility landmine. My experience working
on form controls was that such CSS selectors depend greatly on how the
user agents implement their shadow DOM. Maybe just allowing to set
"display:none" on "::download-button" is simple enough but we would take
the risk to have a solution specific for one button that we could not
easily extend. And as explained in the original email, having a generic
extensible solution is a goal for us here.

For purposes of just hiding individual controls, isn't this as extensible as you need it to be? Do you anticipate ever adding controls that are off by default but can be turned on?

 

This said, I would really like for us to allow styling. Having a way for
websites to have the native controls match their colour patterns would
be great. I would expect a lot of push back from other browsers about
this given the feedback for this simpler feature.

I talked to Rick about CSS customisation of the media controls during
BlinkOn and he seemed to think that we should probably do this from
script to increase the chances of compatibility. I'm not sure if that's
the right approach but I think it's a strong enough signal that we
shouldn't try to use new CSS selectors here.

+Rick Byers, care to weigh in here? It seems to me that a CSS approach would be easier to remove down the line, and it would not imply a commitment to going any further with controls customization.

Meanwhile, in https://github.com/whatwg/html/issues/2293#issuecomment-278933507, Simon has also spoken in favor of a nodownload attribute. I think there's a significant chance Blink would be the only engine to ever have it, which is not great, but perhaps it wouldn't be terrible to call if disableDownload and just call this the pattern for disabling media things, following disableRemotePlayback?

[Jochen Eisinger]

btw, it seems to me that API owners isn't necessarily the right set of ppl to give advice here, but you should talk to ergonomics (+Ian Kilpatrick) and predictiability

--

You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To post to this group, send email to blink-api-ow...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAARdPYewtzUEfvLKtAhQq-Jfhs%2Bz044dTS0d_KY623qfh0-wyA%40mail.gmail.com.

[Anton Vayvod]

Ideally, we don't want the page to disable all the ways to download, just the download button on the native controls bar. The context menu would work as before, for example. In that sense, it'd be inconsistent from disableRemotePlayback which disables every way of remoting the media element (except for things like tab casting).

We could, of course, spec it in a way that allows user agents to only remove the button but I imagine developers using the attribute and focusing their complaints on the context menu.

Or we could disable the menu too and get users who knew about the download item complain.

[Philip Jägenstedt]

Do you know how much work it would be to disable download from the context menu? If it's just a few lines here and there, maybe just doing that would be fine? Not doing it would be fine as well, you could wait until someone complains about it.

[Anton Vayvod]

It's more of a compromise between the user's (I want to be able to download videos) and web developer's (I want to make downloading some videos very hard) needs question rather than the implementation difficulty one.

FWIW the plumbing is already there for both Android and desktop.

--

You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To post to this group, send email to blink-api-ow...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAARdPYdPfXWb4xQLpUMz0Yp4y5vN_qemDP1M2wYG4UWJaVocfQ%40mail.gmail.com.

[Mounir Lamouri]

I would be concerned in exposing an API that pretends to block downloads. It would sound like a fake DRM mechanism which I would prefer us to not be part of.

-- Mounir

[Anton Vayvod]

On Tue, Feb 14, 2017 at 12:31 PM 'Mounir Lamouri' via blink-api-owners-discuss <blink-api-ow...@chromium.org> wrote:

I would be concerned in exposing an API that pretends to block downloads. It would sound like a fake DRM mechanism which I would prefer us to not be part of.

-- Mounir

On Tue, 14 Feb 2017 at 17:00 Anton Vayvod <ava...@chromium.org> wrote:

It's more of a compromise between the user's (I want to be able to download videos) and web developer's (I want to make downloading some videos very hard) needs question rather than the implementation difficulty one.

FWIW the plumbing is already there for both Android and desktop.

On Tue, Feb 14, 2017 at 11:44 AM Philip Jägenstedt <foo...@chromium.org> wrote:

On Tue, Feb 14, 2017 at 10:33 PM Anton Vayvod <ava...@chromium.org> wrote:

On Tue, Feb 14, 2017 at 5:52 AM Jochen Eisinger <joc...@chromium.org> wrote:

btw, it seems to me that API owners isn't necessarily the right set of ppl to give advice here, but you should talk to ergonomics (+Ian Kilpatrick) and predictiability

Thanks, I would also like to know what Rick and Ian think on the matter.

The original proposal seems to have high ergonomic benefits and low compatibility risk if later removed but other browser vendors oppose it.

The question then is whether it's still worth adding this API to Blink and that's why I think Blink API owners are the right people to ask.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CA%2B-LeH8DOnB39ovWe7i_WNMSDDNcVcf%2BOrTvOzXExQWrYk06Yg%40mail.gmail.com.

[Philip Jägenstedt]

disableRemotePlayback also doesn't really prevent remote playback since a power user with DevTools or an extension can just remove the attribute, would this not be similar? A spec for it could even say in bold that it's just a hint about preferred UI that the UA is free to ignore.

We have a bunch of proposals on the table now, but other vendors aren't keen on adding a download button at this point. I have my own ideas about what would be nicest, but ultimately anything that you can get into some spec and have some other vendor say is acceptable should get 3xLGTM in an Intent to Ship.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CA%2B-LeH8DOnB39ovWe7i_WNMSDDNcVcf%2BOrTvOzXExQWrYk06Yg%40mail.gmail.com.

[Chris Harrelson]

Hi all,

Sorry for the late feedback here. I intentionally didn't comment, reason being that I don't think it's the API owners' place to help design or give direct feedback on the APIs. Our place is to ensure that Blink always makes a strong effort to propose new features in an open and collaborative way. But since it's perhaps come to a head, I'll say more here.

I read through https://github.com/whatwg/html/issues/2293 in some detail just now. My feedback:

* I find the feedback objecting to the proposal legitimate and well-reasoned. I also find the arguments in favor of the proposal reasonable.

* Based on the use-cases discussed there, I think there seems to be a way to achieve the use-case while also respecting the concerns, those concerns being: user agent vs author agent, compat across browsers, and the principle of not adding APIs that have no strong use-case as yet identified.

* Proposal #3 and retaining the download button in the context menu, I think satisfies those concerns sufficiently, would be accepted by those commenting on the issue, and as far as I can tell would achieve the goal of the feature.

Chris

p.s. Please don't read my comments above as any criticism of the emails on this thread, just an explanation of why I didn't respond until now. It's been a good discussion. :)

On Tue, Feb 14, 2017 at 8:51 PM, Philip Jägenstedt <foo...@chromium.org> wrote:

disableRemotePlayback also doesn't really prevent remote playback since a power user with DevTools or an extension can just remove the attribute, would this not be similar? A spec for it could even say in bold that it's just a hint about preferred UI that the UA is free to ignore.

We have a bunch of proposals on the table now, but other vendors aren't keen on adding a download button at this point. I have my own ideas about what would be nicest, but ultimately anything that you can get into some spec and have some other vendor say is acceptable should get 3xLGTM in an Intent to Ship.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.
To post to this group, send email to blink-api-owners-discuss@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAARdPYdPfXWb4xQLpUMz0Yp4y5vN_qemDP1M2wYG4UWJaVocfQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.
To post to this group, send email to blink-api-owners-discuss@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CA%2B-LeH8DOnB39ovWe7i_WNMSDDNcVcf%2BOrTvOzXExQWrYk06Yg%40mail.gmail.com.

--

You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.
To post to this group, send email to blink-api-owners-discuss@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAARdPYcKPDmYHnpvEsi6sEBuj7hW-0U%2B89a3HGS0hp1m65bbdA%40mail.gmail.com.

[Rick Byers]

Sorry for the delay in responding, I've been trying to digest this whole thing.

From an API owners perspective I think all 3 solutions put us in a place of wanting to ship an API that isn't relevant or interesting to any other engine, but has lots of urgent developer demand for chromium.  This is definitely a difficult place to be on an "intent to ship", but IMHO doesn't necessarily mean we shouldn't still ship.  In particular, if there were technical objections to why the API could not be interoperable in the future should the use case come to matter for another browser, that would be greater cause for concern from my perspective.  But, from a predictability perspective, NOT having some reliable way to disable Chrome's "download" control (without resorting to hacks like replacing all the controls with custom ones) is probably worse for developers than having an API that for the foreseeable future has relevance only to Chrome.

This "we don't want this in the HTML spec because it makes no sense for our browser" is exactly one of the sorts of objections that our incubation-first standards policy is designed to address.  It seems likely that any API here won't get into the HTML standard any time soon, but should instead go through some incubation elsewhere (ideally WICG if we can find anyone outside the chromium project interested in collaborating or giving feedback on the design).  To ship something we'll definitely want a precise spec in a GitHub repo somewhere people can file issues on.

At this point it sounds like you've done a thorough job of collecting design feedback from engineers on chromium and other engines, and you should probably just pick the design you think best balances the concerns and propose shipping it.  We should certainly try to minimize the technical objections (eg. maybe Apple's feature detection concern is worth addressing - i.e. prefer #2 or #3 over #1).  And the fact that no other engine is interested in implementing is a substantial concern. But if we can show:

• Why this is important for chromium (the developer demand and risk of disabling all native controls you site is compelling to me)
• That we've made our best effort to specify the API precisely and respond to feedback so that it could be implemented interoperably in the future should some engine decide the use case is relevant to them
• That the compat risk of needing to change/remove the API in the future is low (eg. the fact that the API is very small helps, and #2 seems a bit safer than #1 in this regard).

Then I'd personally argue that you've met the bar for shipping this feature.

Rick

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsubscr...@chromium.org.

To post to this group, send email to blink-api-owners-discuss@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAARdPYdPfXWb4xQLpUMz0Yp4y5vN_qemDP1M2wYG4UWJaVocfQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsubscr...@chromium.org.

To post to this group, send email to blink-api-owners-discuss@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CA%2B-LeH8DOnB39ovWe7i_WNMSDDNcVcf%2BOrTvOzXExQWrYk06Yg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsubscr...@chromium.org.

To post to this group, send email to blink-api-owners-discuss@chromium.org.

[Anton Vayvod]

Apple's concern about feature detection will only be addressed by something like #2 as Philip pointed out in the GitHub discussion (https://github.com/whatwg/html/issues/2293#issuecomment-274966480). Having no feature detection causes problems though that Philip and Domenic identified above.

I also highly doubt web developers will suddenly drop support for videos on Safari because it doesn't support some API -- they didn't even have an option of having custom controls until recently.

That aside, any option here seems to have high interoperability risk because we don't have other browsers support so according to the Blink policy we'd have to prove the change moves the web forward:

"If a change has high interoperability risk but is expected to significantly move the web forward, Blink will sometimes welcome it after careful, publicly-explained consideration." -- https://www.chromium.org/blink#TOC-Policy-for-shipping-and-removing-web-platform-API-features

Since "significantly" is a vague term, I thought discussing it here ahead of an Intent to Ship makes sense. I'm happy to continue the conversation on an Intent to Ship thread and I apologize if I used blink-api-owners-discuss@ inappropriately.

That said, I don't see how #3 moves the web forward.

I believe #1 does though, in a number of ways:

a) it keeps the web authors confident they won't have to write custom controls in the future when Chrome adds a new media control -- the path to add an opt-out would be straightforward and they can expect it as soon as the new feature ships

b) it continues providing users with new features -- as a consequence of a) above

c) it makes expanding and maintaining customization of media controls easier for Blink developers -- since the API is extendable and centralized by design.

Since the API is small and is feature detectable, the compatibility risk should be small. Specifying how it works in WICG sounds good to me.

On Wed, Feb 15, 2017 at 2:37 PM Rick Byers <rby...@google.com> wrote:

Sorry for the delay in responding, I've been trying to digest this whole thing.

From an API owners perspective I think all 3 solutions put us in a place of wanting to ship an API that isn't relevant or interesting to any other engine, but has lots of urgent developer demand for chromium.  This is definitely a difficult place to be on an "intent to ship", but IMHO doesn't necessarily mean we shouldn't still ship.  In particular, if there were technical objections to why the API could not be interoperable in the future should the use case come to matter for another browser, that would be greater cause for concern from my perspective.  But, from a predictability perspective, NOT having some reliable way to disable Chrome's "download" control (without resorting to hacks like replacing all the controls with custom ones) is probably worse for developers than having an API that for the foreseeable future has relevance only to Chrome.

This "we don't want this in the HTML spec because it makes no sense for our browser" is exactly one of the sorts of objections that our incubation-first standards policy is designed to address.  It seems likely that any API here won't get into the HTML standard any time soon, but should instead go through some incubation elsewhere (ideally WICG if we can find anyone outside the chromium project interested in collaborating or giving feedback on the design).  To ship something we'll definitely want a precise spec in a GitHub repo somewhere people can file issues on.

At this point it sounds like you've done a thorough job of collecting design feedback from engineers on chromium and other engines, and you should probably just pick the design you think best balances the concerns and propose shipping it.  We should certainly try to minimize the technical objections (eg. maybe Apple's feature detection concern is worth addressing - i.e. prefer #2 or #3 over #1).  And the fact that no other engine is interested in implementing is a substantial concern. But if we can show:

• Why this is important for chromium (the developer demand and risk of disabling all native controls you site is compelling to me)
• That we've made our best effort to specify the API precisely and respond to feedback so that it could be implemented interoperably in the future should some engine decide the use case is relevant to them
• That the compat risk of needing to change/remove the API in the future is low (eg. the fact that the API is very small helps, and #2 seems a bit safer than #1 in this regard).

Then I'd personally argue that you've met the bar for shipping this feature.

Rick

On Wed, Feb 15, 2017 at 1:05 PM, Chris Harrelson <chri...@chromium.org> wrote:

Hi all,

Sorry for the late feedback here. I intentionally didn't comment, reason being that I don't think it's the API owners' place to help design or give direct feedback on the APIs. Our place is to ensure that Blink always makes a strong effort to propose new features in an open and collaborative way. But since it's perhaps come to a head, I'll say more here.

I read through https://github.com/whatwg/html/issues/2293 in some detail just now. My feedback:

* I find the feedback objecting to the proposal legitimate and well-reasoned. I also find the arguments in favor of the proposal reasonable.

* Based on the use-cases discussed there, I think there seems to be a way to achieve the use-case while also respecting the concerns, those concerns being: user agent vs author agent, compat across browsers, and the principle of not adding APIs that have no strong use-case as yet identified.

* Proposal #3 and retaining the download button in the context menu, I think satisfies those concerns sufficiently, would be accepted by those commenting on the issue, and as far as I can tell would achieve the goal of the feature.

Chris

p.s. Please don't read my comments above as any criticism of the emails on this thread, just an explanation of why I didn't respond until now. It's been a good discussion. :)

On Tue, Feb 14, 2017 at 8:51 PM, Philip Jägenstedt <foo...@chromium.org> wrote:

disableRemotePlayback also doesn't really prevent remote playback since a power user with DevTools or an extension can just remove the attribute, would this not be similar? A spec for it could even say in bold that it's just a hint about preferred UI that the UA is free to ignore.

We have a bunch of proposals on the table now, but other vendors aren't keen on adding a download button at this point. I have my own ideas about what would be nicest, but ultimately anything that you can get into some spec and have some other vendor say is acceptable should get 3xLGTM in an Intent to Ship.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To post to this group, send email to blink-api-ow...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAARdPYdPfXWb4xQLpUMz0Yp4y5vN_qemDP1M2wYG4UWJaVocfQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To post to this group, send email to blink-api-ow...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CA%2B-LeH8DOnB39ovWe7i_WNMSDDNcVcf%2BOrTvOzXExQWrYk06Yg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To post to this group, send email to blink-api-ow...@chromium.org.

[Rick Byers]

On Wed, Feb 15, 2017 at 5:12 PM, Anton Vayvod <ava...@chromium.org> wrote:

Apple's concern about feature detection will only be addressed by something like #2 as Philip pointed out in the GitHub discussion (https://github.com/whatwg/html/issues/2293#issuecomment-274966480). Having no feature detection causes problems though that Philip and Domenic identified above.

I also highly doubt web developers will suddenly drop support for videos on Safari because it doesn't support some API -- they didn't even have an option of having custom controls until recently.

That aside, any option here seems to have high interoperability risk because we don't have other browsers support so according to the Blink policy we'd have to prove the change moves the web forward:

"If a change has high interoperability risk but is expected to significantly move the web forward, Blink will sometimes welcome it after careful, publicly-explained consideration." -- https://www.chromium.org/blink#TOC-Policy-for-shipping-and-removing-web-platform-API-features

Since "significantly" is a vague term, I thought discussing it here ahead of an Intent to Ship makes sense. I'm happy to continue the conversation on an Intent to Ship thread and I apologize if I used blink-api-owners-discuss@ inappropriately.

Not at all, this has been a great discussion!   I just don't want you guys to feel blocked.  Ultimately there's nobody here who is going to make tough API design trade offs for you :-).  You should feel empowered (as the ones who will own this API) to collect all the feedback you've been given and choose the path you feel is best to best balance the trade offs.

Certainly the discussion around which options are likely to be considered to meet the bar for the (unfortunately vague and hard to interpret) launch guidelines is a perfect thing to discuss here.  

I think the feedback so far as been that #3 seems likely to meet the bar (there's some support from Apple and Mozilla for that design, even if they have no need to implement in the foreseeable future).

My opinion was that #1/#2 could also meet the bar if we can address the concerns (though perhaps Chris or others disagree?).  Eg. it seems (unless I missed it) that we don't yet have much evidence of demand to back up the additional use cases beyond "no download".  Are there concrete examples you can point to of developers disabling native controls today for something that would be addressed by this API (but not also addressed by the addition of a small number of 'nofoo' attributes as Apple and Mozilla appear to prefer?  Can we find any developers who say they'd switch from custom controls to this new API even if the API was Chrome only?

That said, I don't see how #3 moves the web forward.

Well the urgent "move the web forward" we need here is resolving the developer complaint about not being able to remove the download button.  "moving the web forward" doesn't necessarily need to be some larger-scope thing with a view to the future.

I believe #1 does though, in a number of ways:

a) it keeps the web authors confident they won't have to write custom controls in the future when Chrome adds a new media control -- the path to add an opt-out would be straightforward and they can expect it as soon as the new feature ships

Well you still have to spec the token, which (focusing just on the tech, not the politics) should be no more difficult than speccing a new 'nofoo' attribute, right?  And if it's only Chrome that ships the API, will developers use it?  It doesn't "move the web forward" if almost nobody ends up using that additional capability because they have to write custom controls to get what they want on Safari anyway.  I'm not saying it doesn't, just that some concrete evidence from developers beyond the "I don't want the download button" use case would make your argument a lot more compelling.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.
To post to this group, send email to blink-api-owners-discuss@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAARdPYdPfXWb4xQLpUMz0Yp4y5vN_qemDP1M2wYG4UWJaVocfQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.
To post to this group, send email to blink-api-owners-discuss@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CA%2B-LeH8DOnB39ovWe7i_WNMSDDNcVcf%2BOrTvOzXExQWrYk06Yg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.
To post to this group, send email to blink-api-owners-discuss@chromium.org.

[Philip Jägenstedt]

On Thu, Feb 9, 2017 at 2:34 AM Domenic Denicola <dom...@google.com> wrote:

On Wed, Feb 8, 2017 at 2:19 PM Philip Jägenstedt <foo...@chromium.org> wrote:

The main consideration here is whether a change like this will eventually be implemented in all engines, or if it will fall short of that and leave us wondering in 3 years whether to try removing or not.

In the specific case of a download button, it is not a given that this would become ubiquitous and push others to implement the same opt-out mechanism. Perhaps most plausibly, it might be overtaken by some page-wide or video-specific "save for offline" feature that people might want a different opt-out for.

Given that, and the skepticism from other vendors, I think it makes sense to plan for the outcome that this doesn't get much traction. It will make the API worse, and we shouldn't do it in general.

The option that would make this the easiest to remove while still keeping the door open to exposing this with a nicer API and allowing feature detection is, IMHO, option 2.

There is one downside that I hadn't thought about before. Setting video.controls = false would remove the attribute, so one couldn't toggle the controls on and off while preserving the opt-outs. This is unlike classList, where the mere presence of the class attribute is in itself not meaningful. Did you already discuss this, Mounir and Anton?

Other than that, I think that the only complaints I would anticipate with option 2 would be:

• We are making it impossible to ever overload the controls attribute to be anything other than a list of tokens. This seems fine.
• It's not possible to feature detect. (Which is kind of the point.)
• controls="nodownload" will start appearing in the wild, which is ugly in the same way that sprinkling playsinline attributes is ugly.

Another downside of option 2 is that 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.

Domenic, are you sure that these frameworks actually require the reflection to work? I imagine that some engines have forgotten to reflect some attributes from time-to-time, and that they have a workaround for this?

I tried to find the answer in https://github.com/facebook/react but there's a lot of code and I'm not sure I found the right "setAttribute".

[Domenic Denicola]

I don't know for sure myself, as I too have not been able to read the source code very accurately. What I do know is that several of the React leads at Facebook reached out to us directly about ensuring that all HTML attributes are reflected as properties going forward, and I assured them that this was how HTML spec development was done these days.

Combined with the failures you noted about combining controlsList and controls IDL attributes, I think in general it is a bad pattern to attempt to upgrade a boolean attribute to a token list, and whatever we do, we should not do that. I still think the solution #3 (a separate nodownload attribute) is by far the best, but if people don't like that, then some separate attribute (e.g. controlslist="nodownload") will be better than trying to change the meaning of controls="".

 

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To post to this group, send email to blink-api-ow...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAARdPYf-U7jS%3DHGuGv8zOfA0E_kHzWiCKHV1n6t_GKGC0kV-Tg%40mail.gmail.com.

[Philip Jägenstedt]

On Thu, Feb 16, 2017 at 11:54 PM 'Domenic Denicola' via blink-api-owners-discuss <blink-api-ow...@chromium.org> wrote:

On Wed, Feb 15, 2017 at 10:56 PM Philip Jägenstedt <foo...@chromium.org> wrote:

On Thu, Feb 9, 2017 at 2:34 AM Domenic Denicola <dom...@google.com> wrote:

On Wed, Feb 8, 2017 at 2:19 PM Philip Jägenstedt <foo...@chromium.org> wrote:

The main consideration here is whether a change like this will eventually be implemented in all engines, or if it will fall short of that and leave us wondering in 3 years whether to try removing or not.

In the specific case of a download button, it is not a given that this would become ubiquitous and push others to implement the same opt-out mechanism. Perhaps most plausibly, it might be overtaken by some page-wide or video-specific "save for offline" feature that people might want a different opt-out for.

Given that, and the skepticism from other vendors, I think it makes sense to plan for the outcome that this doesn't get much traction. It will make the API worse, and we shouldn't do it in general.

The option that would make this the easiest to remove while still keeping the door open to exposing this with a nicer API and allowing feature detection is, IMHO, option 2.

There is one downside that I hadn't thought about before. Setting video.controls = false would remove the attribute, so one couldn't toggle the controls on and off while preserving the opt-outs. This is unlike classList, where the mere presence of the class attribute is in itself not meaningful. Did you already discuss this, Mounir and Anton?

Other than that, I think that the only complaints I would anticipate with option 2 would be:

• We are making it impossible to ever overload the controls attribute to be anything other than a list of tokens. This seems fine.
• It's not possible to feature detect. (Which is kind of the point.)
• controls="nodownload" will start appearing in the wild, which is ugly in the same way that sprinkling playsinline attributes is ugly.

Another downside of option 2 is that 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.

Domenic, are you sure that these frameworks actually require the reflection to work? I imagine that some engines have forgotten to reflect some attributes from time-to-time, and that they have a workaround for this?

I tried to find the answer in https://github.com/facebook/react but there's a lot of code and I'm not sure I found the right "setAttribute".

I don't know for sure myself, as I too have not been able to read the source code very accurately. What I do know is that several of the React leads at Facebook reached out to us directly about ensuring that all HTML attributes are reflected as properties going forward, and I assured them that this was how HTML spec development was done these days.

Combined with the failures you noted about combining controlsList and controls IDL attributes, I think in general it is a bad pattern to attempt to upgrade a boolean attribute to a token list, and whatever we do, we should not do that. I still think the solution #3 (a separate nodownload attribute) is by far the best, but if people don't like that, then some separate attribute (e.g. controlslist="nodownload") will be better than trying to change the meaning of controls="".

Hmm, yes. To elaborate a bit, my fear is that frameworks that allow setting multiple attributes at once may not guarantee the order in which individual attributes are set. This may not be a problem, but using a separate attribute would be more conservative.

If the only use case is disabling controls and not opting in to them, then a nocontrols="download etc" or disablecontrols="dowload etc" would work.