Toolbar: Adaptivity

Zurück: Demo-Übersicht

Wie sich eine Werkzeugleiste bei wenig Platz verhält: Einträge, die nicht mehr nebeneinander passen, wandern hinter einen Knopf „Weitere Aktionen“ und bleiben von dort aus erreichbar.

Status: [Live]. Referenz: ActionBar/ToolBar-Zeile im Widget-Katalog. Der Zustand „responsive-overflow“ des Vokabulars ist als Opt-in umgesetzt ('overflow' => true plus scripts/toolbar.js); ohne die Angabe bricht die Leiste um, statt zu falten.

Beispiel Befehlsleiste des Tresors: bei 1400 px stehen fünf Bedienelemente nebeneinander und es gibt keinen Überlaufknopf; bei 390 px tragen beide Gruppen hidden, sichtbar bleibt ein Knopf, und „Weitere Aktionen“ führt die übrigen.

Toolbar-Basiskontrakt bereits verstanden.

Dasselbe Overflow-Prinzip wie bei Tab Control → Adaptivity, hier auf Toolbar-Items statt Tab-Köpfe angewendet.

echo $widgets->toolbar($items, ['ariaLabel' => 'Aktionen', 'overflow' => true]);

Relevant für Toolbars mit vielen Items in schmalen Panels. Opt-in über $opts['overflow'] – bestehende Toolbars (z. B. die Bulkbar) behalten bewusst ihr Umbruchverhalten.

Unterhalb verfügbarer Breite (ResizeObserver, scripts/toolbar.js) verschwinden die am weitesten rechts stehenden Items hinter einem „Weitere Aktionen“-Button (.wk-toolbar__more), der ein Menü im Kontextmenü-Look öffnet (role=„menu“/menuitem); ein Menü-Eintrag klickt das echte, versteckte Element – ein Code-Pfad.

No-JS-Fallback: alle Items bleiben sichtbar und brechen um (flex-wrap), kein Overflow-Menü ohne JavaScript.

Siehe Abschnitt 4.

• Selects/Inputs im Overflow-Menü werden als klickende Einträge gelistet – für komplexe Controls das Overflow-Verhalten nicht aktivieren.

Das „Weitere Aktionen“-Menü muss tastaturbedienbar sein – dasselbe Muster wie das bestehende Kontextmenü.

Entfällt.

• Demo-Übersicht – alle Kategorien
• Tab Control: Adaptivity – identisches Overflow-Prinzip