Download the PHP package inlayphp/design without Composer

Inlay Design

The public design-system façade for Inlay applications.

inlayphp/design gives applications one stable place to choose semantic tokens, generate CSS, and create an application-owned theme class. It builds on the serializable inlay.themes.v1 contract from inlayphp/theme, so existing Theme and panel integrations remain compatible.

Install

The frontend companion is @inlayphp/design:

Presets and fluent themes

Design::base() is the neutral zinc foundation. Design::orbit() is the canonical Inlay operations workspace: a cool-white canvas, light sidebar, restrained purple accent, 44px controls, and readable status roles. Design::default() is the same Orbit preset under the stable default name. Design::highContrast() provides stronger light/dark foreground, border, and status contrast. Design::make('brand') creates an empty contract. named() copies the token maps under a new name; tokens() and darkTokens() merge overrides.

The lower-level Theme class remains supported:

Use Design for new code and keep Theme when maintaining an existing package or panel.

Generate an application theme

The generator creates both the PHP source of truth and a CSS variable file:

Generated files:

The class is intentionally application-owned so domain decisions never leak into the package:

Import the generated CSS from the application's Tailwind/Vite entry point:

The stylesheet contains :root light variables, dark overrides for prefers-color-scheme, and an explicit [data-theme="dark"] mode. Add data-theme="light" to the root shell when an explicit light choice should override the operating-system preference. Pass the theme to a panel with $panel->theme(BrandTheme::make()) and share the same serialized contract with React or Vue.

The frontend façade also re-exports the centralized recipe layer from @inlayphp/ui:

Recipes read the generated semantic variables, so an application can adjust spacing, typography, focus rings, transitions, and component variants through its theme contract instead of copying Tailwind strings.

The command accepts safe relative output paths and an explicit overwrite flag:

Names and paths reject traversal, empty segments, unsafe class characters, and absolute paths. Existing files are never overwritten unless --force is provided.

CSS contract

Design::css() emits deterministic --inlay-{token} custom properties. Null tokens are omitted, booleans are normalized to true/false, and unsafe CSS delimiters are rejected before output. Token names are semantic and lowercase (surface-muted, danger, control-height); avoid component-specific names so community packages can consume the same contract.

Extending the design system

Official and community packages should:

• consume semantic variables instead of hard-coded colors and dimensions;
• expose stable data-slot hooks and typed class-name overrides;
• reuse the @inlayphp/design controlClass, buttonBaseClass, and semantic button variant recipes;
• keep application-specific tokens in the generated application theme;
• provide both React and Vue renderers when the component is intended for both targets.

The current package is the first design-system slice. High-contrast presets, icon registries, shared recipes, and the first headless primitive are available behind the same public boundary. @inlayphp/ui-react and @inlayphp/ui-vue provide the renderer-specific Dialog primitive; both use the same @inlayphp/ui recipes and accessibility contract. Additional primitives can be added without changing application-owned theme tokens.

Testing

The package includes generator tests, CSS safety tests, and the matching frontend contract tests.

Related packages

• inlayphp/theme: serializable PHP theme builder kept for compatibility.
• @inlayphp/design: TypeScript façade and shared renderer recipes.
• inlayphp/panels: panel-level theme delivery.
• inlayphp/forms, inlayphp/tables, inlayphp/actions, and inlayphp/widgets: semantic-token consumers.