- 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