The HTML5 spec says the following about the element's effective media volume:

"An element's effective media volume is determined as follows:

[...]

The element's effective media volume is volume, interpreted relative to the range 0.0 to 1.0, with 0.0 being silent, and 1.0 being the loudest setting, values in between increasing in loudness. The range need not be linear. The loudest setting may be lower than the system's loudest possible setting; for example the user could have set a maximum volume."

I think that the text needs to be clarified to rule out what I think is the deliberate misinterpretation currently done in Webkit-GTK on Linux, especially when the system runs PulseAudio in its default configuration with flat volumes. In fact, Xabier Rodríguez Calvar (a WebKit-GTK developer) has explicitly asked me to raise the issue with W3C during LinuxCon Europe 2013.

The misinterpretation done by WebKit-GTK + PulseAudio is that the volume is interpreted as relative to the sound card's maximum hardware volume. I.e., if the web page requests 100%, the master volume control of the system mixer will be bumped, resulting in a sound much louder than intended - potentially up to hardware or hearing damage. I think that it is a security issue to allow this behaviour, and thus want the wording to be changed in the standard.

Another reason to change the wording is this annoyance-class bug: if a browser implements the volume through any means that correspond to a slider in the system mixer, any application that sets the volume using a timer will result in that slider disobeying the user. This is indeed the case with Epiphany, Midori or any other browser based on WebKit-GTK under Linux with PulseAudio. It would be nice to disallow implementations that implement this annoyance.

In fact, all other browsers that I have tested (IE, Firefox, Chrome/Chromium, Opera) implement the volume as relative to the one set by the user in the system mixer, and I think that this behaviour is what was intended. There are web pages in the wild relying on this (e.g. by setting volume to 1.0 explicitly and assuming that it is just the safe default), e.g. http://www.mikanse.com/FunWithDynamite/fun-with-dynamite.html (search for "this.volume=1" in http://www.mikanse.com/FunWithDynamite/funwithdynamite.js)

Here are some relevant links:

https://bugzilla.gnome.org/show_bug.cgi?id=675217 (initial bug report)
http://jsfiddle.net/bteam/FbkGD/ (security-relevant reproducer - just repeatedly changes the volume to 99% or 100% using a timer)
The end of https://bugs.webkit.org/show_bug.cgi?id=118974 (the root cause)
http://www.openwall.com/lists/oss-security/2013/10/22/6 (attempted CVE request, not answered yet)

Here is the wanted clarification:

"The element's effective media volume is volume, interpreted relative to the range 0.0 to 1.0, with 0.0 being silent, and 1.0 being the loudest setting, values in between increasing in loudness. The range need not be linear. The loudest setting must be equal to or lower than the volume set for the browser in the system's mixer application, if the system has one. There may be other methods for the user to set the inviolable maximum volume, and there must be at least one such method. Volume changes done through the DOM or through the browser UI must not result in any changes to the user-controllable elements of the system mixer."

As I said, all major browsers already comply with the new requirements: the inviolable maximum volume is set in the system mixer, and javascript doesn't have access to it.

Of course, you are welcome to suggest a better wording that covers the issue. There may be other ways to produce audio from HTML5, they may need a similar clarification (requirement of a system-mixer-relative volume model) too.