EEnterUI
DocsComponentsThemesDonation
Get Started
  • Overview
  • Introduction
  • Installation
  • SolidJS Renderer
  • Theming
  • Styling PhilosophyLearn how EnterUI handles styling.
  • Production Checklist
  • Migration & Versioning
EnterUIDocsGetting StartedStyling Philosophy
Getting StartedUpdated 6 May 2026

Styling Philosophy

How EnterUI stays polished by default, fully themeable, and free of any required utility-CSS framework.

EnterUI brings the FroggDesign visual language into ready-to-use product surfaces. It targets React and Next.js apps, dashboards, SaaS products, internal tools, admin panels, and interfaces that need refined defaults without a heavy styling setup.

The styling principle is simple: beautiful by default, flexible by design.

Every component ships with mature defaults but stays open to override. Start with the component as-is, then adjust theme, brand, density, or repeated product patterns through CSS variables, className, style, or composition, in that order.

#What The Defaults Optimize For

  • Calm, premium product UI rather than decorative demo surfaces.
  • Dense but readable dashboards and internal tools.
  • Clear focus-visible, hover, disabled, invalid, selected, loading, and empty states.
  • Neutral hierarchy with green used only as a small success or selection signal.
  • Stable dimensions for common controls so variants do not shift layouts unexpectedly.

#Tailwind Is Not Required

EnterUI does not depend on Tailwind. You can use Tailwind alongside it, but it is fully optional.

The primary styling layer is plain CSS variables plus predictable .eui-* classes. That keeps EnterUI portable across plain CSS, CSS Modules, Sass, styled-components, vanilla-extract, Panda CSS, Emotion, Tailwind, and existing product design systems.

#Override Order

Apply overrides in this order:

  1. CSS variables for app-wide or scoped theme decisions.
  2. className for one-off component adjustments.
  3. style for local dynamic values.
  4. Wrapper components for repeated product patterns.

#CSS Variables

Use variables for design decisions that should survive component updates.

app/globals.css
:root {
  --eui-primary: #2563eb;
  --eui-primary-foreground: #ffffff;
  --eui-ring: #60a5fa;
  --eui-radius-md: 12px;
}

#className

Use className when a local product surface needs extra layout or a narrow visual adjustment.

Code
import { Button } from "@froggdesign/enter-ui-react";

export function SaveButton() {
  return <Button className="settings-save-button">Save</Button>;
}
Code
.settings-save-button {
  min-width: 120px;
}

#Tailwind Optional

Code
import { Button } from "@froggdesign/enter-ui-react";

export function HeroAction() {
  return <Button className="rounded-full px-6">Get started</Button>;
}

This is a convenience, not a requirement. EnterUI does not ship Tailwind, depend on it, or lock consumers into utility classes.

#CSS Modules

button.module.css
.customButton {
  border-radius: 9999px;
  padding-inline: 24px;
}
Code
import { Button } from "@froggdesign/enter-ui-react";
import styles from "./button.module.css";

export function SaveButton() {
  return <Button className={styles.customButton}>Save</Button>;
}

#Component Composition

Compose EnterUI primitives into product-specific components instead of changing package internals.

Code
import {
  Badge,
  Button,
  Card,
  CardContent,
  CardFooter,
  CardHeader,
  CardTitle,
} from "@froggdesign/enter-ui-react";

export function ProductCard() {
  return (
    <Card>
      <CardHeader>
        <Badge variant="info">Platform</Badge>
        <CardTitle>Billing Console</CardTitle>
      </CardHeader>
      <CardContent>Built with EnterUI primitives and FroggDesign tokens.</CardContent>
      <CardFooter>
        <Button>Open product</Button>
      </CardFooter>
    </Card>
  );
}

#Class Naming

EnterUI uses the .eui-* prefix so overrides are easy to identify. Common public classes include:

  • .eui-button
  • .eui-card
  • .eui-input
  • .eui-select__trigger
  • .eui-dialog__content
  • .eui-table
  • .eui-app-shell
  • .eui-toast

Prefer top-level component classes and documented parts. Avoid depending on private DOM structure unless the docs explicitly describe that part as a stable styling surface.

#Chart And Data Styling

Charts use lightweight SVG and token-based tones. Avoid turning analytics cards into decorative illustrations. Keep line, area, heatmap, and metric colors restrained so they support scanning instead of dominating the page.

#Do And Don't

Do

  • Start with default styles.
  • Override through theme variables for rebrand work.
  • Use className for local layout.
  • Create wrapper components for repeated product patterns.
  • Keep text and controls stable across responsive sizes.

Don't

  • Override every component without a reason.
  • Hard-code colors when a token is available.
  • Lean on internal DOM structure that is not documented.
  • Use green as a dominant background or brand wash.
  • Make Tailwind a hard requirement for consumers.

#In Short

EnterUI exists so teams can ship refined interfaces immediately while keeping full control when a product needs a custom theme, density, or composition pattern.

PreviousTheming
NextProduction Checklist

On this page

  1. What The Defaults Optimize For
  2. Tailwind Is Not Required
  3. Override Order
  4. CSS Variables
  5. className
  6. Tailwind Optional
  7. CSS Modules
  8. Component Composition
  9. Class Naming
  10. Chart And Data Styling
  11. Do And Don't
  12. In Short