prop-for-that

Sliders, pointer position, element visibility, viewport size, battery, network, sensors — JavaScript can read all of it; CSS can't. prop-for-that writes that runtime state into --live-* and --const-* custom properties — batched and diffed down to one setProperty per frame — so your CSS can compose and react to it with plain calc() and var().

Zero dependencies. TypeScript. ESM + CJS. SSR-safe.

npm i prop-for-that

<script type="module">import 'prop-for-that/auto'</script>

<input type="range" data-props-for="range" />

/* the slider paints itself from its own value — no event listeners, no render loop */
input {
  background: hsl(calc(var(--live-value-pct) * 120) 80% 50%);
}

Bind any element with data-props-for="key …" and read its --live-* properties in CSS. That's the whole idea.

Custom properties inherit downward only, and @container style() matches against an ancestor — so an element can't style-query the values written on itself, and its siblings never see them. Add data-props-to="<selector>" (or { to } imperatively) to observe the element but write its properties on the nearest matching ancestor:

<figure>
  <img data-props-for="img" data-props-to="figure" src="art.jpg" />
  <figcaption>…</figcaption>
</figure>

/* the skeleton is a sibling of the <img> — it can only react because the
   property lives on the <figure> */
@container style(--live-loaded: 0) {
  .skeleton { opacity: 1; }
}

propsFor(img, ['img', 'size'], { to: 'figure' }) // selector, or an element

• CSS does the work. No per-element event handlers or render loops — bind once, compose in stylesheets.
• Fast by design. One requestAnimationFrame flush per frame — idle when nothing changes, frozen while the tab is hidden — plus write-on-change diffing and a single shared ResizeObserver / IntersectionObserver for the whole page. Continuously-sampling element sources pause while their element is off screen; event-driven ones (form fields, ranges, selects) run ungated.
• Ship only what you use. Four lightweight core sources are built in; everything else is an opt-in, tree-shakeable plugin — and under auto each plugin loads on demand, the moment a data-props-for attribute asks for it.
• Plays with the platform. Opt into typed @property values for interpolation, or FOUC-safe constants written before first paint.
• Tiny and dependency-free, in every bundle format.

Core (built in): viewport, element size, visibility, and <input type="range"> values.

Plugins (opt-in): pointer position, battery, network, online status, page focus & visibility, navigation type, page meta tags, low-entropy user-agent (OS / browser / engine / version / mobile), FPS, clock, scroll velocity, device orientation / motion, geolocation, CPU pressure, soft-keyboard geometry, media playback, form & field state, select & color-picker values, text-truncation (ellipsis) detection, dominant + accent colors extracted from images and video, and per-element random rolls (optionally seeded) — 20+ in all.

→ Every source, every property, and live demos are in the docs.

auto sees the light DOM only (not shadow roots — bind those with propsFor(el, …)), and lazy-loads plugin chunks, so from a CDN use one that serves the dist files verbatim (unpkg / jsDelivr), not a rewriting CDN.

Full API and concepts: prop-for-that.netlify.app/docsite.

A condensed, single-file reference — entry points, the full variable catalog, recipes, and gotchas — lives at llms.txt, hosted at prop-for-that.netlify.app/llms.txt and shipped in the npm package (node_modules/prop-for-that/llms.txt).

MIT © Adam Argyle