Why not use the Safari API?

[sicking]

It's not a very clean API, but i'm not sure that it's worth trying to deprecate existing content in order to get a cleaned up API. Previous similar attempts for other APIs have failed.

https://developer.apple.com/library/safari/releasenotes/General/WhatsNewInSafari/Articles/Safari_7_0.html#//apple_ref/doc/uid/TP40014305-CH5-SW7

[mounirlamouri]

The Safari Airplay API isn't actually used that much on the Web. The most commonly used attributes are the ones that enable/disable the airplay button. Most websites actually "enable" it which is the default behaviour anyway.

I don't think it's worth having all browsers implement the API.

[jernoble]

@sicking Are you referring to the

[sicking]

I was referring to both. I.e. the x-webkit-wirelessvideoplaybackdisabled markup attribute, the wirelessvideoplaybackdisabled DOM property (i'm not sure about the spelling) the webkitplaybacktargetavailabilitychanged event and the webkitShowPlaybackTargetPicker() DOM method.

[mounirlamouri]

I am tracking a few metrics about the usage of the webkit prefixed API (using internal Google tools). The overview is:

• webkitShowPlaybackTargetPicker(), webkitplaybacktargetavailabilitychanged and webkitCurrentPlaybackTarget are virtually unused on the Web. There is at best two dozens websites using those.
• x-webkit-airplay=deny and x-webkit-wirelessvideoplaybackdisabled are used by three dozen websites.
• x-webkit-airplay=allow and x-webkit-airplay (no attribute) is used significantly more. Three order of magnitude more. Though, these attributes are a no-op.

Thus, as much as I think we should use this API as a legacy to understand the UC, I don't think there is any benefit for the Web to standardize it as-is.

[jernoble]

@mounirlamouri

I am tracking a few metrics about the usage of the webkit prefixed API (using internal Google tools).

Google's spider and usage counters aren't browsing the web under a Mac or iOS Safari User Agent, so you're missing every site with UA-specific behavior. Including, for example, YouTube, DailyMotion, & Vimeo, among others, which I'm sure you'll agree is a large percentage of internet video.

So, I would argue that your "internal Google tools" are almost entirely useless for this purpose.

That said:

Thus, as much as I think we should use this API as a legacy to understand the UC, I don't think there is any benefit for the Web to standardize it as-is.

I agree. For one, "AirPlay" is a trademarked term, so it doesn't belong in a spec. And you can "cast" to a remote over a wired connection as well as a "wireless" one. Replace all instances of "airplay", "wireless playback" with "remote playback", and you have something spec-able.

[mounirlamouri]

Yes, I have no doubt that some websites have UA specific behaviour but it's not relevant to the discussion: for other browsers to have an interest in implementing proprietary APIs, a large chunk of the web needs to be using these APIs so that implementing them would enable new features on these websites. I don't think this is the case here.

[jernoble]

It's unfortunate that so many video sites, including Google's, have decided to do UA sniffing rather than feature detection in this case. However, it would be much easier for sites to drop their UA sniffing behavior than for them to re-implement under an entirely new–and possibly incompatible–remote playback API.

[sicking]

Right, that is my feeling too. The goal to me isn't to get a lot of websites to automatically start working. The goal is to get adoption of whatever we implement. The amount of work a website has to do definitely has a big effect on that.

That said, if the number of websites that use the safari API is really low, then I agree that that makes it less important to use the existing API.

[avayvod]

As I understand it, the resolution is that there are advantages to implementing an unprefixed API with a specification over implementing the existing prefixed Safari API: the existing adoption is not high enough to justify the latter for other browser vendors and the sites behavior will likely be improved with the adoption of the Remote Playback API. Feel free to reopen the issue if it needs to be discussed further.