Html: Add equivalent of webkit-playsinline attribute to <video>

[hober]

Background: now that WebKit's new prefixing policy is in place, I'm looking at existing features to see which can be safely unprefixed.

On small iOS devices, videos play in fullscreen by default. Some apps & frameworks which embed WebKit (e.g. iAds) needed a way for content to opt in to inline playback, so we support a webkit-playsinline attribute.

I don't know offhand what implementations on e.g. Android do, but if other folks would also find such an opt-in useful I'd love it if we could converge on a common attribute for this. As for naming, playsinline(simply unprefixing the existing WebKit name) would be fine, but I'd be happy with some other name too.

[domenic]

@mounirlamouri, what do you think of this in the Chrome context?

Anyone know who to ping for Gecko and Edge?

[miketaylr]

Anyone know who to ping for Gecko

Possibly @leibovic (or she would know the right person).

[mounirlamouri]

A boolean to give a hint to the UA to play the video inline doesn't seem to be interesting for most UA given that they already play the video inline. As far as I know only Safari on phones doesn't.

Regarding implementation in Chrome, I believe there is nothing to implement as such an attribute would be a no-op in the current context. Obviously, this is assuming that browsers play the video inline unless asked to play the video fullscreen via the Fullscreen API. If things were to change, this attribute could be needed.

In the context of unprefixing webkit- attributes, it doesn't seem to be the highest priority given that it will not help web compat. The attribute's behaviour can't be detected by developers which will have to rely on UA sniffing to know if they need it and if it will actually have an effect.

[leibovic]

Anyone know who to ping for Gecko

Possibly @leibovic (or she would know the right person).

I am not the right person :) Randall Barker has been working on media on Android, or you could ask Anthony Jones for a more general media issue.

[mounirlamouri]

/CC @kentuckyfriedtakahe (Anthony Jones)

[hober]

Safari on iPhone on iOS 10 will also respect this attribute: https://developer.apple.com/library/prerelease/content/releasenotes/General/WhatsNewInSafari/Articles/Safari_10_0.html#//apple_ref/doc/uid/TP40014305-CH11-DontLinkElementID_12

I hope we can come up with a cross-browser form for the opt-in to take, though I realize that other browsers don't have the same compat problem that requires Safari to have an opt-in.

[grorg]

Note that when @hober said "Safari on iOS 10" he actually meant "Safari on iPhone on iOS 10". This attribute has been supported on iPad for 6 years now.

[grorg]

It is also necessary to have a media query to detect inline playback support. We added -webkit-video-playable-inline in iOS 4 too.

If we can decide on an attribute name soon then Apple can implement it in time for the actual iOS 10 release.

[domenic]

It seems to me we have two options:

• Standardize some attribute, named either webkit-playsinline or playsinline, which serves as some kind of presentational hint that the author intends the video to play inline. Its absence means the UA chooses; its presence means that the video plays inline. For UAs besides iOS Safari, this attribute is a no-op; the "hint" is unnecessary.
• Acknowledge that this is a UA-specific feature, only needed by one UA, and thus should remain proprietary to that UA. There's no need to standardize it.

It seems to me we have some precedent for standardizing something which is in effect just a pragma to help certain user agents overcome their legacy compatibility constraints, and which has no effect in most browsers: https://html.spec.whatwg.org/multipage/semantics.html#attr-meta-http-equiv-x-ua-compatible

In practice, this pragma encourages Internet Explorer to more closely follow the specifications.

...

User agents are required to ignore this pragma.

With this in mind I'd probably suggest us specifying this under the name webkit-playsinline, and saying something like

Provides a hint to the user agent that the video should be played inline, instead of going fullscreen on playing. In practice, this attribute is used to encourage iOS Safari to behave the same as other browsers.

In particular I don't see any reason to specify it under a new name like playsinline, given that this has been supported on the iPad for 6 years and presumably isn't going away. It's very much like X-UA-Compatible/IE=edge, and there's no reason to tell authors to churn their code to a new version just to make us feel like it's less UA-specific than it really is.

[patrickhlauke]

My only concern here would be that this once again places the onus on developers to add this new magic pragma to all their future content to normalize behavior, to make one UA behave like most other UAs have been behaving for years (just like the X-UA-Compatible hint, or more recently (and non-standardly) shrink-to-fit=no viewport directive)...

[domenic]

My only concern here would be that this once again places the onus on developers to add this new magic pragma to all their future content to normalize behavior, to make one UA behave like most other UAs have been behaving for years

Yeah, that's true, but I don't think there's anything we can do in standards space to change that reality. It's been the case for years and from what we're hearing in this thread will be the case for many years to come. Putting something in the spec makes it moderately easier for authors to learn about the necessity to do this, and avoids them getting yelled at by conformance checkers when all they're trying to do is make their page work the same cross-browser. I'm beginning to think it's strictly better to put it in the spec than to leave it out.

[othermaciej]

We would strongly prefer that the standardized version should not be named starting with webkit-.

I don't believe there is a body of legacy content meaningfully using that name on the public web. Dean was mistaken about Safari for iPad supporting the attribute. It allows inline video playback by default, with no need for webkit-playsinline. So there is no reason for public web content to use it.

We'd rather not push new public content to use a webkit-prefixed attribute that was previously only used in app-specific content.

Additionally: given a standardized non-prefixed name, we can limit the webkit-prefixed version only to non-browser apps so it doesn't creep into the public web.

It would be simpler if we could default all video to be non-fullscreen on iPhones but we don't think that is viable for compatibility reasons, since some sites serve iPhone-specific content with video players that lack controls, on the expectation that video will be fullscreen.

[domenic]

I don't believe there is a body of legacy content meaningfully using that name on the public web. Dean was mistaken about Safari for iPad supporting the attribute. It allows inline video playback by default, with no need for webkit-playsinline. So there is no reason for public web content to use it.

...

Additionally: given a standardized non-prefixed name, we can limit the webkit-prefixed version only to non-browser apps so it doesn't creep into the public web.

Ah, OK, that changes things considerably with regard to the naming situation. It still doesn't help developers, as they need to continue adding the magic pragma to make iOS Safari behave the same as other browsers, but at least they can avoid using the characters "webkit-" while doing so.

At this point it seems like we have the choice between taking some kind of principled stance that UA-specific pragmas should stay out of the standard, or bowing to practicality and including them. I see no need to punish developers by telling them their code is non-conformant when they use such a pragma. And we have precedent. I'm happy to work on a spec for playsinline in that vein.

Was there any consideration for a page-wide pragma? <meta http-equiv="X-UA-Compatible2">, perhaps? ;) or <html videoplaysinline>, or similar. That might be more developer-friendly, as it can simply become part of the boilerplate similar to X-UA-Compatible for those writing cross-browser code, instead of having to be added to every <video> tag.

[patrickhlauke]

Was there any consideration for a page-wide pragma?

my guess would be that Apple likely still want to offer developers the ability to determine player behavior on a per-video basis even within the same document.

would the spec text also make it clear that this attribute is a no-op in browsers other than iOS Safari, which already default to this behavior?

[zcorpan]

Note that the spec has x-ua-compatible as an allowed but no effect pragma. It was added only after it was widely used by web developers, though.

[othermaciej]

I'm not sure a page-wide pragma is a good solution, since pages may contain video that comes from different sources (for example their own, an offsite embed from a third-party video provider, and an ad) which may not be equally equipped to handle inline playback.

---

By the way, I notice an undertone of complaint/frustration that iPhone Safari is different in this regard. Our read of the spec was that it allows presenting all video as full screen by default, or at least doesn't disallow it.

It may be that Safari on iPhone is the only UA that made use of this provision (I don't actually know for sure), but there's nothing intrinsically UA-specific about it. And in an era of smaller phone screens, hardware that could better optimize fullscreen playback, and webpages that were not specifically mobile-optimized, it seemed like a pretty reasonable choice.

Now that all those factors have changed, we don't think it's right to enforce fullscreen on iPhones. But for legacy reasons we're not sure we can just reverse the default instead of giving an opt-out. If anyone has a better suggestion for how to resolve this dilemma, we are open to suggestion.

---

There's a possible alternative here: instead of just a legacy workaround, there could be a useful feature to have video play inline by default, full screen by default, or respect the UA's default setting. In many cases, it may still be useful for video to play full screen by default on a device with a smaller screen. Officially the only way to do this would be to have your play button call enterFullscreen() before play() (I guess only the first time, if the player supports popping back to inline?), which is somewhat awkward. But we weren't sure the genuine feature version of this had enough value, so we're proposing what is effectively just a legacy workaround instead.