back
loading skill details...
Tailwind CSS v4.2 browser-runtime patterns for HyperFrames compositions. Use when scaffolding or editing projects created with `hyperframes init --tailwind`,…
Tailwind CSS for HyperFrames
HyperFrames init --tailwind uses the Tailwind browser runtime pinned to @tailwindcss/browser@4.2.4. Treat that as Tailwind v4, not v3.
This skill is for composition HTML generated by the CLI. It is not for packages/studio, which still uses Tailwind v3 internally with tailwind.config.js, PostCSS, and @tailwind directives.
When To Use
The user asks for Tailwind in a HyperFrames composition.
A project was created with hyperframes init --tailwind.
You see window.__tailwindReady in index.html.
You need utility classes, CSS-first theme tokens, custom utilities, or v3-to-v4 migration guidance.
The render has missing styles and the project is relying on the browser runtime.
Version Contract
Pinned runtime: @tailwindcss/browser@4.2.4.
Browser runtime script is injected by the CLI. Do not replace it with cdn.tailwindcss.com.
HyperFrames waits for window.__tailwindReady before frame capture starts.
The readiness shim must stay deterministic: no render-loop polling APIs, no clock-based retries, no runtime network fetches beyond the pinned Tailwind runtime script.
For offline, locked-down, or production-stable renders, compile Tailwind to CSS and include the stylesheet directly instead of relying on the browser runtime.
v4 Rules
Tailwind v4 is CSS-first:
<style type="text/tailwindcss">
@theme {
--color-brand: oklch(0.68 0.2 252);
--font-display: "Inter", sans-serif;
}
@utility headline-balance {
text-wrap: balance;
letter-spacing: 0;
}
</style>
Avoid v3 setup patterns in browser-runtime compositions:
/* Do not use these in Tailwind v4 browser-runtime compositions. */
@tailwind base;
@tailwind components;
@tailwind utilities;
Do not add a tailwind.config.js just to define colors, fonts, spacing, or utilities for a v4 browser-runtime composition. Use @theme and @utility in a text/tailwindcss style block.
If you truly need an existing JavaScript config for a compiled v4 build, load it explicitly from CSS with @config, then validate in the browser. Do not assume v4 auto-detects v3 config files.
HyperFrames Composition Pattern
Keep Tailwind responsible for static layout and visual style. Keep motion timing in GSAP or another seekable adapter.
<section
class="clip absolute inset-0 grid place-items-center bg-zinc-950 text-white"
data-start="0"
data-duration="5"
data-track-index="1"
>
<div class="w-[1280px] max-w-[82vw] text-center">
<p class="mb-6 text-xl font-medium uppercase tracking-[0.18em] text-cyan-300">
Render-ready Tailwind
</p>
<h1 class="text-7xl font-black leading-none text-balance">
Utility classes, deterministic frames.
</h1>
</div>
</section>
For repeated items, prefer class lists plus CSS custom properties over generating class names dynamically:
<span class="inline-block translate-y-[calc(var(--i)*6px)] opacity-80" style="--i: 0"></span>
<span class="inline-block translate-y-[calc(var(--i)*6px)] opacity-80" style="--i: 1"></span>
<span class="inline-block translate-y-[calc(var(--i)*6px)] opacity-80" style="--i: 2"></span>
Dynamic Class Safety
Tailwind's browser runtime scans the current document and generates CSS for class names it can see. Do not build render-critical class names only at seek time:
// Risky: Tailwind may not see every generated class before capture.
element.className = `bg-${color}-500`;
Use complete class names in HTML, data attributes, or explicit CSS instead:
<div data-tone="blue" class="bg-blue-500 data-[tone=rose]:bg-rose-500"></div>
If a generated class is unavoidable, make sure the full class token appears in a text/tailwindcss block before validation.
Video-Specific Guardrails
Use stable dimensions: w-[...], h-[...], aspect-video, grid, flex, and fixed padding for video layouts.
Prefer transforms and opacity for animated properties.
Keep Tailwind transitions out of render-critical timing unless a seekable runtime owns the state.
Avoid hover, focus, scroll, viewport, or pointer variants for content that must render deterministically.
Use explicit border colors. Tailwind v4 changed the default border behavior from v3, so border border-white/20 is safer than bare border.
Use v4 utility names: shadow-xs, rounded-xs, outline-hidden, shrink-*, and grow-* where those replacements apply.
Be careful with modern CSS utilities if the output needs older browser support. Tailwind v4 targets modern browsers.
Validation
After editing a Tailwind-enabled composition:
npx hyperframes lint
npx hyperframes validate
npx hyperframes inspect
For a render proof:
npx hyperframes render . --workers 1 --quality draft --output tailwind-proof.mp4
The validation path should show no missing-style flashes on frame 0. If styles appear in preview but not render, check that window.__tailwindReady exists and resolves before capture.
Quick Debug Checklist
Confirm the project was scaffolded with hyperframes init --tailwind.
Confirm the script points to @tailwindcss/browser@4.2.4.
Confirm window.__tailwindReady is present.
Replace v3 @tailwind directives with v4 browser-runtime CSS.
Move custom tokens from tailwind.config.js to @theme.
Replace dynamically assembled classes with complete static tokens.
Run npx hyperframes validate and render a short proof.
Credits And References
Tailwind CSS official v4 installation, upgrade, and compatibility docs: https://tailwindcss.com/docs
Tailwind CSS v4 release notes: https://tailwindcss.com/blog/tailwindcss-v4
Community Tailwind skills were reviewed for v4 gotchas and skill shape, but this skill keeps the durable contract in-repo and HyperFrames-specific.don't have the plugin yet? install it then click "run inline in claude" again.
added explicit procedure steps with inputs/outputs, clarified decision logic for v3 vs v4 and offline compilation, documented browser-runtime edge cases (scanner limitations, readiness timing, offline fallback), added output contract and outcome signal sections, preserved original v4 rules and composition patterns.
use tailwind v4 browser runtime to style hyperframes compositions created with hyperframes init --tailwind. this skill covers utility classes, css-first theme tokens, custom utilities, v3-to-v4 migration, and validation. pick this skill when scaffolding or editing a hyperframes project that uses the pinned @tailwindcss/browser@4.2.4 runtime, when you see window.__tailwindReady in index.html, or when styles are missing and the render depends on browser-time tailwind compilation.
required context:
hyperframes init --tailwind flag<style type="text/tailwindcss"> blocksexternal connections:
tools and cli:
confirm the project uses hyperframes' browser-runtime tailwind. check index.html for script tag pointing to @tailwindcss/browser@4.2.4 and presence of window.__tailwindReady. input: index.html. output: confirmation or error log if missing.
if migrating from v3 config (tailwind.config.js or @tailwind directives), remove @tailwind base/components/utilities blocks from style tags. input: existing html and css. output: cleaned html without v3 directives.
define theme tokens and custom utilities in a <style type="text/tailwindcss"> block using @theme and @utility syntax. do not create tailwind.config.js for browser-runtime compositions. input: design tokens (colors, fonts, spacing) and custom utility specs. output: style block with @theme and @utility declarations in the document head or body.
write html with complete, static utility class names. do not assemble class names dynamically at render time (e.g., no bg-${color}-500 in javascript). input: layout structure and design intent. output: html with utility classes like bg-blue-500, text-lg, flex, etc.
for repeated elements with variation, use css custom properties and data attributes instead of dynamic classes. input: list of items to repeat with variable offset or color. output: html with shared class list and inline style="--i: value" for each element.
add explicit border colors (e.g., border border-white/20). v4 changed default border behavior from v3. input: border intent. output: utility classes with explicit color modifiers.
prefer transforms and opacity for animation. keep tailwind transitions out of render-critical timing unless a seekable animation runtime owns state. input: animation requirements. output: html with transform, opacity, and translate classes; motion timing in gsap or equivalent.
avoid hover, focus, scroll, and viewport variants in content that must render deterministically. input: interactivity requirement. output: static classes without reactive pseudo-variants, or explicit fallback styles.
validate composition with npx hyperframes lint and npx hyperframes validate. check for missing-style flashes on frame 0. input: edited html and styles. output: validation log showing no errors or list of style-coverage issues.
render a proof video with npx hyperframes render . --workers 1 --quality draft --output tailwind-proof.mp4. confirm window.__tailwindReady resolves before capture and all styles appear in frame 0. input: validated project. output: proof video file and console log of render timing.
if the project was scaffolded with hyperframes init --tailwind, use the browser-runtime patterns in this skill. if it was scaffolded without --tailwind or uses packages/studio, tailwind v3 config (tailwind.config.js, postcss, @tailwind directives) still applies; this skill does not cover v3 studio setup.
if you need to define colors, fonts, spacing, or utilities, use @theme and @utility in a text/tailwindcss style block. do not create or maintain tailwind.config.js for a browser-runtime composition.
if a project must render offline, in a locked-down environment, or needs strict production stability, compile tailwind to a css file (e.g., with the tailwind cli or a build step) and include the stylesheet directly. do not rely on browser-runtime compilation in those contexts.
if a generated class name is unavoidable (e.g., when data drives a color), ensure the full class token appears explicitly in a text/tailwindcss block or html file before validation. tailwind's scanner only sees classes in the document dom and static text; runtime-only strings will be missed.
if styles appear in preview but not in the final render, check that window.__tailwindReady is defined and resolves to true before hyperframes triggers frame capture. if it does not resolve, the browser runtime may not have finished compiling.
if you see style flashes or missing colors on frame 0, run npx hyperframes inspect to log all detected classes and npx hyperframes validate to check coverage. then adjust the @theme block or add missing tokens to the style block.
if older browser support is needed, note that tailwind v4 targets modern browsers. some utilities (e.g., oklch colors, css custom property syntax) may not work in legacy environments. compile to css and polyfill if required.
success means:
<style type="text/tailwindcss"> block with @theme and @utility rulesyou know the skill worked when: