<video /> attribute needed but not guaranteed by React

[elrumordelaluz]

As @gaearon mentioned, React does not guarantee an attribute will be set, so probably this is not a bug.

If I understand well, react will ensure the property is set anyway.

Current behaviour
React renders the html <video /> element without the attribute muted when explicitly passed.

Demo time
In this pen I made a simple example setting muted to the element and obtaining the result below:

Actually the property is set well, since the original medial file has an audio track and in the pen result is muted.

The point
I think is most a specific need than the expected behaviour.
From the functionality POV, it is absolutely ok, my Component renders a <video /> muted as requested and so on.

But there are browsers and policies, more specifically related to this issue, Webkit and the New updated one year ago, with some interesting changes for the <video /> element.
The part interested is

<video muted> elements will also be allowed to autoplay without a user gesture.

So, the specific need is to have the explicit attribute to tell the browser that this video could be autoPlayed.

There's a similar issue

[syranide]

The muted property is live just like value for inputs and reflects the current value. But the muted attribute reflects the initial state of the component.

So I think the current behavior is wrong, because <video muted /> should force it to always be muted then, just like <input value="foo" /> forces it to always be "foo". So one way to resolve this is to start from scratch; introduce defaultMuted property which maps to the attribute only. Then there should be a muted property which is controlled (just like input value) and there needs to be a callback to go with that e.g. onMutedChange. However! Mute is just equal to volume being zero, so the DOM only exposes the volumechange event.

So perhaps a more DOM-truthful and minimal implementation would be to have muted be the attribute and reflect only the initial mute state.

Then React can take it further and also support a special-property volume and its corresponding event onVolumeChange. But this is a slippery slope and there are tons of such properties that should be added then (and increasingly mixing both behaviors in React is a much larger discussion). Elsewhere we recommend that people simply manually set properties via JS to control elements and I think the same general recommendation works best here too, manually set the properties and expose your fancy video player as a React component if you want to reuse it.

tl;dr IMHO yes, muted should set the attribute only, so that it only sets the initial state of the element.

[montogeek]

I am facing the same issue with Android 4.4, according to new (from a year ago), muted attribute needs to be present.

[syranide]

@gaearon This should be an easy fix if you're OK with the direction (making muted set the attribute instead), although there is potential to break some existing code if someone decided to implement their own mute button and rely on this prop.

[aweary]

Since defaultMuted is already a spec-defined property reflecting the muted attribute, it would make sense to let users utilize this API. The React API is already property-focused, so it's not a big leap. This would be the least complex change, and shouldn't be breaking.

[kiurchv]

@aweary Any progress on this?

[NicolasPoirierB]

@aweary Same question here, we need the muted attribute to be passed to the video tag to allow autoplaying on mobile devices. Has there been any progress in this direction?

Thank you!

[jquense]

folks progress on an Issue is generally visible and takes the form of a PR. If you don't see a linked PR or updates on an issue assume there is no more progress.

It's unclear what the path forward is for this to me. We don't really have way of saying "sync the attribute once and then use the property" and I don't know that adding said logic is even a good idea...

[syranide]

It's unclear what the path forward is for this to me. We don't really have way of saying "sync the attribute once and then use the property" and I don't know that adding said logic is even a good idea...

@jquense I think I understand your point, but inputs have both value and defaultValue. This is exactly the same thing, there should probably be a defaultMuted and muted. It's a "live" value and needs to be special-cased in the same way, that or otherwise just have muted prop which sets the attribute but that means users need to manually access the muted property if they want to control it precisely (just like you can with defaultValue for inputs), which is also fine.

Personally, just having muted set the attribute and leaving everything else up to the user is perfectly fine (and IMHO how input should have been implemented too).

[aweary]

I'm hesitant to change muted to act like value; we want to get away from that special-cased behavior, since it's caused a number of problems. Of course, muted would likely be much less problematic since it's just a boolean value.

We don't really have way of saying "sync the attribute once and then use the property" and I don't know that adding said logic is even a good idea...

defaultMuted is the spec'd solution for this. It sets the initial muted value by reflecting the muted attribute, which can then be controlled using the muted property.

We don't support many attributes that aren't actually DOM attributes, but we do have defaultValue so I think there's a good argument for mirroring that API here.

[jquense]

we want to get away from that special-cased behavior, since it's caused a number of problems.

yeah the controlling behavior ends up causing so many headaches i wouldn't want to do it again, though i agree that it's the right behavior generally.

We don't support many attributes that aren't actually DOM attributes, but we do have defaultValue so I think there's a good argument for mirroring that API here.

I like that idea, tho It's always a slippery slope, what would the SSR behavior if someone specifies defaultMuted but no muted, ? I suppose we already handle this with value and checked...

[aweary]

I like that idea, tho It's always a slippery slope, what would the SSR behavior if someone specifies defaultMuted but no muted, ? I suppose we already handle this with value and checked...

Yeah, I imagine it would behavior just like defaultValue does for SSR, by rendering the value attribute with the provided value.