This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 10419 - <video> should allow muted as a content attribute
Summary: <video> should allow muted as a content attribute
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: All All
: P3 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://dev.w3.org/html5/spec/video.ht...
Whiteboard:
Keywords: a11y, a11ytf, media, WGDecision
Depends on:
Blocks:
 
Reported: 2010-08-24 18:36 UTC by Adrian Bateman [MSFT]
Modified: 2011-04-13 08:33 UTC (History)
19 users (show)

See Also:


Attachments

Description Adrian Bateman [MSFT] 2010-08-24 18:36:44 UTC
muted should be allowed as a content attribute on a <video> element. It can be modified through script but should also be allowed declaratively the same as controls, autoplay, and loop.

Change: add muted to the list of content attributes for <video>

Scenario: we have feedback from developers who wish to include multiple videos on a page and mute all but one of them. Later script can be used to switch between which video should not be muted so that only one is heard at a time.
Comment 1 Ian 'Hixie' Hickson 2010-09-25 04:46:09 UTC
I don't think muted="" makes sense, since it would interact poorly with reflection. However, I could see an argument for adding something like defaultmuted="".

I've commented on this in the WHATWG list also:

   http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-September/028755.html

I'd like to wait a few days and see what feedback we collect there before adding this, since the WHATWG community has been discussing this particular topic.
Comment 2 Simon Pieters 2010-09-29 12:28:00 UTC
I think that .muted should always start off as false, and browser pref to mute audio (which would probably be a global pref or per tab/site/page, not per media element) should not be reflected in .muted but just always mute audio until the user changes the pref again. If the site can unmute then the pref would be useless anyway.

With that behavior, it makes perfect sense to have muted="" reflect .muted.
Comment 3 Adrian Bateman [MSFT] 2010-09-29 20:13:25 UTC
I agree with Simon. The page shouldn't be able to detect if the UA has provided a mechanism to mute all sound and this shouldn't affect the muted value of the element.
Comment 4 Philip Jägenstedt 2010-09-30 13:15:34 UTC
(In reply to comment #2)
> I think that .muted should always start off as false, and browser pref to mute
> audio (which would probably be a global pref or per tab/site/page, not per
> media element) should not be reflected in .muted but just always mute audio
> until the user changes the pref again. If the site can unmute then the pref
> would be useless anyway.
> 
> With that behavior, it makes perfect sense to have muted="" reflect .muted.

I agree, why didn't I think of this?
Comment 5 Ian 'Hixie' Hickson 2010-09-30 18:27:10 UTC
My concern isn't with a feature that mutes all sound, but with a feature whereby the browser recalls the muted state of specific videos or audio on specific pages. For example, I want media by default to not be muted (so that i can just go to someone's blog and watch their video of a cat jumping off a tree without having to worry about turning on audio), but I want audio on the pages of specific games that I visit often to be muted by default. I also definitely don't want to go to a site with six simultaneous videos and have to unmute each individually when the page provides a single unmute control that controls all six.

Maybe I'm misunderstanding how you want the browser to handle user preferences for muting though. Could you elaborate?
Comment 6 Simon Pieters 2010-10-01 08:16:23 UTC
Ah. Yeah I can see the case for remembering the mute setting (and volume setting) for media elements, same as remembering what the user has typed into forms on reload. Hmm. I'll have to think about this a bit more.
Comment 7 Simon Pieters 2010-10-06 09:45:48 UTC
Having thought about this, I agree with Hixie that having .muted reflected as a content attribute is a bad idea since we want to allow the browser to remember the mute setting but we don't want to make that mutate the DOM during parsing. However, I think calling the content attribute something else is also a bad idea, since muted="" is what most authors would intiutively try to use to mute the video with markup. Thus, I think we should follow the precedent set with <input value>, .value and .defaultValue, and introduce <video muted> which is reflected with .defaultMuted.
Comment 8 Ian 'Hixie' Hickson 2010-10-13 10:36:54 UTC
How about we add an audio="" attribute that controls the audio channel of the <video>?

It would take a space-separated list of tokens, with the following meanings:

* "off": disable the audio channel entirely, as if the video data had no audio track.

* "muted": if present when the media resource is loaded, set .muted to true, overriding user preferences.

* a floating point number from 0.0 to 1.0: if present when the media resource is loaded, set .volume to the given value, overriding user preferences. (Only one such value allowed; ignore all but the first.)

In the future we could add new values, too, like maybe "do-not-pitch-correct" which would disable the pitch correction when changing playbackRate. Also, maybe we don't need all the values above in the first version -- in particular, we might not need the volume control or "off" initially.

This gets around the various reflection problems, still allows all the various user preference models and "mute" UIs that people have proposed, and isn't a pain to type ("audio=muted" is pretty self-explanatory and doesn't feel verbose).
Comment 9 Philip Jägenstedt 2010-10-13 13:39:14 UTC
(In reply to comment #8)
> How about we add an audio="" attribute that controls the audio channel of the
> <video>?

And of <audio>, I presume? <audio audio=muted> is a bit weird, but volume and pitch control is not.

> It would take a space-separated list of tokens, with the following meanings:
> 
> * "off": disable the audio channel entirely, as if the video data had no audio
> track.
> 
> * "muted": if present when the media resource is loaded, set .muted to true,
> overriding user preferences.

Having both "off" and "muted" seems unnecessary, just "muted" would do.

> * a floating point number from 0.0 to 1.0: if present when the media resource
> is loaded, set .volume to the given value, overriding user preferences. (Only
> one such value allowed; ignore all but the first.)

It's slightly easier to use the last one, if you consider what the code that loops over the list of tokens looks like.

> In the future we could add new values, too, like maybe "do-not-pitch-correct"
> which would disable the pitch correction when changing playbackRate. Also,
> maybe we don't need all the values above in the first version -- in particular,
> we might not need the volume control or "off" initially.
> 
> This gets around the various reflection problems, still allows all the various
> user preference models and "mute" UIs that people have proposed, and isn't a
> pain to type ("audio=muted" is pretty self-explanatory and doesn't feel
> verbose).

It seems mostly OK to me, but are there other cases of multiple related keywords being space-separated and put in the same attribute?
Comment 10 Simon Pieters 2010-10-13 16:01:09 UTC
I think the audio="" suggestion makes the API look weird and inconsistent. :-)
Comment 11 Ian 'Hixie' Hickson 2010-10-15 18:46:40 UTC
> And of <audio>, I presume? <audio audio=muted> is a bit weird, but volume and
> pitch control is not.

For now I'll pass on the default volume control and won't add it to <audio>, but yeah, if this turns out to be a useful feature then we can extend it to volume and add it to <audio>.


> Having both "off" and "muted" seems unnecessary, just "muted" would do.

Ok, I'll skip "off" for now. I think it has some use cases (e.g. if you just want an animated background video and don't want the user to be able to enable the audio accidentally), but it can wait.


> It seems mostly OK to me, but are there other cases of multiple related
> keywords being space-separated and put in the same attribute?

Yeah, there's quite a few, e.g. rel="", class="", sandbox="", sizes="", itemprop="", accesskey=""...
Comment 12 Silvia Pfeiffer 2010-10-15 20:14:52 UTC
(In reply to comment #7)
> Having thought about this, I agree with Hixie that having .muted reflected as a
> content attribute is a bad idea since we want to allow the browser to remember
> the mute setting but we don't want to make that mutate the DOM during parsing.
> However, I think calling the content attribute something else is also a bad
> idea, since muted="" is what most authors would intiutively try to use to mute
> the video with markup. Thus, I think we should follow the precedent set with
> <input value>, .value and .defaultValue, and introduce <video muted> which is
> reflected with .defaultMuted.

Why not use .muted and .currentMutedState - seems more similar to .src and .currentSrc which is already a pattern for <video> and <audio>
Comment 13 Ian 'Hixie' Hickson 2010-10-15 21:28:44 UTC
.src isn't ever diametrically opposite to .currentSrc (it's either blank or equal), which wouldn't be the case with the muted state. Also, the reflected version of the content attribute is basically useless, so it would be unfortunate for it to have the better name.

The audio="" idea has the advantage of being a useful place to hook audio-related future features, and also doesn't require any backwards-incompatible changes to existing UAs, which may be an issue at this point given how fast people have jumped on the <video> bandwagon.


EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Partially Accepted
Change Description: see diff given below
Rationale: I've added a feature equivalent to the requested feature, though using a slightly different syntax, for the reasons discussed in this bug.
Comment 14 contributor 2010-10-15 21:29:44 UTC
Checked in as WHATWG revision r5636.
Check-in comment: Add <video audio=muted>.
http://html5.org/tools/web-apps-tracker?from=5635&to=5636
Comment 15 Karl Dubost 2010-10-16 11:22:44 UTC
This is a comment I had posted on html5quizz but still in moderation queue

Comment by karl at October 15th, 2010 at 4:25 pm 
Your comment is awaiting moderation. 

[cut]

It seems windows media player had a <param name="Mute" value="false"> . (*to check*)

Youtube has in its API
http://code.google.com/apis/youtube/js_api_reference.html

* player.mute():Void -- Mutes the player.
* player.isMuted():Boolean - Returns true if the player is muted, false if not.

DailyMotion API
http://www.dailymotion.com/en/doc/api/player/javascript_api

* player.mute():Void -- Mutes the audio playback.
* player.isMuted():Boolean - If audio playback is muted, returns true, false otherwise.

Vimeo Moogaloop video player doesn't seem to have anything for mute in the API.
http://vimeo.com/forums/topic:25102

mute="" seems to be aligned with YouTube and DailyMotion on another side, it might be confusing for people.
Comment 16 Philip Jägenstedt 2010-10-18 07:47:34 UTC
attribute boolean audio;

Surely the above is a mistake? It seems to me that it should be a DOMTokenList or a string.
Comment 17 Simon Pieters 2010-10-21 07:32:07 UTC
I'd like the editor to consider the comments here http://html5doctor.com/html5-simplequiz-3-how-to-mute-a-video/#comments

There are many different opinions, and one could draw different conclusions... I'll refrain from doing further analysis of the comments myself at this time.
Comment 18 Adrian Bateman [MSFT] 2010-10-21 16:55:59 UTC
Our preference is for the muted/defaultMuted proposal that Simon suggested. This is simpler to implement and use.
Comment 19 Ian 'Hixie' Hickson 2010-11-02 20:02:49 UTC
audio="" has the advantage of being more conveniently extensible in the future, but is slightly more complex to implement.

muted/.defaultMuted has the advantage of being simple, but the disadvantage of propagating sicking's pet peeve into new parts of the spec.

These seem like the only two serious contenders though.

I'll spec whatever you guys implement... so far we have Microsoft clearly stating a preference for muted/.defaultMuted; do any other browser vendors have any clear preferences?
Comment 20 Ian 'Hixie' Hickson 2010-11-03 08:30:08 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Did Not Understand Request
Change Description: no spec change
Rationale: See comment 19. I'm happy to change this to using muted/.defaultMuted instead of audio="" if other browser vendors agree that it's a better solution. In the meantime, I've left the spec using audio="" since that's the solution that IMHO fulfills the most constraints (including the "don't reflect with a different name" constraint that sicking has been a big proponent for).
Comment 21 Sam Ruby 2010-11-29 19:39:59 UTC
http://www.w3.org/html/wg/tracker/issues/146
Comment 22 Martin Kliehm 2010-12-21 16:16:59 UTC
The Accessibility Task Force bug-triage sub-team believes this should be TF priority since it's been escalated to a tracker issue, therefore adding the a11yTF keyword.
Comment 24 contributor 2011-04-12 20:24:29 UTC
Checked in as WHATWG revision r5991.
Check-in comment: Change <video audio=muted> to <video muted> (applies wg decision)
http://html5.org/tools/web-apps-tracker?from=5990&to=5991