Idea to make atomic props responseve

[tobiasschmidt89]

Hi there,

I recently found out that I can do this with custom props:

:root {
  --s4: 1rem;
  --s8: 2rem;
}
@media screen and (min-width: 80ch) { :root {
  --md-s4: var(--s4);
  --md-s8: var(--s8);
  --md-flex: flex;
}}

Usage in css.

.card {
  display: var(--md-flex, grid);
  padding: var(--md-s8, var(---s4));
}

Responsive atomic custom props feel like tailwind, but only one custom prop is needed per value and breakpoint vs. tailwinds property, value and breakpoint combination. Also it still feels like utility classes, but mixes better with using plain old css vs going full in with utility classes.

Usage in inline styles (jsx) also feels good and comparable to tailwind without the need of crazy tooling:

<Card style="padding:var(--md-s8, var(--s4));" />

This basically removes 50% of the reason why we have css-in-js. With some smart choices it is also possible to solve the other 50% of issue: Inline style interactivity. Compared to e.g. space props it is more difficult so to create a set of useful props in a library like open props

a:hover {
  --h-scale: scale(1.15);
}

Usage:

<Card style="transform:var(--h-scale, scale(1));" />

Maybe open props can become a responsive, atomic custom prop library with this.

KR
Tobi

[argyleink]

Nice, glad you're feelin it and finding workflows!

I see what you've got here as "house props" which you can totally make adaptive/responsive.

:root {
  --surface-1: var(--gray-1);
  --text-1: var(--gray-10);
}

@media (prefers-color-scheme:dark) {
  :root {
    --surface-1: var(--gray-11);
    --text-1: var(--gray-2);
  }
}

body {
  background: var(--surface-1);
  color: var(--text-1);
}

This makes --surface-1 and --text-1 adaptive to color scheme. It was initially setup by someone, me in this example, but other team mates later can just use the adaptive props and not worry about what backs them, they just know they get these adaptive atomic custom properties. Can be used in JSX or whatever.

I definitely think making house props is a great way to architect a back-of-the-front, to help accelerate a team 👍🏻

[tobiasschmidt89]

Ok nice I see. For colors this definitely works to "overload" them on a breakpoint. For spaces it would be necessary to write a new custom prop per breakpoint to use the "var fallback value" trick shown in my example (e.p. padding: var(--md-s8, var(--s4)); to e.g. change spacings per breakpoint or to switch the display type or a flex-direction or similar on a specific breakpoint. Introducing breakpoints is of cause a difficult decision for a library. So maybe it has to be house props.

Thanks

[WebMechanic]

This makes --surface-1 and --text-1 adaptive to color scheme.

we eventually went with separate theme style sheets delivered using <link .. media="(prefers-color-scheme:dark)"/> so the browser only loads one and defers the other.
With the supplemental JS based theme toggle we "force" either of these linked .css files to become active. Once the user uses the toggle the prefers-color-scheme basically goes down the drain and switching is controlled by script only.

[WebMechanic]

Interessanter Ansatz, Tobias.

I was toying with some selectors where we put size keywords that map to actual device sizes from our analytics using @custom-media inspired by props.media.css.
We changed the scale and keywords a bit and added some Sass mixins, maps, and functions to help generate and compute other props that match these size names, mostly just sm, md, and lg that map to a size-1, size-3 and size-5 respectively.

Now, for sizes that are virtually fixed for every layout, we use a single property, i.e. --size-3 (md).
Sizes that could/should vary based on media or container query we use pretty much the same as your fallback solution, i.e.

padding-inline: var(--v-size-3, var(--size-3))

--size-3 itself never changes, but --v-size-3 will be modified inside a @media or @container query, eventually using a selector other than :root to limit its scope to that part of a component or subtree.

:root {
  --size-3: 1em;
}

@media (--md-n-below) {
  :root {--v-size-3: .625em }
}

@media (--lg-n-above) {
  :root {--v-size-3: 1.625em }
  .card-body {--v-size-3: 1.25em }
}

@container product-listing (--slim) {
  .sidebar {--v-size-3: 1ch }
  .block-foot {--v-size-3: 3ex }
}

That's more or less what the generated code looks prior passing PostCSS for the custom-medias.
Each of the --v-size is actually a Sass function return value that takes a size keyword and an optional "responsive" flag which maps to a its fixed size property such as --size-3 or a flexible size using clamp().

We're still fleshing out the details and clamp formulae and also want to extend this idea to create "skip-if" and "show-if" selectors to toggle element visibility (i.e. long/short labels) based on available space or device width. Some components also need to toggle between display grid, flex and block. Your display: var(--md-flex, grid) example inspired me to give that a try as well.

It's fun to leverage the power of CSS custom properties with "house props" (nice name) and a "core" based on Open Props.

Enjoy coding!