- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 04 Jun 2019 14:13:54 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `“effective media volume is mutable” pseudo-class for media elements`, and agreed to the following:
* `RESOLVED: Add :volume-locked.`
<details><summary>The full IRC log of that discussion</summary>
<heycam> Topic: “effective media volume is mutable” pseudo-class for media elements<br>
<heycam> https://github.com/w3c/csswg-drafts/issues/3933<br>
<heycam> hober: this one is similar to the other cases. it's a bit weird though<br>
<heycam> ... in the HTMl spec, media elements have a volume. which you can set from JS<br>
<heycam> ... can also be set by native controls<br>
<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<br>
<heycam> ... at least one case where this matters, on iOS, there is no software controlled volume<br>
<heycam> ... it can'tb e chnaged from script. you can change it on the element, but that clause applies<br>
<AmeliaBR> q+ to ask about fingerprinting potential<br>
<heycam> ... so we short circuit at step 1 of that algorithm<br>
<heycam> ... this is a feature that users like. they have control of volume, pages can't screw with that<br>
<heycam> ... I think there's another impl that does this? can't remember<br>
<heycam> ... people are doing UA sniffing to hide the volume button in media controls on iOS<br>
<astearns> github: https://github.com/w3c/csswg-drafts/issues/3933<br>
<heycam> ... I'd rather then be able to know that the effective volume won't be affected by the JS prop<br>
<heycam> ... the other difference is I don't know what to name this<br>
<TabAtkins> q+<br>
<florian> q+<br>
<heycam> ... the HTML spec doesn't have a name for it<br>
<jensimmons> `volume-effectiveness`?<br>
<dbaron> :can-control-volume ?<br>
<heycam> AmeliaBR: before the name, I want to confirm this is uncontroversial. not exposing new information?<br>
<RRSAgent> logging to https://www.w3.org/2019/06/04-css-irc<br>
<heycam> ... currently, if you set the volume from script, and it doesn't work, you can tell?<br>
<heycam> hober: yes<br>
<fremy> @hober: `:user-locked-volume` ?<br>
<heycam> AmeliaBR: if I mute the whole laptop, is that included in this?<br>
<heycam> hober: I don't know if system muted state on desktop OS affects that<br>
<heycam> ... if it did, I would expect it to affect this<br>
<chris> rrsagent, here<br>
<RRSAgent> See https://www.w3.org/2019/06/04-css-irc#T14-04-21<br>
<heycam> AmeliaBR: either way there's a clear defn in HTML? and it's already exposed to script?<br>
<heycam> hober: yes<br>
<heycam> hober: AmeliaBR proposed :adjustable-volume. so it's the opposite of that<br>
<jensimmons> q+<br>
<heycam> TabAtkins: :volume-locked<br>
<heycam> ... expresses the semantic that you'd style on, doesn't need :not()<br>
<heycam> ... but given other suggestion for a volume pseudo, you could merge this into a pseudo that takes a keyword<br>
<TabAtkins> https://www.irccloud.com/pastebin/rPsIGCzk/<br>
<heycam> hober: on Windows, muted and volume are independent states<br>
<heycam> :volume( locked || muted || <volume-value> )<br>
<heycam> <volume-value> = [ '<' | '>' ] '='? [ <number [0,1]> | <percentage [0%,100%]> ]<br>
<fremy> +1 on TabAtkins's proposal<br>
<astearns> ack florian<br>
<heycam> florian: I don't think this varies per element. maybe a MQ is better?<br>
<heycam> hober: I think the use case is tied to media controls<br>
<heycam> florian: but you can't have one media element which is locked and one is not?<br>
<Rossen_> q+ fremy<br>
<heycam> hober: I think it makes sense to be symmetric with the other pseudos<br>
<heycam> ... but I concede the point it's a system wide thing<br>
<fremy> q-<br>
<Rossen_> ack jensimmons<br>
<heycam> jensimmons: a few quick examples in the thread<br>
<TabAtkins> :volume(locked < 50%), for example<br>
<dbaron> s/a few/request a few/<br>
<heycam> hober: of Tab's syntax, or when you would use this?<br>
<TabAtkins> :volume(muted)<br>
<heycam> jensimmons: when you'd use it<br>
<florian> q+<br>
<hober> div.controls:volume(locked) .volume { display: none; }<br>
<heycam> TabAtkins: for :volume(locked), you'd display:none your custom volume button<br>
<heycam> AmeliaBR: should the pseudo refer to the fact that the volume control works or wouldn't work<br>
<heycam> hober: my case is for the latter<br>
<TabAtkins> `video:volume(locked) + .controls > .volume { display: none; }`<br>
<heycam> ... shouldn't display if it's going to be futile<br>
<Rossen_> q?<br>
<heycam> fremy: if you set vol to 0, that stil lmutes the video?<br>
<heycam> hober: depends on the platform<br>
<heycam> ... not on Windows. unmuted at volumnet 0<br>
<heycam> hober: on iOS you can mute audio tracks on media elements<br>
<heycam> fremy: using volume 0?<br>
<heycam> hober: using .muted<br>
<heycam> chris: when you unmute you want to go back to the old volume<br>
<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<br>
<heycam> hober: it's often a sibling<br>
<Rossen_> ack florian<br>
<heycam> hober: that's the same as the existing :play / :paused pseudos<br>
<heycam> hober: I really like Tab's locked suggestion. either as the one off or the general proposal<br>
<heycam> ... since we resolved on :muted. I'm happy to resolve on :volume-locked, and discuss merging later<br>
<heycam> AmeliaBR: for the parenthesized idea, volume(max/min) might also be useful<br>
<heycam> TabAtkins: are min/max different from 0% / 100%?<br>
<heycam> AmeliaBR: do we want to expose %s in a selector?<br>
<heycam> emilio: we don't have any other pseudos with numeric values inside them<br>
<heycam> hober: I think it's a good argument for going with the one off for now<br>
<heycam> RESOLVED: Add :volume-locked.<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3933#issuecomment-498689912 using your GitHub account
Received on Tuesday, 4 June 2019 14:13:56 UTC