Media Chrome responsiveness / breakpoints / views, new custom element?

[luwes]

Wanted to open up a discussion and reference post on having different views / layouts for different container sizes or other conditions. Related to Media Themes, #42

Suggestion by @dylanjha:

<style>
  media-controlbar {
    --media-breakpoint-md: 768px;
  }
</style>

<media-control-bar md="hide">
<media-control-bar md="show">

Another option could be to have a special custom element for it:

<media-breakpoint md="show">
  <media-control-bar>
  </media-control-bar>
</media-breakpoint>

Should this be part of Media Chrome or could it be more generic?
What can we learn from CSS frameworks, Tailwind CSS?
Any custom elements already out there for this purpose?
Is it overkill to use JS for this? Have to, because container queries are not supported yet. Must use ResizeObserver.
Do we want to hide via CSS or actually add/remove nodes from the DOM?

Interesting related projects:

• https://github.com/GoogleChromeLabs/container-query-polyfill (1.6kB brotli)
• https://github.com/philipwalton/responsive-components and blog post
• https://github.com/Heydon/watched-box
• https://github.com/tomhodgins/style-container and Codepen and tweet

[gkatsev]

I would lean towards having the <media-breakpoint> element. Seems more explicit and clear to me.
To expand on it, it would also be interesting if we could introduce a <media-responsive> element as well that would wrap the media-controller to represent that we want a responsive player. So, we'd have something like

<media-responsive>
  <media-controller>
    <media-breakpoint small>
      <media-control-bar>
      </media-control-bar>
    </media-breakpoint>
    <media-breakpoint medium>
      <media-control-bar>
      </media-control-bar>
    </media-breakpoint>
  </media-controller>
</media-responsive>

[dylanjha]

I'm liking this direction 👍🏼

Also I'm thinking small, medium, etc. can be defined with css vars --media-medium-breakpoint: 768px , for example?

[gkatsev]

That works. Alternatively, it could take a media= attribute that would function similar to media-queries or the media attribute on source elements.
For example https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/media

<media-breakpoint media="all and (min-width: 600px)">
</media-breakpoint>

[luwes]

was thinking something similar, what if we can use as much of the container query syntax without the bloat of the polyfill (https://github.com/GoogleChromeLabs/container-query-polyfill) and also make the transition to real container queries super easy like renaming 1 attribute or so.

[gkatsev]

Also, in terms of container queries, depending on timing, we might be able to out wait the clock, since STP has them now, and chrome is implementing it soon. I think we'd just want to re-evaluate when we're ready to work on this and see where CQs are in browsers at the time.

[Nodalailama]

Hi,

I want to share the fact that aspect-ratio css property is now fully supported: https://caniuse.com/?search=aspect-ratio
Thus, it may be a great to use it to allow a more flexible way to include media-chrome in project.

That's it.

Best regards.

[luwes]

definitely, for keeping the Media Chrome dimensions inline with the video's intrinsic size this is the way to go!

[luwes]

After seeing other projects and experimenting a little I think we might be trying to over-engineer here.
There's really no need for extra custom elements which would only add noise to the DOM tree and increase nesting depth.
Container queries would also be invisible in HTML.

This snippet is pretty much what is needed,
https://philipwalton.com/articles/responsive-components-a-solution-to-the-container-queries-problem/#observing-container-resizes

Adding classes that the theme author can target in CSS or if using a render engine exclude parts of the DOM tree.

[gkatsev]

I think the main benefit that having the extra elements could add is being a lot more explicit and allow more easily to only hook up responsiveness when it's available. Also, with the media= attribute, one benefit is that it would be more easily and explicitly configurable rather than relying on what we decide should be the breakpoints.

However, you might be right that we're overthinking things, and we should just add it in and not worry too much about it.

[dylanjha]

What feels better -- let's say I have a very simple example:

A control bar that has:

• On small: shows a single play button
• On medium+: it has a play button + a full screen button

Something like (I'm using self-closing html elements for brevity):

Option 1

<style>
  media-controller[sm] media-full-screen-button {
    display: none;
  }
  
  media-controller[md] media-full-screen-button {
    display: block;
  }
</style>

<media-controller>
  <media-control-bar>
    <media-play-button />
    <media-full-screen-button />
  </media-control-bar>
</media-controller>

Option 2

<media-controller>
  <media-breakpoint sm>
    <media-control-bar>
      <media-play-button />
    </media-control-bar>
  </media-breakpoint>
  <media-breakpoint md>
    <media-control-bar>
      <media-play-button />
      <media-full-screen-button />
    </media-control-bar>
  </media-breakpoint>
</media-controller>

[gkatsev]

Given the current support for container queries that is pretty big already with Chrome 105+ and Safari 16 and that Firefox is the only missing one which has a pretty small marketshare at this point. Maybe our solution is to go full-in on container queries with the container queries polyfill used for firefox support (not included by default, but strongly encouraged/documented and also tested with)? This is because either of the above solutions, once implemented, will be available forever, so, if we're thinking that they may change down the line, it might be better to side-step it and go all in on container queries now.

[cjpillsbury]

After talking with @heff, there may be a value add to breakpoints support in addition to container queries, but we should see how far we can get with just assuming container queries for now (aka still may be a feature we want to support, but can probably be lower down the priority chain for the time being).

[gkatsev]

yeah, exactly. More features might be useful, but let's not rush adding them!

[dylanjha]

I think the action item here is to re-write this guide to show developers how they can use container queries to achieve responsiveness

[gkatsev]

Got two examples using container queries set up here:
Native container queries (which accounts for both Safari and Chrome): https://media-chrome-git-fork-gkatsev-responsive-example-mux.vercel.app/examples/responsive.html
Usage using the container query polyfill, working in Firefox: https://media-chrome-git-fork-gkatsev-responsive-example-mux.vercel.app/examples/responsive-polyfill.html
PR to add these examples is: #347