Establish Conventions for (Un)supported and (Un)available states.

[cjpillsbury]

There are several states/properties that may be unsupported or unavailable in a given use case/environment for media chrome. The purpose of this discussion is to establish a convention for naming and managing these two scenarios.

Overview

Categories

(Un)supported

These are states/features and the like that are unavailable or cannot be changed within a given runtime/execution environment. Conceptually at least, these should only need to be checked once and should never change within a runtime. Since these may be asynchronous, we may want/need to distinguish between three different states:

• Supported
• Unsupported
• Unknown

We could assume either supported/unsupported (generally or on a case by case basis), though this may add complexity if things like show/hide or enabled/disabled states/styles for particular components are being driven by these values.

Examples:

• volume (unsupported on mobile devices/tablets)
• airplay (only supported in safari)

(Un)available

These are states/features and the like that are supported but are currently unavailable based on details of the media content or other environmental factors. These can change dynamically, including for a particular instance of a media-controller and/or slotted media. Since these may be asynchronous, we may want/need to distinguish between three different states:

• Available
• Unavailable
• Unknown

We could assume either available/unavailable (generally or on a case by case basis), though this may add complexity if things like show/hide or enabled/disabled states/styles for particular components are being driven by these values.

Examples:

• Captions/Subtitles (media.textTracks dynamically updated. Conceptually at least, this could be accounted for based on having an empty MEDIA_CAPTIONS_LIST/MEDIA_SUBTITLES_LIST, respectively)
• airplay (may change based on switching networks, turning on/off airplay devices, and the like)

Convention Proposals

This is just a starting proposal but I'm open to alternatives as long as they capture the relevant cases and communicate effectively.

General

If the corresponding attribute is absent on a given media state receiver/component, that component should "assume" the relevant state/feature is supported or available. This allows implementations and "out of the box" examples to render/behave/style "as if" something is available, treating unsupported/unavailable (and potentially corresponding unknown states)

Proposal 1 - simple 2 state boolean

• [state]-unsupported
• [state]-unavailable

Boolean attribute convention: if hasAttribute(), implies unsupported/unavailable, otherwise supported/available . Value should be empty string ("") by convention.

Examples:

• captions-unavailable
• airplay-unsupported
• volume-unsupported

Proposal 2 - 3 state

• [state]-support ("UNKNOWN"|"UNSUPPORTED")
• [state]-availability ("UNKNOWN"|"UNAVAILABLE")

Default attribute value convention: if !hasAttribute(), implies supported/available

We may also consider the 3rd state ("SUPPORTED" / "AVAILABLE") as valid explicit values, where !hasAttribute() maps to "SUPPORTED" / "AVAILABLE" more explicitly.

[cjpillsbury]

Depended on/relates to #135

[heff]

I like the use of an attribute for this. That's very targetable, and flexible. You could choose to handle that at the player level, control-bar, the button itself.

What's an example of where we'd want to handle unavailable differently from unsupported, or could we combine them into one?

[cjpillsbury]

What's an example of where we'd want to handle unavailable differently from unsupported, or could we combine them into one?

I think the most likely case would be where folks want to disable for unavailable but hide for unsupported. On our current list, airplay unsupported vs. airplay unavailable is the only real potential contender here: Do we want to make it impossible to hide airplay if unsupported and disable if unavailable and handle? I think most folks hide for both, so could be fine.

What are the primary benefits you see about combining them? I do think the implementation details will be a bit harder to smash the two together, but not enough imo to significantly weigh into our decision, unless that's your motivation for combining them.

[heff]

What are the primary benefits you see about combining them?

Just simplicity unless we know we need the complexity. We don't want to make component authors learn and decide between two different mechanisms if they're ultimately going to use them the same way.

I'm wondering if it'd be easier to get behind if it were one enum, like:

• airplay-status="supported"
• airplay-status="available"
• airplay-status="unsupported"
• No attr = unknown (do we have a good use case for unknown?)

I'm not loving status, though. It doesn't work great for volume-status. Maybe volume-control-status.

I'm having a hard time making airplay "disabled". It's always pulling up a menu with at least my current device. Is that true everywhere? When I turned on airplane mode and turned off wifi, I actually saw MORE airplay options pop up. That's creepy.

[cjpillsbury]

hmmm... I thought the availability event was based on device detection, but I could def be mistaken. Not sure the exact conditions, but you can cause it to go unavailable by disconnecting from wifi. Would need to poke around more to see other conditions that cause it to report 'not-available', since... you know... apple docs. https://developer.apple.com/documentation/webkitjs/adding_an_airplay_button_to_your_safari_media_controls

[cjpillsbury]

No attr = unknown (do we have a good use case for unknown?)

detecting if volume is available is (horribly) async now on mobile safari 15 (see our slack for a discussion on this silliness). If we don't account for that, we will have the possibility of an ugly initial render situation (either show then quickly hide volume slider or hide then quickly show it) 😞.

I do personally think our "default"/no attr situation should be "available" (+ implicitly supported, I'm assuming), regardless of any of the other details. This would allows us to assume "status quo" for the base case/absence of a variable (e.g. our example pages with just the buttons).

I'm not loving status, though. It doesn't work great for volume-status. Maybe volume-control-status

If this is clunky, we could certainly still move forward with "collapsing" supported/available into a single value "available" (since available implies supported and unsupported implies unavailable).

If we stuck with my above proposals, that would mean either the 3-state option, which is my S1 (e.g.):

• airplay-availability="unknown"
• airplay-availability="unavailable"
• No attr = available

or the 2-state option

• airplay-unavailable (/ `airplay-unavailable='' or any value)
• No attr = available

[heff]

I hear what you're saying. I like the potential pattern of the two state option:

1. media-el[nofoo] {} - You can't use it, and you don't care the diff between unsupported and unavailable.
   • I'd expect buttons to auto-disable themselves in either case
2. `media-el[nofoo="bar"] - You care if it's unsupported or just currently unavailable, e.g. disable or hide.
   • I'd expect a control bar to hide unsupported buttons. Maybe allow them to stay if only currently unavailable.
3. media-el {} or `media-el:not([nofoo]) - We'll assume it's supported until told otherwise

The unknown state feels uncomfortable to me. I think partly because the default state is "assume supported" but it's also "unknown". If I have an airplay button on its own, it doesn't know if airplay is supported, and it's gonna try triggering it either way. It's unknown until we run a test that confirms the feature. It feels like we'd be opening the door for every function/feature to need an "unknown" set by default. And one way or another we gotta decide if it's hidden or showing.

detecting if volume is available is (horribly) async

That really sucks. I hate designing around a dumb bug. It looks like the video.js fix waits a single tick. Not great, but I was assuming we meant seconds.

For volume I could see us:

1. Assume by default that volume is supported (set no attr)
2. On iOS (browser detect) assume the opposite and set the attr to unsupported until proven otherwise by the video.js async test
3. Run the async test at javascript load time, don't wait for a media slot to load. Depending on the success or failure of the async test, update our default assumption either way.

After all that I like your 2 state option, including the "or any value" where the value is more info.

media-el[]
media-el[airplay-unavailable]
media-el[airplay-unavailable="unavailable"]
media-el[airplay-unavailable="unsupported"]

Could also consider something like

airplay-unavailable="temporarily" // now, momentarily, atm, afk
airplay-unavailable="permanently" // always, until hell freezes over, ded

[cjpillsbury]

I think the biggest point of contention remaining is including or excluding the "unknown" state. Everything else is feels like details I'm comfortable deferring to you for whatever you prefer. One callout I'll highlight but still would defer to you is the OS detection proposal: previously, you expressed concerns about building in user agent/OS detection because it can easily become a "can of worms." Just want to make sure that original concern/risk is being weighed in the proposal. FWIW It doesn't feel like it would be necessary if we agree to including "unknown" somehow.

Here's how I see the value of "unknown". Not sure if this is a "me thing", but I personally dislike interfaces/apis that

• Have even a small amount of "false advertising"/"lie to me"
  • In the proposed design, we will have cases where something is maybe (un)supported, the API says one thing, and then eventually it says something different.
• Don't provide a way for me to know when something is "being figured out" vs "is figured out"
  • Since the given element may have no property because it is available but may have no property simply because media-controller has yet to determine if it's supported/available, I cannot design in a way that accounts for that difference easily. By way of example, I may want to show an overlay or hide all controls until I know which controls "make sense" for the playback environment and/or media content. In the proposed design, I don't believe that would be possible.

[cjpillsbury]

I'll proceed with on the coarse grained aspects where we agree and assume "unknown" won't be included (and hold off on the OS detection), as that shouldn't be difficult to add as an initial state. If you feel strongly about excluding it, we can exclude it.

[heff]

OS detection proposal...can of worms

In principle I don't think it's something we should regularly rely on, but in the example solution I laid out the downside is pretty small for the times when iOS detection would be wrong. Ultimately the async test still has to run and confirm our initial assumption. The browser check is just helping make a better initial assumption.

FWIW It doesn't feel like it would be necessary if we agree to including "unknown" somehow.

Yeah, but it wouldn't be necessary because we'd be putting it on the component author or media chrome user to understand the nuances and decide what to do in the unknown case rather than being helpful/opinionated (which I understand is the crux of the debate). In the volume case, we can form an opinion on the likely case, that can make the difference between the button awkwardly changing or not for many viewers. A value like "probably" or "probablynot" would be more valuable in this case than just "unknown". But then media chrome users are going to treat "probably" and "definitely" the exact same way.

Have even a small amount of "false advertising"/"lie to me"

Would you be more comfortable with the general direction of airplay-unsupported = 'probably' ?

until I know which controls "make sense" for the playback environment

If needed I think there's probably a better way to solve for this example than an unknown state for each feature. Like a more generalized controller state of "I know what I'm gonna know" across the board. In reality if you care about this you're probably hiding the control bar until firstplay anyway.

I might eat my words but I'm not convinced an unknown state is a good thing in practice. I think we should move forward without and see if it comes up as a clear need later.

[cjpillsbury]

Looks like the OS detection + async volume suppport tests are gonna be more complicated for iPadOS Safari. Here's what I got on a test app I cobbled together, loaded on my iPad+Safari:

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.2 Safari/605.1.15
Supported (Synchronous test): true
Supported (Asynchronous test): false,
initial volume: 1,
attempted volume set: 0.6,
subsequent volume (sync): 0.6,
subsequent volume (async): 1

It seems things are a little better (currently at least) for non-Safari browsers built on the native webkit browser. Here's iPad+Chrome (though the inconsistency is not great):

User Agent: Mozilla/5.0 (iPad; CPU OS 15_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/97.0.4692.84 Mobile/15E148 Safari/604.1
Supported (Synchronous test): true
Supported (Asynchronous test): false, 
initial volume: 1, 
attempted volume set: 0.6,
subsequent volume (sync): 0.6,
subsequent volume (async): 1

[cjpillsbury]

Another callout specific to airplay:
I've successfully confirmed available/unavailable events will fire based on whether or not my AppleTV is unplugged or not (and does so dynamically). However, even if airplay is available, it will not be available for selection until after at least the metadata for the media has loaded. I've confirmed this by changing the preload attribute in our advanced example between "none", "metadata", and "auto". For metadata & auto (assuming airplay is supported & available), the airplay menu will show up when pressing the airplay button. However, no menu will show up if preload="none" (unless/until playback has begun). Whether or not we want to account for this is a separate question, I just wanted it on the radar for discussion/decisions.

[heff]

Ok cool, glad we were able to confirm that. I think that's a point in favor of making disabled vs. hidden possible.

[cjpillsbury]

Found another discrepancy: For iOS/iPadOS Safari, selecting an AirPlay target is available before metadata load. For macOS Safari, it's only available after at least metadata load.