Introduction
OmniUI is a practical, framework-agnostic UI toolkit. CSS-only components that work anywhere, with optional JavaScript enhancements when you need them.
What is OmniUI?
OmniUI is a component library built on a simple principle: components should work by default. No JavaScript required for core functionality. No framework lock-in. Just HTML and CSS that works everywhere.
CSS-Only First
Core components work without JavaScript. Use them in emails, static sites, server-rendered pages, or any environment where HTML and CSS work.
Framework Agnostic
Works with React, Vue, Svelte, Angular, vanilla JS, or no framework at all. No build step required for basic usage.
Progressive Enhancement
Start with CSS-only components, add JavaScript enhancements when you need interactivity. Use only what you need.
Accessible by Default
Built with ARIA patterns, keyboard navigation, and screen reader support. Respects user preferences like reduced motion.
Three-Tier Architecture
OmniUI organizes components into three tiers based on their JavaScript requirements:
Tier 1: CSS-Only
Zero JavaScript required. These components work with pure HTML and CSS. Buttons, cards, badges, alerts, form inputs, navigation, and more.
50+ components covering layout, actions, feedback, data display, forms, navigation, and disclosure patterns.
Tier 2: Enhanced (Coming Soon)
Optional JavaScript enhancements. Tier 1 components that gain additional functionality with JavaScript, but still work without it.
Examples: Accordion with animated transitions, tabs with keyboard navigation, form validation.
Tier 3: Interactive
JavaScript required. Complex interactive components that need JavaScript to function: drag-and-drop dashboards, modals, dropdowns, toasts.
These components still follow OmniUI patterns and integrate with the CSS system.
Design Principles
Works by Default
Every component has sensible defaults. Drop in the HTML, add the class, and it works. No configuration required for basic usage.
<!-- This just works -->
<button class="omni-button">Click me</button>
<div class="omni-card">Content here</div>
<span class="omni-badge">New</span>Data Attributes for Variants
Customize components using data-* attributes instead of modifier classes. This keeps the API clean and self-documenting.
<!-- Semantic variants -->
<button class="omni-button" data-variant="primary">Primary</button>
<button class="omni-button" data-variant="danger">Danger</button>
<!-- Style variants -->
<button class="omni-button" data-variant="primary" data-variant-style="outline">Outline</button>
<button class="omni-button" data-variant="primary" data-variant-style="ghost">Ghost</button>
<!-- Sizes -->
<button class="omni-button" data-size="sm">Small</button>
<button class="omni-button" data-size="lg">Large</button>CSS Custom Properties
Theming and customization through CSS custom properties. Override at any level: globally, per-component, or per-instance.
/* Global theme override */
:root {
--omni-color-primary: #0066cc;
}
/* Component-level override */
.my-special-button {
--omni-variant-bg: purple;
}Modern CSS
OmniUI uses modern CSS features for better performance and maintainability:
:where()selectors for low specificity (easy to override)- Logical properties (
margin-inline,padding-block) for RTL support color-mix()for dynamic color variations:has()selector for parent-based styling- Container queries for component-level responsiveness
The Variant System
OmniUI uses a consistent variant system across all components:
| Attribute | Values | Purpose |
|---|---|---|
data-variant |
primary, secondary, success, warning, danger, info | Semantic color meaning |
data-variant-style |
solid, outline, ghost, soft | Visual treatment |
data-size |
sm, md, lg | Component dimensions |
data-state |
loading, disabled | Interactive state |
When to Use OmniUI
Good Fit
- You want components that work without JavaScript
- You're building with any framework (or none)
- You need accessible components out of the box
- You want to progressively enhance functionality
- You need components for emails or static sites
- You want a foundation to build upon, not a design system
Maybe Not
- You need a complete design system with branding
- You want highly opinionated, styled components
- You're building exclusively for one framework (use native solutions)
- You need complex state management built into components