Sliding-out volume controls and the implications

[heff]

Re-posting in discussions so we can close #40

---

Publishing my neurosis here for entertainment and in case anyone has an interesting view point.

I'm working on example of audio players, and I'm feeling compelled to use a volume control that reveals itself rather than is aways visible, because audio players tend to be on the smaller side.

For an example of sliding-out/revealing audio controls see the youtube player or the default chrome controls for audio (and video).

Because this requires a relationship between the mute-button and the volume-range, the possible implementations then balloon out of control, with various benefits and costs of each.

All that to say, I think the short term answer is to do nothing for now, and rely on the themes (Option E), at least until we have a clearer understanding of how theming will work and where the challenges will be.

Volume Control Notes

Option A: Set sibling relationship

<media-mute-button reveal-volume-range="asdf"></media-mute-button>
<media-volume-range id="asdf"></media-volume-range>

Positives

• Control hierchy stays flat
• No change to how you style the two components

Negatives

• Need to use javascript to do the hiding.
  • Not the worst.
• Tab order could be weird. You really want the next tab after the mute button to go to the volume control, otherwise it will get hidden. So volume really needs to come after or before the mute button
  • The volume range should reveal itself on focus either way

Option B: Child volume range

<media-mute-button>
  <media-volume-range></media-volume-range>
</media-mute-button>

Positives

• Makes it easy to align volume to the mute button however is needed
• Volume is still in the light dom, so no shadow dom challenges

Negatives

• Styling challenges
  • Volume range has backgrounds, padding, etc, that need to be adusted now that it's in side the mute button. If a theme styles the volume range, we'll want some of those styles to apply (e.g. range handle styles), but not padding, backgrounds, etc.
• Is tab order a challenge? Can you tab to child element from a parent?
• Have to solve all the layout possibilities, or the most prominent ones

Option C: Single combined control

<media-volume-button reveal-volume></media-volume-button>

Positives

• Simple concept
• Could replace the other two

Negatives

• Confusion around which volume elements to use and when
  • Unless this replaces the existing independent controls, but that could be pretty restricting
• Have to solve all the mute/volume layout possibilities, or at least the most prominent ones

Option D: A parent element to combine them

<media-volume-control-set reveal-volume>
  <media-mute-button></media-mute-button>
  <media-volume-range></media-volume-range >
</media-volume-control-set>

Positives

• Keep them independent controls, so styling looks relatively the same as other use cases.

Negatives

• Creates hierarchy in the controls which can complicate theme styles
  • Today we use control-bar > * to style direct children of the control bar and avoid styling everything deeper. Couldn't do that anymore.
• Does this create complication for themes? Do you have to account for someone using this set component? (I think a theme actually needs to be inclusive of the HTML).

Option E: Put it on the themes to handle

A very real option here is to not provide this feature at the component level. In the youtube them it's all in the CSS. It's a complex interaction that would be nice to simplify out of the box, but maybe not at the risk of making all other styling more complex.

[cjpillsbury]

My leanings right now are (E) since it is a currently available working solution (albeit one that requires some CSS acrobatics, at least for the time being), where we can prioritize a full blown component if there is demand/need from the community.

If we were to proceed, I'd probably start with (C) or (D), which I believe should be fairly similar implementations "under the hood", especially if we add well-defined slots to (D). These fit well with our current UI architecture, and some of the negatives can be mitigated with smarter CSS or other minor tweaks (e.g. category attributes, more reliance on classes in our examples/"recipes", etc.).

Both (A) & (B) add complexity to existing components that for now are "single purpose" and reasonably simple. I'd be concerned about decisions that start baking in more and more complexity into "primitive" components when we can instead "compose" more advanced components out of the primitive ones.
I do think we will need some kind of component <--> component intercommunication/interactivity going forward (a la (A)), and one path forward for its implementation could rely on similar/the same concepts we're discussing in #102 for showing/hiding components based on support/availability (hiding volume on mobile, hiding CC button if there are no captions/subtitles, hiding Airplay if it's unsupported, etc.), though I think we'd want to button that down before implementing anything like that here.