Weitere Erklärungen und mehr über CSS-Tabs
Hier bei CSS-Tricks spielen wir seit Jahren mit der Idee von CSS-Tabs. Vor einem halben Jahrzehnt haben wir sieben verschiedene Techniken erforscht (alle ziemlich schlecht, verwenden Sie diese nicht). Wir haben sie vor vier Jahren erneut besucht und einige der Mängel dort behoben, aber einige neue Probleme eingeführt.
Heutzutage können Sie mit Techniken wie The Checkbox Hack mit nur HTML und CSS einer guten Tab-UI-Erfahrung viel näher kommen. Schauen Sie sich Arts Beitrag darüber an, wie das geht. Und seine abschließende Demo
Siehe den Pen Radio-Controlled Tabs (ARIA) von Art Lawry (@artlawry) auf CodePen.
Wie immer im Web gibt es immer neue Möglichkeiten zu erkunden. Ich glaube, die Jury ist sich noch nicht einig, ob Formularsteuerelemente für die Barrierefreiheit zur Umschaltung der Sichtbarkeit von Inhalten akzeptabel sind, wenn display: none verwendet wird, um diese Inhalte zu verbergen. Vielleicht könnten andere Verbergementen erforscht werden.
Stephan Barthel hat dieses Konzept mithilfe von Flexbox erforscht, was an sich ziemlich interessant ist.
Es gibt Gerüchte, dass CSS auch bei der Gestaltung beliebiger zustandsbasierter Designs hilft, sodass die Zukunft für diese Art von Dingen sicherlich interessant ist.
Erster!
Warum nicht css :target verwenden? Wäre das nicht schöner als die Verwendung von Checkboxen? =\
Das funktioniert sicherlich! Gleichzeitig kann es beim Klicken zu einigen seltsamen, unnötigen Sprüngen auf der Seite führen: https://css-tricks.de/functional-css-tabs-revisited/
@Geoff Graham
„unnötiges Springen auf der Seite beim Klicken“
Es kann vermieden werden
http://codepen.io/Kseso/pen/FlInH
Mehr Infos [es-es Blog]
http://ksesocss.blogspot.com/2012/10/tabs-rwd-target-sin-salto.html
Ja, ich sage definitiv nicht, dass es nicht funktioniert – es ist nur schön, nicht über diesen Nebeneffekt nachdenken zu müssen. :)
Ich bin immer begeistert, was CSS leisten kann, aber ich bin ein wenig besorgt darüber (mehr oder weniger).
JavaScript ist nicht böse, und ich denke, diese Art von Dingen hängt mit einem Zustand in unserer Anwendung zusammen und sollte zur besseren Verständlichkeit und Wartbarkeit in JavaScript verbleiben.
Aber ja, für eine sehr einfache Seite oder einen kleinen und nicht kritischen Teil unserer Webanwendung denke ich, dass dies wirklich leistungsstark, einfach zu machen und sehr sauber ist.
Aber das ist nur meine Meinung.
Mit Radio-Buttons und Checkboxen, die als Links gestylt sind, erwarten Tastaturbenutzer, dass das Drücken der Eingabetaste auf diesen Links die gewünschten Ergebnisse erzielt; wenn ich mich richtig erinnere, können Checkboxen und Radio-Buttons jedoch nur mit der Leertaste ausgewählt werden: eine weitere nicht so tolle Tatsache in Bezug auf diesen Ansatz.
Der Kommentar ist möglicherweise leicht ungenau, da ich die Unterschiede im Verhalten von Eingabeelementen und Anker-Elementen kürzlich nicht getestet habe.
@Irfan, indem Sie einen einzigen Event-Listener auf dem Container der Radio-Buttons hinzufügen, könnten Sie durch Drücken der Eingabetaste den Radio-Button auswählen, der den Fokus hat (Event-Bubbling ist eine schöne Sache).
Der letzte Tab (Dessert) hat einen fehlerhaften aktiven Zustand.
Verfluchte fehlende Punkte… danke und behoben.
Können Sie erklären, warum Sie verwenden müssen
und nicht einfach
Ich kann nicht sehen, wie das einen Unterschied macht?
Das ist der allgemeine Geschwisterselektor und er ist es, der diese Magie bewirkt.
Ihre Version besagt, dass wir das Element #breakfast-tab wollen, das sich in .tabs befindet, das sich in #breakfast befindet (und #breakfast hat den Fokus). Aber da #breakfast ein Radio-Input ist, können wir keine anderen Elemente darin platzieren.
Stattdessen sagen wir, wir wollen das #breakfast-tab, das sich in .tabs befindet, das ein *Geschwister* von #breakfast ist (und #breakfast hat den Fokus). Wir konnten unsere Tabs nicht in den Radio-Input einfügen, aber wir können sie danach platzieren. Dies ermöglicht es uns also, Dinge zu stylen, die nach einem Radio- (oder Checkbox-)Input basierend auf dessen Zustand kommen.
Hey, nett! Danke, dass du dich an mich erinnerst!
Nun macht mein Kommentar keinen Sinn mehr, aber ich wurde in der früheren Version dieses Artikels erwähnt. :-/
Das ist ziemlich cool! Danke fürs Teilen.
Ein paar Vorteile der Verwendung eines JavaScript-basierten Tab-Systems sind, dass, wenn man das richtige Skript verwendet, jeder Tab eine eigene URL hat, was sich wiederum gut für SEO und das Teilen von Inhalten eignet.
FWIW, jQuery UI Tabs haben das: https://jqueryui.com/tabs/
Standalone-Demo: https://jqueryui.com/resources/demos/tabs/default.html#tabs-2
Ich finde auch, dass eine Lösung wie diese, obwohl ziemlich clever, irgendwie „hacky“ ist. Die Verwendung von
inputundlabelfür Tabs fühlt sich für mich unsemantisch an :/Nun, hier sind ein paar Fragen für alle
1- Warum versuchen wir immer, JavaScript zu vermeiden?
2- Ist JavaScript SO schlecht? Selbst für eine Lösung wie diese?
3- Wäre JavaScript nicht so allgegenwärtig wie CSS, ja sogar wie HTML selbst?
—
Außerdem und im Sinne der richtigen Benennung, hier ein Vorschlag
Weißraum ist nicht von Natur aus schlecht, Weißraum ist tatsächlich eher das Gegenteil
1- Er gibt den Elementen im Layout Raum zum „Atmen“ und fühlt sich nicht eingeengt an.
2- Er verbessert die Inhalts-Hierarchie.
3- Er verbessert die Lesbarkeit.
Mehr dazu: https://boagworld.com/design/why-whitespace-matters/
Wie es ist, ist die Formulierung irreführend, weil sie *Weißraum* als etwas Schlechtes bezeichnet. Ich empfehle, den Begriff *Weißraum* durch einen der folgenden zu ersetzen: *unterer Abstand; ungenutzter Raum; leerer Raum;*
Nochmals vielen Dank!
Ich lasse das auch hier
http://codepen.io/Merri/pen/bytea/
Sollte die Probleme mit der Barrierefreiheit gelöst haben + hat die benutzerfreundliche Syntax, Tabs als eigenständige Blöcke zu definieren, anstatt sie in drei Teile aufzuteilen (zuerst die traditionellen Radios, dann Labels und dann die Panels).
Das Muster im Link enthält zusätzliches CSS und JS, um es in IE8, IE7 und IE6 zum Laufen zu bringen, in leicht zu entfernendem Format. Ohne JS beginnt die Unterstützung etwa ab dem Zeitalter von IE9, Opera Presto und Safari 5.
Und es wechselt im Mobilbereich in den Akkordion-Modus.
Vielen Dank für den großartigen Artikel!
Ich mag das wirklich – ausgezeichnete Arbeit – aber es funktionierte beim ersten Mal nicht für mich, bis ich einen Fehler im CSS des Haupttextes entdeckte
aktuell …
#breakfast:checked ~ tab-links #breakfast-tab,
#dinner:checked ~ tab-links #dinner-tab,
#dessert:checked ~ tab-links #dessert-tab
sollte sein …
#breakfast:checked ~ .tab-links #breakfast-tab,
#dinner:checked ~ .tab-links #dinner-tab,
#dessert:checked ~ .tab-links #dessert-tab
Eine Tab-Oberfläche ohne JS ist als Konzept gut und schön, aber warum ist Barrierefreiheit immer ein nachträglicher Gedanke?
Sie sollte in unseren Entwicklungsprozess integriert werden.
Wo ist die grundlegende Tastaturunterstützung?
Und wenn das behoben ist, haben Screenreader-Benutzer immer noch keine Chance, da die Inhalte mit „display:none;“ verborgen sind.
#NurGesagt
:)
Anerkennung für Geoff, der einen alten Artikel & Methode verfeinert hat, aber ich stimme @basher zu – dies sollte *niemals* als Best Practice betrachtet werden. Es ist tatsächlich ein „CSS-Trick“ – aber er schlägt die Tür für Sehbehinderte zu.
Dieser Artikel passt nicht zu CSS Tricks. Ich habe großen Respekt vor der Arbeit, die in diesen Artikel geflossen ist, und für diese Seite – und werde dies auch weiterhin tun –, aber ich finde diesen Artikel enttäuschend. Ich möchte lernen, wie ich das Web so gut wie möglich bauen kann – für jeden!
Ja, genau meine Gedanken. Das ist ein Spielzeug, vielleicht für schnelle Demos, aber sollte nicht in ernsthaften Projekten verwendet werden. Selbst wenn es nicht unzugänglich wäre, fühlt sich die Verwendung von Formularelementen allein für ihre interaktiven Eigenschaften falsch an. Schade, dass
<dl>s nicht bei allen Browsern gleich funktionieren; ich verwende diese am häufigsten für Q&A-ähnliche Umschalter. Die Verwendung der `:targeted`-Methode macht für Tabs viel mehr Sinn, und ich werde vielleicht mit @Ksesos Idee spielen, um das Springen zu verhindern. Ein Nachteil dabei ist, dass man beim Zurück- und Vorwärtsnavigieren durch mehrere Anker unerwartet auf einer Tab-Seite ist… wenn es doch nur einen guten No-JS-Weg gäbe, eine Seite zu verlassen und einfach zum letzten offenen Tab zurückzukehren, anstatt durch die gesamte Historie der Klicks zu gehen.Danke für das erneute Aufgreifen, Lebensretter.
Sie könnten max-height: 0 (mit overflow: hidden) anstelle von display: none verwenden.
http://codepen.io/anon/pen/JdXgEN
Pro
* Kann mit Übergängen gekoppelt werden, um zwischen Tabs zu animieren
Contra
* Erfordert eine explizite maximale Höhe für den offenen Zustand
* Es ist irgendwie ruckelig
Eigentlich, nach reiflicher Überlegung, vielleicht doch nicht…
Zwei weitere Nachteile
Das bloße visuelle Verbergen von Elementen auf diese Weise erlaubt es Screenreader-Benutzern immer noch, sie zu finden und mit ihnen zu interagieren.
Das Platzieren vieler Texte auf dem Bildschirm, die Benutzer nicht sehen können, ist eine Black-Hat-Taktik und kann sich negativ auf die SEO auswirken.
display: none; ist wichtig. :)
@James C: Wie kann es ein Nachteil sein, Screenreader-Benutzern die Interaktion mit Inhalten zu ermöglichen? Viele von ihnen können den Text ohnehin nicht visuell lesen, daher sehe ich nicht, wie es nützlich wäre, den Inhalt zwangsweise zu verbergen. Außerdem können Sie, wenn Sie müssen, JavaScript verwenden, um ARIA-Attribute zu aktualisieren, um Screenreadern mitzuteilen, dass der Inhalt visuell nicht sichtbar ist, was meiner Meinung nach ein besserer Weg ist.
Auch das SEO-Problem existiert nicht. Google hatte keine Probleme mit der Indexierung und hat keine Strafen verhängt, obwohl wir auf unserer Website eine CSS-Tab-Lösung ohne JavaScript verwenden. Unser Ranking hat sich tatsächlich verbessert, seit wir nicht-JavaScript-Tabs verwenden (natürlich wurden auch andere Verbesserungen vorgenommen).
Schließlich finde ich es eine ziemlich nette Funktion, dass Leute navigieren, auf alle Inhalte auf der Website zugreifen und Dinge kaufen können, obwohl sie JavaScript deaktiviert haben.
Und ich habe noch eine andere (8-Wege?) Methode, reine CSS-Tabs zu erstellen, ohne Radio-Buttons, Target oder den Focus-Selektor. Sie ist immer noch nicht perfekt wie bei aktivierten Radio-Buttons, aber es kann mit unendlicher Transition-Verzögerung gemacht werden, interessiert? :>
@basher, @kyle und @philtune: Ich gehe weiter auf den Stand der Barrierefreiheit für diese Technik im Link ein, der jetzt oben erwähnt wird. Es bringt Sie möglicherweise immer noch nicht an den Punkt, an dem Sie sich mit der Technik als „Best Practice“ wohlfühlen, aber es geht definitiv über den ursprünglichen Artikel hinaus, so wie er hier veröffentlicht wurde.
Ich spreche auch ein wenig über die Verwendung von Checkboxen/Radios zur Speicherung des Seitenstatus, was möglicherweise @philtunes Bedenken ausräumt (dann wiederum stelle ich fest, dass die Leute auf einer Seite der Linie stark herunterfallen).
Insgesamt bin ich sehr froh, dass die Leute die Stärken und Schwächen dieser Technik erforschen. Hoffentlich werden andere sie weiter verfeinern und herausfordern, damit eine stärkere Lösung entsteht.