molily: toggle Menü Katastrophe

Beitrag lesen

Hallo!

Richtige Reihenfolge beim Lernen:

Darüber streiten die Gelehrten. Die wenigsten heutzutage kennen Low-Level-DOM-Grundlagen, und das halte ich auch nicht für schlimm. Bei deren Anwendung kann man nämlich weitaus mehr falsch machen als bei der Anwendung von jQuery und Co.

function toggleDisplay(element) {
    object=document.getElementById(element);
    if (object.style.display=='block') {
object.style.display='none';
    } else {
object.style.display='block';
    }
  }

Wenn man so etwas in reinem JavaScript schreibt, braucht man eine Menge an Wissen und muss viele Annahmen machen, um einfachen Code zu schreiben:

Es muss sich hier um Blockelemente handeln. Wenn das Element standardmäßig sichtbar ist, muss es den Inline-Style style="display: block" haben, sonst ergibt .style.display == 'block' nämlich false. Das Auslesen von CSS-Eigenschaften geht anders. Diese Funktion eignet sich also nicht zum beliebigen Togglen, sondern zum Einblenden und *anschließenden* Ausblenden.

Es hat schon seine Gründe, warum die show-, hide- und toggle-Methoden von jQuery ziemliche Monster sind. Über die Einschränkungen und Fallstricke beim Zeigen und Verstecken von Elementen könnte man einen ganzen Aufsatz schreiben.

<style>
  .unsichtbar
  {
  display: none;
  }
  .sichtbar
  {
  display: block;
  }
      </style>

Hier arbeitest du mit Klassen, warum beim Togglen hingegen mit Inline-Styles. Vieles spricht dafür, Styles wenn möglich konsequent per Stylesheet zu setzen und nur Klassen oder andere Flags zu ändern, die dafür sorgen, dass andere Stylesheet-Regeln angewandt werden.

<p><a href="javascript:toggleDisplay('switch')">(Nicht) Anzeigen</a></p>

Das ist ein Rückschritt gegenüber dem Workflow mit jQuery. <a href="javascript:…"> sollte man nicht verwenden, sondern HTML und JavaScript sauber trennen – Stichwort Unobtrusive JavaScript – und Event-Handler im JavaScript registrieren. Dabei hilft einem jQuery hervorragend.

Einige würden noch einwenden, dass das kein echter Hyperkink ist, wenn das href-Attribut nicht sinnvoll gefüllt ist und nur JavaScript-Event-Handler existieren. Das sehe ich nicht so streng, aber es wirft die wichtige Frage auf, was passiert, wenn JavaScript nicht verfügbar ist: Die Inhalte bleiben in diesem Fall für immer unsichtbar.

  1. Dies hier tut auch in etwa was Du willst, geht aber sogar ganz ohne Javascript:

.sitepart {
   display:none;
   height:0;
   overflow:hidden;
   transition: height 1s;

}
.sitepart:target {
    display:block;
    height:300px;
}

Das ist elegant, geht aber wieder von einigen Vorannahmen aus. Es ist eine Lösung für einen sehr speziellen Fall: Das Element ist nur sichtbar, wenn gerade der Anker in der URL darauf zeigt. Es wird nicht dauerhaft eingeblendet. Aktiviert der Nutzer einen anderen Anker, so verschwindet das Element wieder. Das kann gewünscht sein, hat aber nichts mit einem generischen Ein- und Ausblenden auf Knopfdruck zu tun.

Hinzu kommt, dass mit einem festen height-Wert gearbeitet werden muss, damit die Transition funktioniert. Das heißt, wenn sich der Inhalt ändert, muss auch das CSS angepasst werden, sonst wird der Inhalt u.U. abgeschnitten. Das würde ich als Albtraum für die Wartbarkeit bezeichnen.

Ferner funktioniert :target nicht in IE < 9 funktioniert. In diesen Browsern ist der Inhalt komplett unzugänglich.

Schließlich lässt sich anmerken, dass display: none Inhalte in einer Weise versteckt, sodass sie für Screenreader unzugänglich sind. Nutzt man eine zugängliche Methode, wird eine Animation gleich viel komplizierter.

Was ich damit sagen will: Es hat schon seine Gründe, warum Bibliotheken wie jQuery verwendet werden. Sie lösen nicht alle Probleme und man muss immer noch selbst gewisse Fälle abdecken, aber sie vereinfachen vieles und setzen verschiedene Best Practices um. »Das geht auch einfach mit ein paar Zeilen CSS« ist zwar korrekt, verschweigt aber die Einschränkungen und Vorannahmen dieser vermeintlich einfachen Lösungen.

Grüße,
Mathias