Establish a well-defined way of identifying asynchronously initialized media elements

[cjpillsbury]

NOTE: This should eventually be turned into a proposal, but for now I'd just like to get some thoughts/ideas.

Currently, we have an example of the <youtube-video/> media element that is inherently asynchronous. There are likely to be many examples of these, especially for any player architectures that rely on iframes, remotely-hosted scripts, and the like. We should probably come up with a well-established convention/interface for any media elements that will fall into this category so <media-controller/> can predictably support delaying its state management until after the media is ready.

To also support things like <video/> and to avoid adding additional requirements to other custom media elements, we should minimally expect a property (or attribute, though I'd lean away from that) that <media-controller/> can check for to determine if it should be waiting at all.

If media-chrome identifies the media element as "async initialized", two options I can think of "off the dome" for handling the async:

• make the property mentioned above yield a promise that resolves when the player is ready/initialized
• dispatch a well-defined event for when the media element is ready/initialized and make the property yield a ready/initialized state (boolean).

Things to discuss:

• which of these options (or any additional ideas) should we go with?
• what should we call these things?
• any additional gotchas we might need to consider?

[heff]

I don't think we need an addition and here's what I think we can use to do that:

• play() already uses an async promise
• <video> already errors if you try to seek before loadedmetadata/readyState:HAVE_METADATA. Even if the underlying iframe isn't loaded, the custom media element can still return readyState:0 HAVE_NOTHING
• Otherwise media playback functions have async event responses, so the function calls can be queued until the underlying iframe is loaded

So basically while the underlying player iframe may not be loaded, the custom element can still be providing default states that help know what's possible, or queueing calls to the media functions for when the iframe is ready.

Am I missing anything in that?

[cjpillsbury]

My main concern there is it makes the implementation effort/complexity and, as a consequence, the barrier of entry of these categories of players much higher and the likelihood of bugs/RTEs much greater (as we saw already in our own implementation of <youtube-video/>). This will likely slow down adoption and increase risk when updating versions/codebases for anyone who does adopt using media-chrome.

When the media is slotted, the <media-controller/> invokes a bunch of methods and getters on the media instance (including, e.g. deep references like media.textTracks.etc. I'm worried that this will lead to scenarios where we would want to treat something as a minor/patch update but will result in breaking changes for these elements. While there is some risk of this with any custom media element, I think it's much higher for the "asynchronously initialized" ones.

[heff]

My main concern there is it makes the implementation effort/complexity and, as a consequence, the barrier of entry of these categories of players much higher

That is if you're not using <custom-video>. Implementing the full video API is already a big barrier to entry if you're starting from scratch. Why don't we build <custom-video> for async players and solve this as part of it?

I'm worried that this will lead to scenarios where we would want to treat something as a minor/patch update but will result in breaking changes

I'm not sure what you mean by that. In general I wouldn't be excited to introduce a fundamental API design/requirement like this without being able to point to a clear need. You may ultimately be right, but I'd like to feel the need clearly not speculate, considering what a major difference in the API this would introduce.

[cjpillsbury]

Yeah I think everything you're saying is fair. Let's consider this as answered for now, since we'll have the conversation to refer back to for posterity if it comes up in the future.