Erstellung eines schrittweise verbesserten mobilen Menüs, das ohne JavaScript funktioniert
Letzte Aktualisierung am 21. Januar 2019.
Reine CSS-Off-Canvas-Hamburger-Menüs sind keine neue Entdeckung. Schließlich hat Chris Coyier bereits im November 2012 über diese Technik geschrieben.
- Wenn das für Sie ein alter Trick ist, dann warten Sie noch ein bisschen mit mir. Ich habe das Beispiel von Chris verbessert und würde mich über Ihr Feedback freuen.
- Wenn das für Sie neu ist, machen Sie sich keine Sorgen. Sie haben viel Gesellschaft, da es scheint, dass ein Großteil des Webs noch nicht wirklich verstanden hat.
Damit werden wir ein einfaches, reaktionsfähiges Off-Canvas-Hamburger-Menü bauen, das nur CSS verwendet und leicht in Ihr eigenes Projekt zu integrieren ist. Aber zuerst…
Was ist falsch an JavaScript?
Nichts.
Aaron Gustafson erklärt die Bedeutung von Progressive Enhancements und die Rolle von JavaScript in der Webentwicklung besser als ich es je könnte. Sie sollten seinen Beitrag lesen. Aber der Kürze halber werde ich versuchen, es zusammenzufassen:
- „Kernaufgaben können immer ohne JavaScript erledigt werden.“
- Kernaufgaben sollten auf der stabilsten Schicht erledigt werden (d.h. nicht JavaScript).
- Progressive Erweiterungen sind nicht gegen JavaScript gerichtet. Es geht nur darum, die richtigen Technologien auf der richtigen Ebene einzusetzen.
- „Weil es eine gewisse Chance gibt, dass JavaScript nicht läuft, müssen wir diese Chance immer einkalkulieren.“
- Es ist nie eine gute Idee, potenzielle Benutzer zu ignorieren.
- Progressive Enhancements sind einfach gute Technik.
So, wir werden so viel wie möglich mit HTML und CSS machen. Dann lassen wir JavaScript auf einer geeigneteren Ebene zaubern, um die bereits vorhandene Benutzeroberfläche zu verbessern.
Schritt 1: HTML
Wie Sie vielleicht wissen, ist der erste Schritt immer das Schreiben einer soliden, gut durchdachten HTML-Basisschicht.
Anmerkung: Ich verwende Font Awesome für die Icons in meinem Beispiel.
Sieht ziemlich standardmäßig aus, oder? Wir haben:
- Unser übergeordnetes <header>-Element
- Das Hamburger-Symbol („fa-bars“)
- Eine Hauptüberschrift (oder möglicherweise ein Logo)
- Die Navigation in einem <nav>-Element
- Ein Schließsymbol („fa-close“) innerhalb der Navigation (mehr dazu später)
- Ein „Hintergrund“ nach der Navigation. Warum ist es ein Anker-Tag? Das erkläre ich später.
Schritt 2: Machen wir es zugänglicher
Zugänglichkeit sollte nie ein nachträglicher Gedanke sein – wie zum Beispiel, nachdem Sie Ihre Anwendung geschrieben haben. Sie sollte von Anfang an geplant werden. Wenn Sie jetzt ein paar grundlegende Überlegungen anstellen, wird sich nicht nur die allgemeine Zugänglichkeit Ihrer Website verbessern, sondern es wird Ihnen (dem Entwickler) auch ein besseres Markup zur Verfügung stehen, das Sie in Ihrem JavaScript verwenden können!
Damit fügen wir ein paar weitere Attribute und einen Text hinzu, der nur für Bildschirmleser geeignet ist:
Hier ist eine kurze Aufschlüsselung all dieser Attribute und wie sie funktionieren:
- Wir haben eindeutige IDs für unsere HREFs hinzugefügt (mehr darüber, wie das funktioniert, später).
- Wir haben eine informative Beschriftung der Schaltflächen für Bildschirmleser mit
- Wir haben die Symbole vor Bildschirmlesern mit ausgeblendet, da es sich um visuelle Darstellungen handelt, und mit den <span class=“sr-only“>-Elementen reinen Text für Bildschirmleser hinzugefügt.
- Wir haben den „Hintergrund“ aus dem Tabbing-Index herausgenommen mit einem . Er ist rein visuell und wir wollen unsere sehbehinderten und nur mit Tastatur arbeitenden Benutzer nicht verwirren.
- Wir haben das erstaunliche Attribut hinzugefügt, um den anfänglichen (und semantischen) Zustand des „Hintergrunds“ festzulegen. Kein Müll mehr – wie aufregend!
Hier ist das bisherige Ergebnis:
Schritt 3: Lasst es uns gestalten!
Wir gehen das Ganze von der mobilen Seite aus an, also lassen wir die mobile, „Hamburger-artige“ Ansicht (der interessante Teil) weg.
Zunächst werden wir nur das Layout der Kopfzeile richtig gestalten (ohne die Interaktivität):
Das Ergebnis:
Schritt 4: Interaktivität mit reinem CSS
Wenn Sie Widgets mit CSS interaktiv machen wollen, haben Sie mehrere Möglichkeiten:
- Verwenden Sie Radios oder Checkboxen
- Verwenden Sie die Pseudoklasse :target.
Radios und Checkboxen funktionieren erstaunlich gut für die meisten Widgets, wie Tabs, Modals, Dropdowns und Akkordeons. Chris Coyier nannte diese Technik „den Checkbox-Hack“. Mehrere Entwickler haben diesen „Hack“ für ihre Off-Canvas-Menüs verwendet, z. B. in Paul Lewis‘ Tutorial für den Chrome Dev Summit oder Luis Manuels Morphing-Hamburger-Menü.
Doch die Pseudoklasse :target ist in diesem Anwendungsfall semantischer, da es direkt um die Navigation geht. Sie mögen anderer Meinung sein, und das ist völlig in Ordnung! Es wäre unglaublich einfach und vollkommen akzeptabel, die :target-Pseudoklasse gegen ein Kontrollkästchen auszutauschen.
Beide Techniken haben jedoch ihre Tücken.
Die Verwendung einer Checkbox:
- Erfordert JavaScript, um das Off-Canvas-Menü zu schließen, wenn einer der Links innerhalb des Menüs ein Ankerlink zu einem bestimmten Abschnitt derselben Seite war.
- Erfordert, dass das <Eingabefeld> ein Geschwister des Menüs oder zumindest ein Geschwister des Vorgängers des Menüs ist. Mit anderen Worten, das CSS ist ein wenig komplizierter. Sie können das <Label> (sogar mehrere Labels) an anderer Stelle haben.
- Das <Label>-Element kann nicht direkt fokussiert oder mit einem Tabulator versehen werden, was etwas komplizierteres CSS für die Handhabung des Fokus auf dem Kontrollkästchen erfordert, während das sichtbare Erscheinungsbild des <Labels> geändert wird.
- Die Tastaturnavigation beim Öffnen/Schließen des Menüs wird nicht ganz einfach sein. Die Änderung des Zustands eines Kontrollkästchens erfolgt über die Taste, nicht über die Taste. Während blinde Benutzer verstehen können, dass das Widget durch ein Kontrollkästchen bedient wird, werden sehende Tastaturbenutzer verwirrt sein, da das Kontrollkästchen nicht sichtbar ist – etwas, das ich in diesem Anwendungsfall als hinderlich empfand.
Verwendung der Pseudoklasse :target:
- Fügt das Öffnen/Schließen des Off-Canvas-Menüs der Browser-Historie hinzu (und schiebt den Hash in die Adressleiste). Um dies zu vermeiden (und das potenziell lästige Springen an den Anfang der Seite), muss JavaScript Event.preventDefault() ausführen.
Und vielleicht gibt es noch andere Vorbehalte, die ich übersehen habe. In jedem Fall ist die Wahl der Technik eine Frage der Vorliebe und hängt von den Anforderungen Ihres Projekts ab. Wie auch immer, ich schweife ab…
Hier ist der interaktive Teil des CSS:
Das Ergebnis, wenn es angeklickt wird:
Wie das alles funktioniert
Im Wesentlichen gibt uns die Pseudoklasse :target einen neuen „Zustand“ für das Styling der gezielten Navigation. Wenn main-menu angewählt wurde (und die Raute zur URL hinzugefügt wurde), können wir das Menü ausblenden. Es ist ein bisschen wie eine :focus-Pseudoklasse für das Ziel-Element (nicht der Link selbst).
Wir haben auch erlaubt, dass der „Hintergrund“ angezeigt wird, wenn die Navigation anvisiert wird.
Sie werden feststellen, dass das Haupt-Hamburger-Symbol mit der ID der Navigation verbunden ist, während sowohl das Schließen-Symbol als auch die Hintergrund-Schaltflächen mit dem Haupt-Hamburger-Symbol verbunden sind. Dies ermöglicht es uns, auf das Schließen-Symbol oder den Hintergrund zu klicken, um den „Fokus“ – oder eigentlich :target – von der Navigation zu entfernen. Wäre der Hintergrund kein Link, wäre er ohne JavaScript nicht anklickbar.
Ich habe auch die :target-Selektoren mit dem Attribut im CSS verknüpft. Hier werden wir das Hamburger-Menü schrittweise mit JavaScript verbessern, damit es nicht zur Kopfzeile springt, wenn es angeklickt wird, und so die bereits erwähnte Einschränkung vermeiden. Wenn das JavaScript das Hash-Verhalten des Browsers übernimmt, wird die Pseudoklasse :target nicht mehr funktionieren. Wenn dies geschieht, werden wir das Attribut nutzen, um das Umschalten mit true/false-Werten zu gestalten, so wie wir es in der Vergangenheit mit Klassen getan haben.
In der Zwischenzeit funktioniert dies jedoch wunderbar ohne JavaScript.
Ich habe die @supports media query hinzugefügt, um die bevorzugte position:fixed CSS für Browser (sowohl mobile als auch Desktop) bereitzustellen, die sie unterstützen. Andernfalls erhalten lahme Browser und Geräte – ich schaue dich an, iOS – position:absolute.
Schritt 5: Stile für größere Bildschirme
Da wir nicht wollen, dass das Hamburger-Menü auf nicht-mobilen Geräten (oder größeren Bildschirmen im Allgemeinen) angezeigt wird, fügen wir die dafür erforderliche Media Query hinzu. Dann werden wir es so gestalten, dass es wie eine horizontale Navigation aussieht:
Das Ergebnis:
Voila! Wir sind fertig!
Alles zusammenfügen
Hier ist das endgültige HTML:
Hier ist das endgültige CSS:
Demo
Testen Sie meinen CodePen selbst:
→ Reines CSS Hamburger Menü ohne JavaScript.
Hinweis: Sie können auch die Checkbox-Version des Menüs ausprobieren.
Möchten Sie JavaScript hinzufügen, um das Menü eleganter zu gestalten?
Während wir das Off-Canvas-Menü vollständig mit CSS erstellen können – was seine Leistung und Zuverlässigkeit verbessert -, benötigen wir immer noch JavaScript, um die Interaktivität rund um die Nachteile der beiden Techniken zu verbessern. Sie können auch JavaScript verwenden, um das Scrollen auf der Seite zu verhindern, während das Menü geöffnet ist.
Es ist auch erwähnenswert, dass ein anständiges Niveau (und wohl das wichtigste Niveau) der Zugänglichkeit ohne JavaScript erreicht werden kann. Es ist jedoch schwierig, ein robustes Maß an Zugänglichkeit ohne die Fähigkeit von JavaScript, das DOM zu manipulieren (z. B. Fokusmanagement, ARIA-Attributaktualisierungen usw.), zu erreichen.
Weitere Informationen zur Verbesserung der Zugänglichkeit Ihrer Website durch JavaScript finden Sie in den folgenden Artikeln:
- Verwendung von ARIA-Attributen für die JavaScript-Zustandseinstellung &Styling
- Schreiben von JavaScript mit Blick auf die Zugänglichkeit
Haben Sie weitere Gedanken oder Vorschläge?
Ich würde mich freuen, Ihre Kommentare zu meinem Ansatz für ein reines CSS-Hamburger-Menü zu hören.
Bearbeitungen und spätere Überlegungen
21. Januar 2019: Artikel überarbeitet und Codebeispiele aktualisiert, um unnötige ARIA-Attribute zu entfernen und die Zugänglichkeit zu verbessern.
Während ich mehr über die Verwendung von ARIA und die Entwicklung von & Tests für Barrierefreiheit im Allgemeinen gelernt habe, sind mir einige Dinge klar geworden:
- JavaScript hat definitiv seinen Platz und sollte Teil jedes robusten UI-Musters für Barrierefreiheit sein.
- Abgesehen von ARIA-Landmarks ist JavaScript für die richtige Verwendung von ARIA erforderlich. Und viele der Attribute, die ich verwendet habe, sollten besser von JavaScript hinzugefügt werden, sobald sie geladen sind, anstatt sie direkt im Markup hinzuzufügen. Dieses Konzept folgt guten Praktiken des Progressive Enhancement – ARIA-Zustände und -Eigenschaften zusammen mit JavaScript sind ein Upgrade und sollten auf einer separaten Ebene gehandhabt werden.
- Zuvor habe ich den Fokus nicht richtig gehandhabt, da der Fokus verschwinden würde, wenn er sich durch die visuell verborgenen Links bewegt (wenn sie eingeklappt sind). Ich fügte ein display: none; zum Menü-CSS hinzu, um dies zu beheben.
Wenn Sie also eine frühere Version meines Pure CSS Off-Canvas Hamburger Menüs implementiert haben, ziehen Sie bitte in Betracht, es auf diese einfachere und zugänglichere Version zu aktualisieren!