Von UIkit3 nach ncss

ncss ist bewusst KEIN Klassen-Shim für UIkit3 (siehe Begründung unten) - stattdessen diese Übersicht, um typische UIkit3-Layouts von Hand nach ncss zu übertragen. Für die Kombination beider Systeme auf DERSELBEN Seite (statt einer vollständigen Migration) siehe stattdessen <ncss-container> in UIkit3 - dort läuft ncss isoliert im Shadow DOM neben bestehendem UIkit3-Markup, ohne dass beide Systeme sich gegenseitig stören.

Warum kein 1:1-Klassen-Shim

Ein Shim, der z.B. .uk-button optisch wie .ncss-btn aussehen lässt, wäre für rein optische/statische Klassen (Grid, Card, Button, Text-Utilities) machbar. Zwei strukturelle Gründe sprechen dagegen, es als vollständiges System auszuliefern:

JS-gebundene Komponenten. Off-Canvas, Modal, Accordion, Tab, Slider, Sticky, Scrollspy laufen bei UIkit3 über attributgesteuertes eigenes JS (uk-toggle, uk-offcanvas, uk-modal, ...). Eine reine CSS-Klasse kann dieses Verhalten nicht nachbilden - ncss nutzt dafür native <dialog>/<details> mit einer GRUNDSÄTZLICH anderen Markup-Struktur (siehe unten), kein 1:1-Ersatz per Klassenname möglich.
Breakpoint-Suffix-System. UIkit3s klasse@s/@m/@l/@xl-Raster widerspricht ncss' eigenem Grundprinzip "kein klasse@breakpoint-Raster" - ncss setzt stattdessen auf intrinsisches Grid (.ncss-grid, auto-fit) bzw. Container Queries. Ein Shim dafür würde ncss' eigene Architektur unterlaufen.

Container & Grid

UIkit3s uk-grid ist ein Attribut mit fester Spaltenbreite pro Kind (uk-width-1-2) oder gleichmäßig verteilt (uk-child-width-1-3), meist zusätzlich mit einem Breakpoint-Suffix kombiniert (uk-child-width-1-2@s uk-child-width-1-3@m). .ncss-grid braucht dafür KEINEN Breakpoint-Suffix - auto-fit/minmax() übernimmt die Umbruch-Entscheidung selbst, je nach verfügbarem Platz.

UIkit3

<div class="uk-child-width-1-2@s uk-child-width-1-3@m" uk-grid>
  <div>
    <div class="uk-card uk-card-default uk-card-body">Item</div>
  </div>
  ...
</div>

ncss

<div class="ncss-grid" style="--ncss-grid-min: 16rem;">
  <div class="ncss-card ncss-border ncss-radius-md">
    <div class="ncss-card-body">Item</div>
  </div>
  ...
</div>

Eine WIRKLICH feste Spaltenzahl (kein intrinsisches Umbrechen): .ncss-grid--cols-2/-3/-4/-6 (braucht einen Vorfahren mit .ncss-container, siehe Layout). Eine unvollständige letzte Zeile ZENTRIERT statt linksbündig: .ncss-flex-grid + .ncss-width-1-2/-1-3/... (Details: Layout). uk-container → .ncss-container (.ncss-container--narrow für UIkit3s uk-container-small-Äquivalent).

Card & Button

UIkit3

<div class="uk-card uk-card-default">
  <div class="uk-card-body">
    <h3 class="uk-card-title">Titel</h3>
    <p>Text</p>
  </div>
</div>
<button class="uk-button uk-button-primary">Absenden</button>

ncss

<div class="ncss-card ncss-border ncss-radius-md ncss-shadow-sm">
  <div class="ncss-card-body">
    <h3>Titel</h3>
    <p>Text</p>
  </div>
</div>
<button class="ncss-btn ncss-btn--primary">Absenden</button>

Rahmen/Ecken/Schatten sind bei .ncss-card bewusst NICHT im Default enthalten (anders als uk-card-default) - eigene, frei kombinierbare Utilities aus helpers/elevation.css, siehe Karten. uk-button-secondary/-danger → .ncss-btn--secondary/--danger.

Navbar

UIkit3

<nav class="uk-navbar-container" uk-navbar>
  <div class="uk-navbar-left">
    <ul class="uk-navbar-nav">
      <li class="uk-active"><a href="#">Start</a></li>
      <li><a href="#">Über uns</a></li>
    </ul>
  </div>
</nav>

ncss

<nav class="ncss-nav">
  <ul class="ncss-nav-list">
    <li class="ncss-nav-item"><a href="#" aria-current="page">Start</a></li>
    <li class="ncss-nav-item"><a href="#">Über uns</a></li>
  </ul>
</nav>

uk-active hat keine direkte Entsprechung als Klasse - ncss nutzt das semantische aria-current="page"-Attribut statt einer optischen Marker-Klasse (wird von nav.css selbst gestylt). Eine uk-navbar-container mit eigenem Logo/Actions-Bereich → .ncss-topbar (-inner/-brand/-actions), siehe Komponenten-Referenz. Viele Navigationspunkte, die nicht mehr in eine Zeile passen: <ncss-nav-priority> statt UIkit3s uk-navbar-toggle-icon+Dropdown-Handrolling, siehe Priority-Navigation.

Off-Canvas & Modal

Der größte strukturelle Unterschied: UIkit3 aktiviert Off-Canvas/Modal über ein uk-offcanvas/uk-modal-ATTRIBUT + UIkit3s eigenes JS, das per uk-toggle="target: #id" angesteuert wird. ncss nutzt dafür das native <dialog>-Element - showModal()/close() kommen direkt vom Browser, kein Komponenten-JS nötig. Öffnen/Schließen läuft über das native command/commandfor-Attributpaar (Baseline in aktuellen Browsern, js/command-fallback.js als Opt-in-Polyfill für ältere).

UIkit3 (Off-Canvas)

<a href="#panel" uk-toggle>Menü</a>
<div id="panel" uk-offcanvas>
  <div class="uk-offcanvas-bar">
    <button class="uk-offcanvas-close" uk-close></button>
    ...
  </div>
</div>

ncss (natives Dialog)

<button command="show-modal" commandfor="panel">Menü</button>
<dialog id="panel" class="ncss-offcanvas ncss-offcanvas--start">
  <button class="ncss-dialog-close" command="close" commandfor="panel">&times;</button>
  ...
</dialog>

Modal genauso: uk-modal/uk-modal-dialog/-header/-body/-footer/-close-default → <dialog class="ncss-modal">/.ncss-modal-header/-body/-footer/.ncss-dialog-close. Details inkl. Einblendvarianten (--slide-up u.a.): Komponenten-Referenz.

Accordion & Tab

UIkit3

<ul uk-accordion>
  <li>
    <a class="uk-accordion-title" href>Frage</a>
    <div class="uk-accordion-content">Antwort</div>
  </li>
</ul>

ncss

<details class="ncss-disclosure">
  <summary>Frage</summary>
  <p>Antwort</p>
</details>

Natives <details>/<summary> statt UIkit3s JS-Komponente - kein uk-accordion-Init nötig, funktioniert ohne JS. Für "nur eins gleichzeitig offen" (UIkit3s multiple: false-Option): <details name="gruppe"> (natives Attribut, schließt Geschwister automatisch). uk-tab hat KEINE direkte 1:1-Entsprechung als reine CSS/HTML-Komponente - je nach Bedarf entweder dieselbe <details name="...">-Gruppe (wirkt wie Tabs, wenn horizontal per .ncss-nav--scroll angeordnet) oder Web Awesomes <wa-tab-group> (siehe Web Awesome Bridge), falls echtes ARIA-Tab-Verhalten gebraucht wird.

Text- & Abstands-Utilities

UIkit3	ncss
`uk-text-center`/`-left`/`-right`	`.ncss-text-center`/`-start`/`-end`
`uk-text-muted`	`.ncss-text-muted`
`uk-text-lead`	`.ncss-text-lead`
`uk-text-small`	`.ncss-text-sm`
`uk-margin`/`uk-margin-small-top` usw.	`.ncss-mb-md`/`-sm`/`-lg`/`-xl` (`margin-block-end`, logische statt physischer Richtung)
`uk-grid-small`/`-medium` (Grid-Abstand)	`.ncss-gap-sm`/`-md`/`-lg`/`-xl`
`uk-flex`/`uk-flex-middle`/`-between`	`.ncss-cluster` (horizontal, umbrechend) oder `.ncss-flex`/`--center`/`--between`, siehe Layout
`uk-hidden`	`.ncss-hidden`
`uk-visible@m`/`uk-hidden@s`	`.ncss-hide-below-md`/`-from-md` (Viewport) - siehe Hinweis unten zu Breakpoints

Bei den Sichtbarkeits-Utilities der größte Denkweise-Unterschied: UIkit3s @s/@m/@l/@xl-Suffixe erlauben BELIEBIGE Kombinationen (uk-hidden@s uk-hidden@m), ncss bietet dafür bewusst nur die feste -below/-from-Zweiteilung pro Schwelle (sm/md/lg/xl) - für die meisten Layouts reicht das, für ein wirklich exotisches Breakpoint-Muster bleibt eine eigene, unlayered Regel in der eigenen Theme-Datei die richtige Lösung (siehe Einzelne Komponenten anpassen), statt ein ganzes zusätzliches Utility-Raster anzulegen.