elements
elements copied to clipboard
Feature Request: Add src attribute fallback for no-js rendering
Is there an existing issue for this?
- [X] I have searched the existing issues
Which Mux Elements/Packages does this apply to? Select all that apply
mux-audio-react
Description
The MuxAudioReact component (and probably others) relies on client side javascript for the src
attribute to be set. A safe fallback to the outerSrc
prop could mean users can still play media in the native <audio>
element on devices without javascript , and i assume speed up the network waterfall too.
https://github.com/muxinc/elements/blob/main/packages/mux-audio-react/src/index.tsx
Untested, but its probably something along the lines of changing this:
<audio ref={mediaElRef as typeof innerMediaElRef} {...restProps}>
{children}
</audio>
to something like this:
<audio ref={mediaElRef as typeof innerMediaElRef} src={src ?? outerSrc} {...restProps}>
{children}
</audio>
Expected Behavior
Rendered <audio>
element should include the src
property so users can play audio file without javascript.
@samburgers just checking - are you anticipating using a src that would be natively supported for playback via an <audio>
element? HLS/HTTP Adaptive Streaming ("HAS") is not supported by most browsers (except a few e.g. Safari for HLS) for native playback. Since our primary use case for mux elements is playback of media provided by Mux Video, which is HLS, we've primarily built them in a way that assumes or at least prioritizes this in our architecture.
@cjpillsbury thanks for reply. yep, for the sake of progressive enhancement i need to find a player that will fallback to a working native audio elements rendered on the server when javascript is not supported (ie with Nextjs). Mux appears to almost do this, but doesn't pass through the src
attribute and what you are left with is this on the page:
<audio controls></audio>
Regarding HLS, for our case its fine to only support playback for browsers that natively support HLS. We have a mix of Mux/HLS and third party static audio assets, and simply need to cover the most ground possible. It's nice that Mux player allows that flexibility to mix them up, but the no-js fallback is a hard requirement. The alternative would be to make sure Mux player doesnt render the audio
element at all server side, and I manually wire up the fallback. Thats more than fine if you disagree with the suggestion, and you can close the ticket. Thanks again!
Let me chew on this for a bit and discuss with the larger group before making any final decisions there. Regardless, always appreciate more context on how folks are wanting to use our elements, so thanks!
Cool thanks, looking forward to hearing back. As an aside, I kind of think a high quality general purpose media player could be great for introducing a bunch of devs/customers to the Mux service (which i also love). Cheers!
I'm running into a similar issue today w/ playback-id
not being server side rendered in a Next.js app with
https://github.com/muxinc/next-video
Many other attributes are:
player-software-name="mux-player-react" player-software-version="2.0.1" style="width:640px;aspect-ratio:1.7777777777777777" data-next-video="ready" class="flex"