Kein Sass. Kein Bundler. Kein Build-Schritt.

Natives CSS. Volle Kontrolle.

NativeCSS ist ein Design-System, das komplett auf bereits existierende Browser-Features setzt - Cascade Layers, Container Queries, light-dark(), natives <dialog>, scroll-getriebene Animationen. Kein Preprocessor, kein Kompilierschritt, kein Framework-Lock-in.

Auf GitHub ansehen Demo entdecken

<link rel="stylesheet" href="ncss.css">
<link rel="stylesheet" href="theme.css">
<!-- fertig. kein npm install, kein Build. -->

Warum natives CSS

Was seit 2024/2025 in jedem aktuellen Browser steckt - und kaum genutzt wird

Die letzten Jahre haben CSS mehr echte Sprachfeatures gebracht als das letzte Jahrzehnt Tooling. NativeCSS baut ausschließlich darauf auf, statt sie hinter einem Preprocessor zu verstecken.

Cascade Layers

Reihenfolge statt Spezifitäts-Kämpfe - tokens < reset < base < helpers < components. Kein !important, keine ID-Selektoren als Notbremse.

light-dark()

EIN Wert pro Token deckt Hell und Dunkel ab - kein zweites Dark-Stylesheet, keine .dark-Klasse, die durch jede Komponente gereicht werden muss.

Container Queries

Komponenten reagieren auf ihren eigenen Platz, nicht auf den Viewport - eine Karte in der Sidebar verhält sich anders als dieselbe Karte im Hauptbereich, automatisch.

Natives HTML

<dialog> und <details> statt JS-Nachbauten für Modal/Dropdown/Off-Canvas - Fokus-Handling, ESC-Taste und ::backdrop kommen kostenlos vom Browser.

Scroll-getriebene Animationen

animation-timeline: view()/scroll() - Lesefortschritt, Scroll-Reveal, gestapelte Karten, alles ganz ohne IntersectionObserver oder Scroll-Event-Listener.

Eine Quelle der Wahrheit

Ganze Farbskalen (100-900, -on-soft) per color-mix() aus EINEM Basiswert berechnet - eine Marke in theme.css ändern, die ganze Skala zieht automatisch mit.

Cherry-Picking statt Alles-oder-nichts

Jede Komponente eine eigene, kleine Datei (components/card.css, components/modal.css, ...) - nur einbinden, was gebraucht wird. Kein Bundler, der ungenutztes CSS erst per Purge wieder herausschneiden muss.

Features im Scrollverlauf

Fünf Bausteine, die NativeCSS ausmachen

Diese Sektion ist selbst ein NativeCSS-Feature: .ncss-stack-section (components/scroll-stack.css) - Karten stapeln sich beim Scrollen, komplett ohne JavaScript, mit einem funktionierenden Fallback für Browser ohne view()-Unterstützung.

Design-Tokens & Theming

Eine einzige theme.css - Markenfarben, Radien, Schriften, Bewegung. Kein !important, kein zweiter Ort, an dem Werte gepflegt werden müssen.

Cascade Layers

Jede Datei liegt in einem benannten Layer. Reihenfolge entscheidet, nicht Spezifität - Web-Awesome-Bridge gewinnt garantiert gegen Web Awesomes eigenes Theme.

Scroll-getriebene Animationen

Lesefortschritt, Vollbild-Sektionen, diese Stapel-Karten hier, eine sich selbst zeichnende Roadmap-Linie - alles animation-timeline, kein JS.

Web Awesome nur wo nötig

Selbst gehostete Web Awesome + Font Awesome Komponenten (Rating, Tree, Popover) - niemals fürs Seitengerüst, damit die Seite nicht von ES-Modulen abhängt.

Barrierefreiheit eingebaut

prefers-reduced-motion global respektiert, :focus-visible-Ringe, WCAG-geprüfte Kontraste - kein nachträgliches a11y-Audit nötig.

Alle Features im Überblick

Ein solides Grundgerüst - kein Wildwuchs

Noch ein NativeCSS-Feature in eigener Sache: .ncss-stack-section--horizontal - dieselbe Stapel-Mechanik wie oben, nur seitlich statt vertikal.

Tokens & Theming

Fluid Typografie/Spacing (clamp())
Farbskalen per color-mix()
light-dark(), keine zweite Datei
Farbpaletten per [data-palette]
Eine theme.css für alles

Layout & Helfer

Grid/Stack/Cluster-Utilities
Container Queries statt Breakpoints
Responsive Tabellen (2 Strategien)
Elevation (Rahmen/Schatten/Radien)
Sticky, Scroll-Snap, Vollbild-Sektionen

Komponenten

Card, Modal, Off-Canvas, Dialog
Topbar, Nav (Mega-Menü, Dropdown, Tree)
Badge, Breadcrumb, Disclosure, Suche
Select, Slideshow, Sparkline
Audio/Video, Hero, Footer

Scroll & Bewegung

Scroll-Progress-Balken
Auto-Hide Topbar (wie hier oben)
Stacked Cards (vertikal/horizontal)
Sich selbst zeichnende Roadmap-Linie
Cross-Document View-Transitions

Web-Awesome-Integration

Selbst gehostet, kein CDN
Bridge an ncss-Tokens gekoppelt
Font Awesome Icons inklusive
Nur ergänzend, nie fürs Grundgerüst
Eigene lokale Referenz-Doku pro Version

Qualität

Kein Build-Schritt, kein node_modules
@supports-Fallbacks für neue CSS-Features
WCAG-Kontrastprüfung eingebaut
prefers-reduced-motion global
In echten Browsern getestet, nicht nur angenommen

Code-Beispiele

So sieht es in der Praxis aus

Karte + Button, automatisch dark-mode-fähig

<article class="ncss-card ncss-radius-lg ncss-border ncss-shadow-sm">
  <div class="ncss-card-body">
    <h3>Titel</h3>
    <p>Text ...</p>
    <button class="ncss-btn ncss-btn--primary">
      Aktion
    </button>
  </div>
</article>

Eigene Marke - `theme.css`

:root {
  --ncss-color-brand:
    light-dark(#6f6f6e, #b7b7b6);
  --ncss-color-bg:
    light-dark(#154a86, #0b1c33);
}
/* Skalen (100-900), Badges, Buttons,
   Cards ziehen automatisch mit. */

Gestapelte Karten (wie oben)

<div class="ncss-stack-section"
     style="--ncss-stack-count: 4;">
  <div class="ncss-stack-stage">
    <article class="ncss-stack-card"
      style="--ncss-stack-index: 0">
      ...
    </article>
    <!-- ... -->
  </div>
</div>

Modal - natives `<dialog>`

<button command="show-modal"
        commandfor="d">Öffnen</button>
<dialog id="d" class="ncss-modal">
  <div class="ncss-modal-body">
    Kein JS-Framework nötig.
  </div>
</dialog>

Vergleich

Wie ordnet sich NativeCSS ein?

Kein Framework ist per se "falsch" - hier die ehrliche Gegenüberstellung, wofür NativeCSS eine andere Wahl trifft.

Tailwind CSS vs. NativeCSS

Kriterium	Tailwind CSS	NativeCSS
Build-Schritt	Ja, PostCSS-Pipeline + Purge nötig	Nein - `<link>` reicht
Ansatz	Utility-Klassen im Markup	Kuratierte Komponenten + kleine Utility-Sets
Theming	Config-Datei, eigenes Build nötig	EINE `theme.css`, kein Build
Dark Mode	`dark:`-Präfix auf jeder Klasse	`light-dark()`, ein Wert pro Token
Markup-Lesbarkeit	Viele Klassen pro Element	Wenige, sprechende Klassennamen
Bundle/Dateigröße	Abhängig vom Purge-Ergebnis	Statisches CSS, kein Purge nötig
Lernkurve	Eigene Utility-Namenskonvention	Normales CSS + Custom Properties

UIkit 3 vs. NativeCSS

Kriterium	UIkit 3	NativeCSS
Preprocessor	LESS, Build zum Anpassen nötig	Keiner - reines CSS
JS-Abhängigkeit	Eigenes JS für Modal/Dropdown/Off-Canvas	Natives `<dialog>`/`<details>`
Theming-Mechanik	LESS-Variablen, neu kompilieren	CSS Custom Properties, live
Responsive	Viewport-Breakpoints	Container Queries pro Komponente
Dark Mode	Separates Theme/Klasse	`light-dark()` eingebaut
Web-Component-Ergänzung	Nein	Web Awesome optional, nur wo nötig
Cascade-Kontrolle	Spezifität/Reihenfolge im LESS	Cascade Layers, explizite Reihenfolge

Ehrlich bleiben

Nicht jedes Feature läuft überall gleich - das ist Absicht, kein Versteckspiel

NativeCSS nutzt bewusst auch Features, die noch nicht in JEDEM Browser Baseline sind (z.B. animation-timeline oder container-type: scroll-state). Das ist kein Widerspruch zu "kein Build-Schritt, kein JS" - es bedeutet nur, dass jedes dieser Features per @supports-Feature-Detection ODER einer kleinen, opt-in JS-Datei abgesichert ist, die sich SELBST abschaltet, sobald der Browser die native Technik ohnehin schon beherrscht.

CSS-Fallback per Feature-Detection

@supports prüft, ob eine Technik verfügbar ist, und liefert bei Bedarf eine einfachere, aber funktionale Alternative - z.B. animation-timeline: view() (Scroll-Reveal, gestapelte Karten): ohne Unterstützung erscheint der Inhalt einfach normal, ganz ohne Animation, kein Fehlerzustand. Genauso backdrop-filter (.ncss-glass) und initial-letter (Drop Caps, inkl. -webkit--Präfix für Safari).

Opt-in JS-Fallback, nur wenn nötig

Für die seltenen Fälle, wo CSS allein nicht reicht: eine winzige, eigenständige JS-Datei, NUR auf Seiten eingebunden, die sie brauchen. Sie prüft selbst per CSS.supports(...), ob die native Technik bereits greift, und tut in dem Fall schlicht nichts. Beispiel: hide-on-scroll-fallback.js für .ncss-hide-on-scroll (nativ nur in Chromium via container-type: scroll-state) oder command-fallback.js für command/commandfor.

Getestete Engines

Jede nicht-triviale Änderung wird während der Entwicklung in allen drei Rendering-Engines geprüft - Screenshot und berechnete Stile, nicht nur Doku-Annahmen:

Engine	Repräsentiert
Chromium	Chrome, Edge, Brave, Opera u.a.
WebKit	Safari (macOS/iOS)
Firefox	Firefox (Gecko)

Kein Ersatz für echte Geräte-Tests vor einem Produktiv-Einsatz, aber die drei Engines decken die überwiegende Mehrheit real genutzter Browser ab.

Selbst ausprobieren

Kein Signup, kein Build. Repo klonen, ncss.css einbinden, loslegen.

Repository auf GitHub Handbuch lesen

Natives CSS. Volle Kontrolle.

Was seit 2024/2025 in jedem aktuellen Browser steckt - und kaum genutzt wird

Cascade Layers

light-dark()

Container Queries

Natives HTML

Scroll-getriebene Animationen

Eine Quelle der Wahrheit

Cherry-Picking statt Alles-oder-nichts

Fünf Bausteine, die NativeCSS ausmachen

Design-Tokens & Theming

Cascade Layers

Scroll-getriebene Animationen

Web Awesome nur wo nötig

Barrierefreiheit eingebaut

Ein solides Grundgerüst - kein Wildwuchs

Tokens & Theming

Layout & Helfer

Komponenten

Scroll & Bewegung

Web-Awesome-Integration

Qualität

So sieht es in der Praxis aus

Karte + Button, automatisch dark-mode-fähig

Eigene Marke - theme.css

Gestapelte Karten (wie oben)

Modal - natives <dialog>

Wie ordnet sich NativeCSS ein?

Tailwind CSS vs. NativeCSS

UIkit 3 vs. NativeCSS

Nicht jedes Feature läuft überall gleich - das ist Absicht, kein Versteckspiel

CSS-Fallback per Feature-Detection

Opt-in JS-Fallback, nur wenn nötig

Getestete Engines

Selbst ausprobieren

Eigene Marke - `theme.css`

Modal - natives `<dialog>`