Styling

Pick a path by what you already have:

The paths combine. Each section says who wins when they collide.

Inline styles

The style prop puts CSSProperties on one node. It overrides the tag default and every matching stylesheet rule at the same importance.

<div style={{ display: "flex", padding: 48, background: "#0f172a" }}>Hello</div>

CSS

Pass real CSS through css, one string or a list. The engine matches it by className or id.

import { render } from "takumi-js";

const image = await render(<div className="card">Hello</div>, {
  width: 1200,
  height: 630,
  css: `.card { display: flex; padding: 48px; background: #0f172a; color: white; }`,
});

The engine handles:

A <style> tag feeds the same engine. Takumi extracts it from the JSX for you.

<div className="card">
  <style>{`.card { display: flex; padding: 48px; }`}</style>
  Hello
</div>

Tailwind with your bundler

Compile Tailwind with your bundler, then pass the generated CSS through css. Tailwind does the compiling, so every directive and class name works. What renders is still bounded by the engine's CSS support. With Vite, import the stylesheet using ?inline.

import { ImageResponse } from "takumi-js/response";
import stylesheet from "~/styles/global.css?inline";

export function GET() {
  return new ImageResponse(
    <div className="bg-background text-foreground flex justify-center items-center w-full h-full text-4xl">
      Hello Tailwind!
    </div>,
    {
      width: 1200,
      height: 630,
      css: stylesheet,
    },
  );
}

import { defineConfig } from "vite";
import tailwindcss from "@tailwindcss/vite";

export default defineConfig({
  plugins: [tailwindcss()],
});

Tailwind without a build step

The tw prop runs a built-in parser with no build step. It matches the satori prop, so next/og code ports as-is.

import { render } from "takumi-js";

const image = await render(
  <div tw="bg-blue-500 p-4 rounded-lg">
    <h1 tw="text-white text-2xl font-bold">Hello Tailwind!</h1>
  </div>,
  { width: 1200, height: 630 },
);

Arbitrary values work. The parser does not cover every Tailwind feature. The parser mapping lists every supported class.

tw is a plain prop, so build it dynamically:

import clsx from "clsx";

const isError = true;

<div tw={clsx("p-4 rounded", isError ? "bg-red-100 text-red-700" : "bg-green-100 text-green-700")}>
  {isError ? "Something went wrong" : "Success!"}
</div>;

Preflight

The native parser applies no Tailwind Preflight by default, so elements keep their UA margins. A <h1> gets a 0.67em top margin until you add mt-0. box-sizing still defaults to border-box.

The same import line a Tailwind stylesheet starts with turns Preflight on. It drops the UA margins, list markers and heading font tweaks.

const image = await render(node, {
  css: `@import "tailwindcss";`,
});

Utilities in the cascade

Utilities sit in the last declared layer, Tailwind's own order:

Prefix a utility with ! to flip the result. Important declarations reverse the layer order, so a ! utility beats an unlayered rule and a normal style declaration.

Tailwind at-rules

A Tailwind source stylesheet drops into css unchanged. The engine reads these directives and skips the rest:

.card {
  @apply mt-4 bg-brand-500; 
}

Other Tailwind directives do not parse: @utility, @custom-variant, @source, @plugin and @config. Compile those with Tailwind and use the bundler path.

Design tokens

A utility reads a CSS custom property, the way Tailwind compiles it. bg-red-500 resolves var(--color-red-500), and p-4 resolves calc(var(--spacing) * 4). The built-in scale sits behind them as the fallback, so tokens stay optional until you want your own palette.

Declaring tokens

Three equivalent places. All of them feed every var(), in stylesheets, in <style> tags, and in utilities.

A :root rule, or a Tailwind @theme block pasted as-is:

:root {
  --color-brand-500: #5b21b6;
  --spacing-gutter: 2.5rem;
}

Or the cssVariables option, which compiles into a :root rule. The leading -- is optional.

import { render } from "takumi-js";

const image = await render(<div tw="bg-brand-500 p-gutter">Hello</div>, {
  width: 1200,
  height: 630,
  cssVariables: { "--color-brand-500": "#5b21b6", "--spacing-gutter": "2.5rem" },
});

Takumi drops an entry whose value contains ;, {, }, /* or !important. It also drops an entry whose name contains :, ;, { or }. Those entries could escape the generated rule.

A nested palette flattens with the cssVariables helper. Keys join with - into one variable name.

import { cssVariables } from "takumi-js/helpers";

const flat = cssVariables({ color: { brand: { 500: "#5b21b6" } } });
// { "--color-brand-500": "#5b21b6" }

Which utilities read a token

The namespace picks which utilities a token reaches:

Overriding tokens

Tokens declared in a stylesheet follow the CSS cascade. A media query or a selector can override them:

@media (prefers-color-scheme: dark) {
  :root {
    --color-brand-500: #a78bfa;
  }
}

Tokens passed as cssVariables sit in a rule after every stylesheet:

Where this differs from Tailwind

• Colours reach gradients and shadows. from-brand-500 and shadow-brand-500 read --color-brand-500 like bg-brand-500 does.
• Same as Tailwind, but easy to miss: a gradient needs bg-linear-*, bg-radial or bg-conic. Stops alone paint nothing.
• --color-red-500: initial falls back to the built-in red instead of removing bg-red-500.
• A bare rounded keeps its built-in value. rounded-sm and the rest read the variable.
• --spacing needs a unit. A bare number makes p-4 compute pixels here, where a browser rejects the declaration.
• An aliased token stays live. --color-brand: var(--background) follows a subtree --background override. In a browser, @theme inline exists to arrange that.