Transparent background option <rh-audio-player>

[ocean-rh]

Description

should have an option for a transparent background that could then pick up the background color of the div it lives in. And that would need to be combined with a light or dark theme for the controls in case the background color is dark.

Suggested solution

I would like another theme option built into the player component.

Example API

<rh-audio-player color-palette="transparent-dark"></rh-audio-player>

or <rh-audio-player color-palette="transparent-light"></rh-audio-player>

Additional context

No response

[bennypowers]

Thanks for the report @ocean-rh. I'm going to convert this to a discussion until we prioritize this for design and implementation.

Some background on the color system:

The color-palette attribute takes a set list of palette names, so adding a new theme to player would mean adding a new theme to every other component.

As well, <rh-audio-player> has the --rh-audio-player-background-color css custom property, which could be helpful in achieving a transparent player.

You can try this out by visiting https://ux.redhat.com/elements/audio-player/demo/customization/ and running this snippet in the browser's dev tools:

$('main').style.backgroundColor = 'red';
$('rh-audio-player').style.setProperty('--rh-audio-player-background-color', 'transparent');

[bennypowers]

Can you paste here a few examples of the markup for pages you want to retrofit player on to, so we can get a better idea of the challenges involved?

[nikkimk]

What if we did a search for references to the old player's CSS (since you'd be retiring it once fully migrated anyway):

Find

.plyr-theme .plyr__controls {
   background-color: #633ec5
}

replace with

.plyr-theme .plyr__controls {
    background-color: #633ec5;
}
rh-audio-player {
  --rh-audio-player-background-color: #633ec5;
}

so that you wouldn't need to add transparent to every instance of the player's HTML or add to the complexity of the component itself?

[ocean-rh]

My team is hoping to get the option to not need custom css in the future. That was the ask behind this request. I expect that it will still be needed in older instances and in special cases.

All Command Line Heroes episode pages: https://www.redhat.com/en/command-line-heroes/season-9/relentless-replicators
Compiler: Hub and all interior pages: https://www.redhat.com/en/compiler-podcast
Code Comments: https://www.redhat.com/en/code-comments-podcast

[markcaron]

I'm hesitant to add a new transparent variant for a couple reasons:

1. Adding a variant (and extra JS overhead) to do something that CSS can do through CSS vars and ::part() selectors we've exposed for this exact purpose.
2. Adding a transparent variant which shifts the liability on RHDS for accessibility compliance. Meaning, if we provide a transparent option, are we responsible for any contrast issues with the text and controls in Audio Player as a result of the transparency? I'd much prefer this "variance" to be fully owned by the implementer.

The preferred way to add transparency would be through a CSS ::part() selector. Through this, one could make only the toolbar transparent instead of potentially all backgrounds in Audio Player (like the kebab menu).

This could be done at a global CSS level or in a style block on the page:

<style>
rh-audio-player::part(toolbar) {
    background: transparent;
}
</style>

Tighter control could be achieved in global CSS with a [transparent] attribute selector:

rh-audio-player[transparent]::part(toolbar) {
    background: transparent;
}

Or through a .transparent CSS class:

rh-audio-player.transparent::part(toolbar) {
    background: transparent;
}

Screenshot of the part="toolbar" we've exposed already for these situations:

The 2nd reason listed above, though, is what is most concerning, IMO. There's just no programatic way we can account for all the potential abuses of a transparent background. Depending on the background color—like highly saturated colors where neither white or black text works—the implementer may have to write their own CSS to ensure that the text and controls meet the required contrast guidelines anyway.

[markcaron]

@ocean-rh, I should note, that I'm not suggesting you'd "abuse" the transparent background, but that once we offer that option we open a can of worms for others to use in unexpected ways. I'd prefer that any customizations that break accessibility policies be 100% their fault.

[bennypowers]

Closing because rh-audio-player already supports OP's requirement and because we're not planning to add a one-off attribute, per our principle of preferring composition of primitive features to multiplying one-offs.