[whatwg] Volume and Mute feedback on <video>

[Eric Carlson]

On Aug 20, 2010, at 1:21 PM, Jonas Sicking wrote:

> On Fri, Aug 20, 2010 at 12:57 PM, Ian Hickson <ian at hixie.ch> wrote:
>> 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
>>> Webpage has to use JavaScript to turn down (or up) the loudness of their
>>> 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.
> 
> It doesn't seem to be overriding the users default any more than if
> the video or audio track had been recorder with a different volume?
> 
  Agreed. Additionally the element's setting is always modified by the browser setting (if there is one) and the system setting before it gets to the speakers, so an attribute can't override the user's default.


> One use case is simply wanting to have some background music on a
> page, but not wanting it to play in a volume as loud as what the track
> was originally recorded in.
> 
  This is a valid use case. While some container formats can have an audio volume multiplier, it sets the file's maximum volume and I think we want an attribute that sets the initial volume, allowing the user to turn it up if they wish.


>>> However, if I have multiple videos on a page, all on autoplay, it would
>>> be nice to turn off the sound of all of them without JavaScript. With
>>> 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
>>> the muted state without having to write any JavaScript.
>> 
>> 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.
> 
> Having the IDL attribute not reflect the content attribute I think
> will be a source of confusion. The HTML DOM got this very wrong for
> form values, and IE got it right. There were a great many people
> confused about this for forms while gecko was still ramping up market
> share back a few years ago. I think it would be much simpler to have
> it behave like attributes like @disabed.
> 
  I agree with this as well - the IDL attribute should reflect the content attribute.

eric