[whatwg] Volume and Mute feedback on <video>
ian at hixie.ch
Fri Aug 20 12:57:56 PDT 2010
On Mon, 31 May 2010, Silvia Pfeiffer wrote:
> I just came across a curious situation in the spec: IIUC, it seems the
> @volume and @muted attributes are only IDL attributes and not content
> attributes. This means that an author who is creating an audio-visual
> media elements or mute them rather than just being able to specify this
> through content attributes.
What is the use case for overriding the user's defaults in this way?
I guess I could see a use case for muting (e.g. video ads often start
off muted), but declaring the default volume seems very strange.
> However, if I have multiple videos on a page, all on autoplay, it would
> all the new CSS3 functionality, I can, for example, build a spinning
> cube of video elements that are on autoplay or a marquee of videos on
> autoplay - all of which would require muting the videos to be bearable.
> If we added @muted to the content attributes, it would be easy to set
I guess that could make sense.
Would we want to make .muted simply reflect the content attribute, so
that the user enabling/disabling muting changes how the DOM is serialised?
Or would we go for another attribute, say mute="", as the default, and
have the IDL attribute be set by that attribute when loading, and then be
independent of it? The latter seems better I guess.
> As for the @volume attribute, I think it would be similarly useful if an
> author could control the loudness at which a video or audio file starts
> playing back, in particular if he/she knows it is actually a fairly
> loud/quiet file.
Given that the default is 1.0 (the loudest setting), it would only really
let authors make things quieter. It's not clear that there are that many
use cases for that.
On Mon, 31 May 2010, bjartur wrote:
> If you need the audio to be muted you should use CSS. If you need to
> control volume dynamically you need scripting.
I don't know that I'd agree with that really. It's not purely
presentational -- the concept applies regardless of how the video is
presented, so long as it has an audio component.
(Note that CSS3 Speech doesn't apply here, since that's specifically for
audio browsers, not for screen browsers that happen to play audio.)
On Tue, 1 Jun 2010, Alex Bishop wrote:
> A less esoteric use case is videos in advertisements, which often begin
> to play as soon as the ad loads but remain silent until the user
> explicitly chooses to enable sound (the theory being that the motion of
> the video will pique the user's interest and compel them to switch on
> the audio).
> If there were a muted content attribute, such a video could be inserted
> into an ad using code as simple as this:
> <video src="buystuff" autoplay loop muted></video>
> (In most cases, script would probably be used to allow the user to
> enable sound but it's possible that the ad might rely on the
> user-agent's own controls for this.)
You'd have to include the controls="" attribute for that, but yes, indeed.
On Wed, 9 Jun 2010, Kevin Marks wrote:
> Setting volume above 1.0 can be very useful if the original is too
> quiet. For example, Quicktime allows a volume of 300% to amplify quiet
On Thu, 10 Jun 2010, Silvia Pfeiffer wrote:
> I don't think that is possible in the way that the volume attribute is
> currently defined as a value between [0;1]. That is an orthogonal, but
> still important question about the volume attribute then.
On Thu, 10 Jun 2010, Ashley Sheridan wrote:
> Or you could just raise the volume of the audio track itself. I think
> being able to raise the volume like this (beyond 100% of what it is)
> with script just makes it something more likely to be abused (think how
> the TV adverts always seem twice as loud as the programs they surround)
> and so will end up getting blocked more often.
On Thu, 10 Jun 2010, Silvia Pfeiffer wrote:
> That requires editing the resource. Think about it from a process
> point-of-view: you're a Web developer and have been given a set of media
> resources to put on a Website. As you put it all together, you notice that
> the volume of the different files is different and thus playing them back
> next to each other will create a very confusing user experience. Do you
> really want to shoot the files back to the production to adjust the volume
> settings so they are all similar? If you're under time pressure, you'd
> probably much prefer just setting a volume attribute on each so they all
> play back with the same level.
What if you notice that each file uses different fonts for titles, or each
video is colour-corrected differently, or uses a different lens, or has a
different aspect ratio, or four are filmed during the day and one during
the night and the latter one really stands out in a bad way? I don't think
we should assume that just because we can do post-processing in the
client, it's the right thing to do. :-)
On Wed, 9 Jun 2010, Hay (Husky) wrote:
> element. One of the things that really seem to be lacking from the
> specification (and hence, browsers too) is a distinct 'muted' event that
> occurs whenever you set the muted property to 'true' or 'false'. Of
> course, the 'volumechange' event occurs, but that also happens whenever
> you set the volume so you have to check every time the event occurs if
> it originated from a change on the volume or muted property. Because
> these two capabilities of the <video> element have different properties,
> it seems to make sense to let them trigger different events too (or have
> the muted property trigger 'volumechange' as well).
Yeah, this is a trade-off. We wanted to have one event that fired for
both, because otherwise it's easy to make UI that fails to take into
account that there are two things going on. But we also didn't want to
fire multiple events per change, because that makes it really easy to end
up in a situation where by the time you receive the event, the current
situation has changed (since the events get queued). I'm not sure what the
best situation is. I intend to look at how people use onvolumechange over
the next year or so and see how much trouble this is causing.
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg