Theme template breakpoints for responsiveness

[dylanjha]

It seems like every theme will have a need for handling responsiveness. What we're doing with Mux Player is something like this proposed in #369 :

<template if="layout == 'on-demand large'">
</template>

Alt syntax in an earlier iteration is:

<template directive="layout" expression="on-demand large">
</template>

The user of this theme would have to pass in the large size as an attribute. What is cumbersome here is that the user of the theme has to keep track of the containers size and update the attribute accordingly, resulting in a lot of boilerplate code with resize observers.

<mux-theme layout="on-demand large">

It seems to me like the theme should be able to keep track of that (and the theme author can decide on the breakpoints, which are important for the overall design of the theme).

Proposal

Something where I can use familiar media-query syntax to tell the theme to only render a certain layout

<template if="layout == 'on-demand'" size="'min-width 600px;'">
</template>

Open to any and all possible iterations of the syntax, but the main thing I'm getting at is that the theme author, a designer working with HTML and CSS is able to specify breakpoints in the template.

[luwes]

I like this but it'll require a little more work on our side than the solution I mentioned internally I think depending on how far we want to go with the query syntax in the size attribute.

I hacked something together that might work to get our selective rendering to work with MC themes without having to set a player size as an attribute.
It uses container queries and will require some JS in the MediaTheme class
https://codesandbox.io/s/re-render-via-container-queries-ujh4ii?file=/index.html

[luwes]

actually this is good.

I'm gonna add new state properties width and height that can be used in the if directive and are re-evaluated on resize observer events. if the condition changes it will trigger a re-render.

was thinking this could be a powerful concept where we add some other predetermined state properties as well like paused, currentTime, ended that they can check in the if directive

[gkatsev]

It might be nice to be similar to the media attribute in the picture element https://developer.mozilla.org/en-US/docs/Web/HTML/Element/picture#the_media_attribute
However, the name can be confusing, and the media query syntax is harder to parse, though, possible to get it to be parsed natively.

[luwes]

I did some more thinking on this one and I think we should try not to mix the 2 syntaxes because it will cause confusion while editing the template if directives.

I'm still open to the idea but keep in mind it will require another syntax parser evaluate for the container query syntax.
Behind the scenes it would do the exact same thing than option 2 below...

We have to decide between these 2 I think:

1. Use container queries on the template directives, this will involve adding a class or id to the template element.
   It's a little hacky because we'll add dummy template elements to the document with the same attributes and check whether they are visible or not and trigger a re-render if they change visibility. Requires an IntersectionObserver in the media-theme web component. Requires container queries browser support or polyfill.

    <style>
      media-controller {
        container: media-chrome / inline-size;
      }
      .small,
      .large {
        display: none;
      }
      @container (inline-size < 420px) {
        .small {
          display: block;
        }
        .large {
          display: none;
        }
      }
      @container (inline-size > 590px) {
        .small {
          display: none;
        }
        .large {
          display: block;
        }
      }
    </style>

  <media-controller>
    <slot name="media" slot="media"></slot>
    <template if="type == 'on-demand'" class="small"></template>
    <template if="type == 'on-demand'" class="large"></template>
  </media-controller>

2. Use the existing if attribute and add support for evaluating the width and height in that expression. Will require a ResizeObserver in the media-theme web component. Supported on all browsers now.

  <media-controller>
    <slot name="media" slot="media"></slot>
    <template if="type == 'on-demand' && width < 420"></template>
    <template if="type == 'on-demand' && width > 590"></template>
  </media-controller>

I'm leaning to option 2. Requires less code for the user, simpler, less hacky.

Started beefing up our expression logic here #383

[dylanjha]

➕ 1️⃣ for number 2!

[luwes]

ok we decided we're going to start with a simpler syntax that should give enough power and flexibility.
no conditional chaining with && or || but use nested template's for that.

the next decision is about how we want the if condition for breakpoints to look like.
Maybe in these lines now we have the breakpoint attributes #398

Both solutions involve adding some new params to the templates.

1. @heff's idea from feat: add breakpoint-x attributes #398 (comment)

<template if="containerSize >= sm">
  <template if="containerSize <= md"></template>
</template>

a.

<template if="breakpointSm">
  <template if="notBreakpointMd"></template>
</template>

b.

<template if="breakpointSm">
  <template if="!breakpointMd"></template>
</template>

[heff]

I (obviously) suggest just containerSize, at least start there and see if we need more. All the power and reference to breakpoints is available there, and you can also use a number like containerSize > 1920.

if="breakpointSm" isn't immediately clear if it's true when breakpointSm is exact, or true if anything above it is true, because of how breakpoints work on media controller. I don't think it's a good fit here.

[luwes]

cool, note that this will update the container-size attribute many times on resizing triggering a re-render.
should be fine I think, we can always throttle if needed.

[heff]

Ah I see, if containerSize can be a number, right? Let's not start with that option then.

[luwes]

yes indeed, it being a number then

[heff]

If it's not clear I was thinking it could support both containerSize > 1920 AND containerSize > sm, but if containerSize is an attribute with a value of one of the size labels, that doesn't really makes sense. At least without some magic under the hood to translate containerSize into a number.