#Html5 audio mute unmute code#
#Html5 audio mute unmute tv#

I really like Bryan Wood’s proposal, but I would suggest some changes: Why should we try to redefine a functionality that has been around for decades already? Let us experience Mute in HTML5 as we do in all aspects of our lives that provide us the ability to Mute. The way we use and experience “Mute”ing the volume of something on any device we have that provides this functionality, is designing the experience of the user. VPlayer.mute(false) //this unmutes the volume and returns the volume back to the previous level VPlayer.volume //the current volume setting This should be a get ONLY method for this setting If we allow this to be set then we allow developers to misbehave VPlayer.previousVolume //this is the property set by mute VPlayer.mute(true) //this is a method specific to video player elements Var vPlayer = document.getElementById('video1') If no mute value is assumed and no volume value is provided then the default expectation would be to have the default volume be set, the previousvolume set to the default volume value and the mute state to be false. if mute= false then the default volume value would be used. When the DOM is built the previousVolume would be set to 5 if mute=true. Mute=false would be the default experience from this attribute. The mute attribute will allow the volume to be muted initially and providing a volume value would set the default for when it is unmuted. Mute=true would provide the developer to set a default volume for the player to play at when the user plays it. But it also remembers where it was so that when unmuting it returns to that previous volume level.Īs I see it, HTML5 should handle muting just like my other video players. Some systems allow it to directly interface with the OS settings. But what does that mute button really do? It is setting the volume to 0. True most video players have a volume control and a control that handles the mute process. This is the same behavior my OS exhibits when I open up my sound controller and perform the same action.īut video players have both right now, don’t they?

#Html5 audio mute unmute tv#

When I un-mute my TV my volume returns to where it originally was. When I mute my TV the volume reflected to me is 0. Mute is an automatic Volume=”0″ and remembers where it came from. Vimeo Moogaloop video player doesn't seem to have anything for mute in the API.Ī parameter which is mute='' seems to be aligned with YouTube and DailyMotion * player.isMuted():Boolean - If audio playback is muted, returns true, false otherwise. * player.mute():Void - Mutes the audio playback. * player.isMuted():Boolean - Returns true if the player is muted, false if not. The person comes back later on the same page and the state is the second video is unmuted and 1 and 3 muted? Then the person mutes it and unmutes the second video.Ĥ. The person arrives on the page the first video is not muted.Ģ. One would have an attribute muted='false' and the two others muted='true' ?ġ. Are you saying that the page contains a list of videos, let say: three videos. What do you think? Which is the best option? Is there another option that is better than any of the above?īruce, I do not understand exactly the use case. On the other hand it is consistent with and. muted, but it might be confusing for some people. defaultMuted and let the user setting change. We could have muted='' which is reflected by. muted, but defaultmuted='' is a bit long and ugly in markup.

defaultMuted, and just let the user setting change. We could introduce defaultmuted='' which is reflected by. you would get muted='' to appear in the DOM if the video is muted by the user even though there was no such attribute in the markup, which could confuse your scripts or style sheets if it’s not what you expected to happen. if one changes, so does the other), but this would cause the DOM to mutate during parsing if the remembered setting doesn’t match the markup, i.e. We could introduce muted='' which is reflected by.

#Html5 audio mute unmute code#

(Note that code fragments below aren’t real code, just suggestions.) This is where it starts to get hairy if we introduce a content attribute for muting. It would make sense for the browser to remember the mute setting for individual video elements on page reload (or later visit), so that the user doesn’t have to re-mute them. muted IDL attribute reflects the user setting of muted for the video element - if the user clicks “mute” in the native video controls, then the value of. muted = true with script, but it would be more convenient to be able to mute with markup.