[whatwg] audio and video: volume and muted as content attributes?

Philip Jägenstedt philipj at opera.com
Mon May 31 23:30:22 PDT 2010

On Tue, 01 Jun 2010 14:17:03 +0800, Silvia Pfeiffer  
<silviapfeiffer1 at gmail.com> wrote:

> On Tue, Jun 1, 2010 at 3:53 PM, Philip Jägenstedt <philipj at opera.com>  
> wrote:
>> On Mon, 31 May 2010 19:33:45 +0800, Silvia Pfeiffer
>> <silviapfeiffer1 at gmail.com> wrote:
>>> Hi,
>>> 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.
>>> I've searched the archives and didn't find a discussion or reasons for
>>> this. Apologies if this has been discussed before.
>>> I am guessing the reasons for not having them as content attributes is
>>> that anything that requires muting of audio-visual content is assumed
>>> to need JavaScript anyway.
>>> 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.
>>> 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.
>>> I'm curious about other people's opinions.
>>> Cheers,
>>> Silvia.
>> I think both volume and muted could have some use as content  
>> attributes, so
>> the question is only if the additional complexity for implementations  
>> and
>> authors. muted is a boolean attribute and would be trivial to support.
>> volume, however, is a float and last I checked Opera doesn't reflect  
>> [1] any
>> other float properties. I wouldn't be surprised if it would be a first  
>> for
>> some other browsers too. Reflecting floats is a little bit annoying (I  
>> tried
>> when the spec had an aspect attribute for video) because of having to  
>> decide
>> an arbitrary precision to which to round. That absence of volume should
>> imply 1.0 (and not 0.0 or NaN) could also be a little bit of a nuisance.
> It might be easier if the content attribute for volume was specified
> as a percentage value between 0 and 100. Then it would be an integer
> only. I'm not sure if this is possible, but it seems we have more
> content attributes with these kinds of vlaues (e.g. width/height).

This would make volume even more special, as a float that reflects as an  
integer percentage. Just using the existing definition for reflecting a  
float would be simpler.

>> So, I am neither in favor or against of reflecting volume and mute as
>> content attributes. Implementation is quite simple, but doesn't come for
>> free unless browsers are already reflecting other float properties.
> Mute alone would already be really helpful. I wasn't aware that volume
> created such a problem.

I'd be fine with reflecting muted if many people think it would be useful.  
I'm not the one to make that judgment though.

Volume isn't a huge problem, just not as trivial as one might suspect.  
Another thing to consider is that it is currently impossible to set volume  
to a value outside the range [0,1] via the DOM API. With a content  
attribute, volume="-1" and volume="1.1" would need to be handled too. I'd  
prefer it being ignored rather than being clamped.

>> [1]
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#reflect
> Cheers,
> Silvia.

Philip Jägenstedt
Core Developer
Opera Software

More information about the whatwg mailing list