muxinc / elements

Custom elements for working with media in the browser that Just Work™
https://elements-demo-nextjs.vercel.app
MIT License
251 stars 45 forks source link

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

Open samburgers opened 1 year ago

samburgers commented 1 year ago

Is there an existing issue for this?

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.

cjpillsbury commented 1 year ago

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

samburgers commented 1 year ago

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

cjpillsbury commented 1 year ago

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!

samburgers commented 1 year ago

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!

luwes commented 11 months ago

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"