[selectors-4] "effective media volume is mutable" pseudo-class for media elements #3933
Labels
HTML
Requires coordination with HTML people
Needs Feedback/Review
Needs Naming (Request to Bikeshed)
Needs Thought
selectors-4
Current Work
Comments
|
For context, see the discussion on #3821 starting with @tabatkins' comment. |
hober
added
HTML
|
Copying over the initial suggestions from the other issue: For starting the bikeshed debate on that separate issue (please copy over once there's somewhere to copy to):
|
|
@hober just dropped ( in IRC at the CSSWG) possible code syntax for a usecase: |
|
The CSS Working Group just discussed
The full IRC log of that discussion<heycam> Topic: “effective media volume is mutable” pseudo-class for media elements<heycam> https://github.com//issues/3933 <heycam> hober: this one is similar to the other cases. it's a bit weird though <heycam> ... in the HTMl spec, media elements have a volume. which you can set from JS <heycam> ... can also be set by native controls <heycam> ... if you look at the algorithm for determining what the effective volume is, there is a clause that is a short circuit that allows for platform conventions to be followed <heycam> ... at least one case where this matters, on iOS, there is no software controlled volume <heycam> ... it can'tb e chnaged from script. you can change it on the element, but that clause applies <AmeliaBR> q+ to ask about fingerprinting potential <heycam> ... so we short circuit at step 1 of that algorithm <heycam> ... this is a feature that users like. they have control of volume, pages can't screw with that <heycam> ... I think there's another impl that does this? can't remember <heycam> ... people are doing UA sniffing to hide the volume button in media controls on iOS <astearns> github: https://github.com//issues/3933 <heycam> ... I'd rather then be able to know that the effective volume won't be affected by the JS prop <heycam> ... the other difference is I don't know what to name this <TabAtkins> q+ <florian> q+ <heycam> ... the HTML spec doesn't have a name for it <jensimmons> `volume-effectiveness`? <dbaron> :can-control-volume ? <heycam> AmeliaBR: before the name, I want to confirm this is uncontroversial. not exposing new information? <RRSAgent> logging to https://www.w3.org/2019/06/04-css-irc <heycam> ... currently, if you set the volume from script, and it doesn't work, you can tell? <heycam> hober: yes <fremy> @hober: `:user-locked-volume` ? <heycam> AmeliaBR: if I mute the whole laptop, is that included in this? <heycam> hober: I don't know if system muted state on desktop OS affects that <heycam> ... if it did, I would expect it to affect this <chris> rrsagent, here <RRSAgent> See https://www.w3.org/2019/06/04-css-irc#T14-04-21 <heycam> AmeliaBR: either way there's a clear defn in HTML? and it's already exposed to script? <heycam> hober: yes <heycam> hober: AmeliaBR proposed :adjustable-volume. so it's the opposite of that <jensimmons> q+ <heycam> TabAtkins: :volume-locked <heycam> ... expresses the semantic that you'd style on, doesn't need :not() <heycam> ... but given other suggestion for a volume pseudo, you could merge this into a pseudo that takes a keyword <TabAtkins> https://www.irccloud.com/pastebin/rPsIGCzk/ <heycam> hober: on Windows, muted and volume are independent states <heycam> :volume( locked || muted || <volume-value> ) <heycam> <volume-value> = [ '<' | '>' ] '='? [ <number [0,1]> | <percentage [0%,100%]> ] <fremy> +1 on TabAtkins's proposal <astearns> ack florian <heycam> florian: I don't think this varies per element. maybe a MQ is better? <heycam> hober: I think the use case is tied to media controls <heycam> florian: but you can't have one media element which is locked and one is not? <Rossen_> q+ fremy <heycam> hober: I think it makes sense to be symmetric with the other pseudos <heycam> ... but I concede the point it's a system wide thing <fremy> q- <Rossen_> ack jensimmons <heycam> jensimmons: a few quick examples in the thread <TabAtkins> :volume(locked < 50%), for example <dbaron> s/a few/request a few/ <heycam> hober: of Tab's syntax, or when you would use this? <TabAtkins> :volume(muted) <heycam> jensimmons: when you'd use it <florian> q+ <hober> div.controls:volume(locked) .volume { display: none; } <heycam> TabAtkins: for :volume(locked), you'd display:none your custom volume button <heycam> AmeliaBR: should the pseudo refer to the fact that the volume control works or wouldn't work <heycam> hober: my case is for the latter <TabAtkins> `video:volume(locked) + .controls > .volume { display: none; }` <heycam> ... shouldn't display if it's going to be futile <Rossen_> q? <heycam> fremy: if you set vol to 0, that stil lmutes the video? <heycam> hober: depends on the platform <heycam> ... not on Windows. unmuted at volumnet 0 <heycam> hober: on iOS you can mute audio tracks on media elements <heycam> fremy: using volume 0? <heycam> hober: using .muted <heycam> chris: when you unmute you want to go back to the old volume <heycam> florian: for this one and the prev one, wondering if this is practical as a pseudo, given the controls aren't usually a descendant <heycam> hober: it's often a sibling <Rossen_> ack florian <heycam> hober: that's the same as the existing :play / :paused pseudos <heycam> hober: I really like Tab's locked suggestion. either as the one off or the general proposal <heycam> ... since we resolved on :muted. I'm happy to resolve on :volume-locked, and discuss merging later <heycam> AmeliaBR: for the parenthesized idea, volume(max/min) might also be useful <heycam> TabAtkins: are min/max different from 0% / 100%? <heycam> AmeliaBR: do we want to expose %s in a selector? <heycam> emilio: we don't have any other pseudos with numeric values inside them <heycam> hober: I think it's a good argument for going with the one off for now <heycam> RESOLVED: Add :volume-locked. |
|
Extracting from minutes: If we resolve on adding a volume-level pseudo (#4001), then we should revisit the naming of this and merge "muted", "locked", and "volume-level" all into one pseudo, presumably with the syntax: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
and others
Split out from #3821.
In §11 Resource State Pseudos we currently have the
:playingand:pausedpseudo-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. In addition to the cases covered in #3821, a bunch of us (@beccahughes @mounirlamouri @padenot @jyavenard @eric-carlson @jernoble et al.) would like to mint a new pseudo-class to expose whether or not setting the volume IDL attribute would result in the element's effective media volume actually changing.With such a pseudo-class, it would be be possible (without script) to show or hide custom volume controls based on whether or not using such a control would actually result in a user-audible change.
I have no specific proposal for a name. Bikeshedding very welcome. @AmeliaBR has several suggestions.
The text was updated successfully, but these errors were encountered: