elements icon indicating copy to clipboard operation
elements copied to clipboard

Feature Request: Add src attribute fallback for no-js rendering

Open samburgers opened this issue 1 year ago • 5 comments

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 avatar Sep 04 '23 05:09 samburgers

@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 avatar Sep 05 '23 13:09 cjpillsbury

@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!

samburgers avatar Sep 07 '23 05:09 samburgers

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!

cjpillsbury avatar Sep 08 '23 14:09 cjpillsbury

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!

samburgers avatar Sep 09 '23 01:09 samburgers

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"

luwes avatar Oct 23 '23 21:10 luwes