[selectors-4] additional resource state pseudo-classes for media elements

[hober]

In §11 Resource State Pseudos we currently have the :playing and :paused pseudo-classes, which collectively address the use case of a custom "play/pause" media control which should appear as a play button or as a pause button depending on the current play state of the associated media element. A bunch of us (@beccahughes @mounirlamouri @padenot @jyavenard @eric-carlson @jernoble et al.) would like to address several related use cases with additional resource state pseudo-classes:

• Whether or not the media element is muted. Use case: styling a custom muted control. Proposal: mint a :muted pseudo-class.
• Whether or not the media element is currently stalled (see several paragraphs in the HTML spec starting at "The stall timeout is a"). Use case: changing the appearance of a loading progress indicator to indicate that loading is currently stalled. Proposal: mint a :stalled pseudo-class.
• Whether or not the media element is currently seeking. Use case: a custom seek control can reflect the case where a user is seeking using some other, UA-provided control. Proposal: mint a :seeking pseudo-class.

Currently, authors of custom media controls have to do some combination of UA-sniffing and other logic from script in order to handle these cases. Ideally, the appearance of such controls would be expressible in CSS, just as play state currently is.

[FremyCompany]

Looks good to me

Shameless plug: http://fremycompany.com/TR/2012/ED-css-content-state/#interactive

[tabatkins]

All these sound good.

For the volume one, is the issue that the UA can let the user dictate the volume, ignoring the volume attribute?

[jernoble]

@tabatkins, essentially yes.

As a concrete example, some sites currently try to detect whether changing volume is supported by setting video.volume to some arbitrary value, and verifying whether that volume value "sticks". (Effectively, let v = video.volume; video.volume *= 0.5; return v !== video.volume;.) That doesn't work if the UA implements step 1 of the effective media volume algorithm. We'd like to give those sites a way of determining this explicitly, without relying upon side effects or heuristics.

[tabatkins]

Cool, sounds good. Been trying to think of decent names for the pseudo, tho, and am coming up blank. ^_^

[hober]

Been trying to think of decent names for the pseudo, tho, and am coming up blank. ^_^

Yeah, same.

Would it help if I broke that one out into a separate issue?

[tabatkins]

Eh, sure. Might as well.

[AmeliaBR]

For starting the bikeshed debate on that separate issue (please copy over once there's somewhere to copy to):

• :adjustable-volume
• :not(:user-volume)
• :not(:volume-locked)
• :volume-unlocked
• Or maybe a set of :volume() variations, like :volume(muted), :volume(locked), :volume(max)…

[hober]

Okay, I moved the volume case over to its own issue, #3933. The three remaining cases in this issue should be really straightforward.

[css-meeting-bot]

The CSS Working Group just discussed additional resource state pseudo-classes for media elements, and agreed to the following:

• RESOLVED: Add :muted, :seeking, and :stalled pseudos.

The full IRC log of that discussion

Topic: additional resource state pseudo-classes for media elements
github: https://github.com//issues/3821
s/JS Foundation/Open JS Foundation
Ian Kilpatrick, Google
hober: we currently have playing and pause pseudo classes, which media elements match when they are playing or paused
... the use case is, things like custom media controls, with a unified play/pause button
... there are a handful of other common media element states that have a similar rationale for exposing to CSS
... stuff that people are currently using script for
... this issue is the 3 easy ones
... 1 is whether or not the element is muted
... you may have a mute button, styled volume slider
... very similar to playing/paused
... hope it's uncontroversial
... other 2 are a bit weird
... the HTMl spec has a concept of media being stalled
... and you can see examples of custom UI when media is stalled on popular sites like YouTube, netflix
... the spinner looks different
... if we could provide styling for that it would be nice
q+ to ask about "buffering" vs. "streaming connection broken" (have seen different UI)
... the 3rd one is: media elements have a seeking state, which is useful for cases like when you are displaying custom controls, but seeking is happening due to other controls
... maybe seeking with a remote control, but you want you custom control to do a different thing
FYI: https://html.spec.whatwg.org/multipage/media.html#htmlmediaelement
... so the HTML spec has the right hooks here
... just need something in CSS to expose them
... so 3 proposed pseudo classes: muted, stalled, seeking
florian: what is seeking as a state
hober: while you're seeking. if you using the scrubber
AmeliaBR: like an active state
q+ to talk about additional states
q+
ack dbaron
dbaron, you wanted to ask whether :muted would cover tab-level, app-level, or system-level muting (I suspect not, but want to ask)
dbaron: there's ofte na lot of ways to mute something
... my guess here this ignores your tab is muted, hardware control is muted, is that right?
q?
hober: I think that's right. but I'm not sure. I think this shouldb e tied to the host lang's definition
dbaron: ok so the HTML definition
ack tantek
tantek, you wanted to ask about "buffering" vs. "streaming connection broken" (have seen different UI)
ack tantek
tantek: I like the general direction of the proposal, +1 on them. even the less common features
... this shook loose memories of things I worked on right before Mozilla, doing HTML5 consulting, setting up video UIs
... took a bunch of notes which I forgot about that
... I needed this in 2010
... the :stalled pseudo class, I've seen different UI between buffering to show something, vs the network connection is gone
... even if you're in this "I want to play" state
... wondering if it's worth distinguishing
hober: I agree there's a use case there
+1 to tantek
... I think network state is a little more general. that's going to affect hte page, not just the media elements
tantek: but that's a differnt can of worms
hober: I'd rather tacklet that as a different thing
q?
tantek: I'm saying I'd rather not, since it is a can of worms
hober: could you propose another pseudo for this?
tantek: do you want one pseudo that means either of that? two for the specific states?
hober: I'd be happy to delegate this to HTML
... some HTML spec refactoring is needed anyway, for stalled
... from our perspective, we'd defer to the host language
do these apply to

[tantek]

Please also add a :buffering (or :waiting) pseudo-class distinct from :stalled, at the same time as adding :stalled.

Use-case: showing loading/buffering spinner, often with a %, e.g. on Netflix.

I’d like to see :buffering defined similar to :stalled https://html.spec.whatwg.org/multipage/media.html#event-media-stalled, however with the key difference that data is forthcoming. Similar to how the waiting event is defined: https://html.spec.whatwg.org/multipage/media.html#event-media-waiting

Alternatively I'd be ok with a :waiting pseudo-class that maps to the waiting event/definition (might be simpler for the platform / web-developers if we "just" do/keep a direct mapping of the pseudo-class to an existing HTML event name).

I do think it is important to add :buffering (or :waiting) at the same time as adding :stalled, in order to avoid having :stalled be errantly overloaded by implementers and/or web developers to handle the buffering use-case.

(Originally published at: https://tantek.com/2019/155/t2/)