One Screen Size Controller 💍

[bennypowers]

A Lemma

so,

1. rh-table uses breakpoints from tokens
2. rh-pagination will use breakpoints from tokens
3. rh-secondary-nav will also use breakpoints from tokens

👉 when it comes to abstractions, 3 uses is a nice jumping-off point

Two Awkward Solutions

as well,

• using breakpoints dynamically is awkward in .css files (no var() in @media())
• our workaround in rh-table is to have rh-table-responsive.css.ts, which is ok, but not ideal

so, what could we do to keep the javascript parts to themselves, while still allowing some semblance of css-firstery in our styles?

Solution: RHDSScreenSizeController

Straw API:

private screenSize = new RHDSScreenSizeController(this);

render() {
  return html`
    <div id="container" class="${classMap({ [this.screenSize.breakpoint]: true })}">
      ...
    </div>
  `;
}

which renders as

<div id="container" class="mobileXl">
  ...
</div>

then we could

#container.mobile { /* ... */ }
#container.mobileXl { /* ... */ }
#container.desktopLarge { /* ... */ }
#container.desktopSmall { /* ... */ }
#container.tabletLandscape { /* ... */ }
#container.tabletPortait { /* ... */ }
#container.mobileLandscape { /* ... */ }
#container.mobilePortrait { /* ... */ }

this would replace:

export const responsiveStyles = css`
  @media (min-width: ${mobileBreakpoint}) {
    #container { /* ... */ }
  }
  @media (min-width: ${mobileXlBreakpoint}) {
    #container { /* ... */ }
  }
  /* etc. */
`;

👼 Pros

• breakpoint tokens are only imported and used imperatively in one place, but used semantically everywhere
• no more .css.ts
• host attributes not needed

😈 Cons

• doesn't use standard @media() syntax, bespoke classes may be confusing

[bennypowers]

I've actually implemented an MVP / WIP in #279