Same in Chrome Dev 58.0.3026.5

We don't show the play overlay for custom controls. This is working as intended. I think showing the overlay would be fairly annoying to websites that will probably work on hiding it.

The way to hide the play overlay would be to use playsinline attribute. This seems to be the way to go actually.

Please let's make the web consistent there!
Note that I'm talking about mobile not dekstop.

fbeaufort@, let see what dahlke@ and rachelis@ think. I'm happy to defer to them. Though, I think the consistency argument doesn't work very well here because websites are unlikely expecting this from Chrome and we would break them in many ways (happy to develop why). The benefit of adding this overlay sounds quite low compared to the cost.

For the sake of clarity

- iOS:     <video> shows a play overlay button
- Android: <video> does NOT show a play overlay button 

- iOS:     <video playsinline> does not show a play overlay button
- Android: <video playsinline> does not show a play overlay button

It seems to me that the iOS behaviour is correct.
If websites don't want a play overlay button, they'll set the "playsinline" attribute as it is recommended.

And as it already works this way on iOS, I believe we're breaking websites there but just making sure a web experience is the same on iOS and Android.

You make a good argument, fbeaufort. However, I suspect that developers expect the current state and if it is not desirable have worked around it. As I troll through a bunch of sites that use custom controls, every one of them have their own play overlay. If we put one in, we will impact all those sites without warning. This is one case where consistency is likely far more expensive than not. If we had a bunch of devs complaining about this, then maybe it is worth the push, but in absence, I think we will create more problems then we solve. 

May you share sites you've visited that use custom controls?
I suspect those use poster image as well in this form:

<div id="container">
  <video>
  <img id="posterImage">
  <button id="customPlayOverlayButton">
</div>

That means this wouldn't impact them as the poster image would cover the play overlay button.

Sorry for the late response. I think you are correct, most of the sites that I was thinking of were using a poster image instead of a play button overlay. That said, I am still hesitant to mess around with the ecosystem when we aren't really solving a problem. 

mlamouri@, in comment 5 you said you are "happy to develop why" we would break sites. Could you expound? 

It sounds like we're debating between interop (browsers behaving the same as eachother) and compat (Chrome behaving the same from one version to the next).  This is definitely something we struggle with, but in general on the web platform team we tend to favor interop over compat (favoring long-term concerns over short-term ones).  Some of the compat principles here might help: https://docs.google.com/document/u/2/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit?usp=drive_web

One middle ground is to design new APIs whose behavior is explicit, while leaving the default behavior implementation defined.  Eg. if Safari folks had liked the controlsList API, then maybe controlsList=playoverlay / controlsList=noplayoverlay could be the explicit API here, while the default when unspecified would still be implementation defined?

Anyway feature teams are the experts in their areas so are ultimately the ones who need to make the difficult compat vs. interop tradeoffs.

rbyers@, I would be very interested to hear why you see this as an interop issue. To me it is at best a web developer experience consistency which I can be sympathetic of but we are talking about the UA injecting a UI in a <video> element when nothing was asked by the web page. Given that websites can't control or be aware of this, it doesn't sound like an interop issue to me. It could be a compat problem though.

I have two compat concern. One is purely aesthetics and some websites might have their UI slightly broken because of an unexpected play overlay popping up. The other concern could be if a website implements a click to play behaviour or something similar. In this case, the play overlay would take priority and would be the one that would be clicked. As a consequence, the video would be played by the UA which might not be expected and break the player, potentially leaving it in a broken state. All these issues can't be discovered until we implement and launch the feature which is why I think it's a high cost.

For info, UC Browser shows some UI on a simple <video> element.

Deleted: Screenshot_20170406-142435.png 81.7 KB

	Screenshot_20170406-142435.png 81.7 KB View Download

UC browser *always* show native controls so I don't think it's a great example :)

TBH, the playsinline iOS behavior is not reflected in the spec (as the play overlay button):

"The playsinline is a boolean attribute. If present, it serves as a hint to the user agent that the video ought to be displayed "inline" in the document by default, constrained to the element's playback area, instead of being displayed fullscreen or in an independent resizable window.

The absence of the playsinline does not imply that the video will display fullscreen by default. Indeed, most user agents have chosen to play all videos inline by default, and in such user agents the playsinline attribute has no effect."

I don't see why playsinline should mean no extra UI in the inline+custom controls state.

I see the usability problem though. If the user goes to a website that doesn't provide controls and relies on the video autoplaying (e.g. old desktop only website that doesn't know about autoplay muted or user gesture requirement), it will appear broken to users who do want to play the content but have no way to do so.

Perhaps Safari simply relies on playsinline attribute as a hint that custom controls are provided because that's the only way to implement custom controls on iOS phones.

The usability problem might become worse on desktop if we introduce more restrictive autoplay policies.