<video /> attribute needed but not guaranteed by React
As @gaearon [mentioned](https://twitter.com/dan_abramov/status/893511715463340033), 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](https://codepen.io/elrumordelaluz/pen/ba4b5294cec7ea455c66e9b9d0a6c889?editors=0010) 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](http://clips.vorwaerts-gmbh.de/VfE_html5.mp4) 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 <video> Policies for iOS](https://webkit.org/blog/6784/new-video-policies-for-ios/) 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 th
Posted by elrumordelaluz on Aug 4, 2017, 8:50 PM
Tags
Related issues
- struct's lifetime requirements can be bypassed via covariant field assignment
- Proposal to Reorganize the Moderation Team and Review Moderation Policies
- Progressive FPS degradation appears to be related to dota2.com — blocking the domain prevents the performance loss
- proposal: container/...: generic collection types
- Better Custom Endpoint BYOK
- A concrete policy for backward compatibility until Godot 5.0
Raise real-world problems, find people facing the same issue, and discuss solutions.4,500 issues0 comments
github (Other)
struct's lifetime requirements can be bypassed via covariant field assignment
Proposal to Reorganize the Moderation Team and Review Moderation Policies
Progressive FPS degradation appears to be related to dota2.com — blocking the domain prevents the performance loss
proposal: container/...: generic collection types
Better Custom Endpoint BYOK
A concrete policy for backward compatibility until Godot 5.0
New MTP models not supported
Tracking: 429 / Capacity Issues
<video /> attribute needed but not guaranteed by React
As @gaearon [mentioned](https://twitter.com/dan_abramov/status/893511715463340033), 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](https://codepen.io/elrumordelaluz/pen/ba4b5294cec7ea455c66e9b9d0a6c889?editors=0010) 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](http://clips.vorwaerts-gmbh.de/VfE_html5.mp4) 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 <video> Policies for iOS](https://webkit.org/blog/6784/new-video-policies-for-ios/) 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 th
Comments (0)
No comments yet. Start the discussion.