toggle Menü Katastrophe

[Jörg Reinholz]

Moin!

Darüber streiten die Gelehrten.

Gelegenheit für Glaubenskriege.

Die wenigsten heutzutage kennen Low-Level-DOM-Grundlagen, und das halte ich auch nicht für schlimm.

Art 5 GG: Die Meinung ist frei. Ich habe dazu eine andere.

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

Naja. Sollte nicht der Plan am Anfang stehen? Die Bibel (Johannes 1) ist da falsch übersetzt, da steht in der deutschen Fassung "Im Anfang war das Wort". Ich denke, die frühen Übersetzer hatten das Wort "Plan" noch nicht zur Verfügung. Sieht man auch daran, dass behauptet wird "das Wort ward Fleisch" - zweifelsfrei meinten die tatsächlich, der Plan wurde umgesetzt.

Es hat schon seine Gründe, warum die show-, hide- und toggle-Methoden von jQuery ziemliche Monster sind.

Hier arbeitest du mit Klassen, warum beim Togglen hingegen mit Inline-Styles.

Auch in nativem JS korrigierbar. Feeilich wäre es eine gute Idee hier mit Klassen und/oder Selektoren zu operieren.

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.

Ich bin hier nach wie vor anderer Meinung. Ich behalte gern die Kontrolle und ich kenne eine Menge negativer Beispiele die deshalb so besch... funktionieren, weil der Ersteller weder Ahnung von JS noch von jQuery hat, letzteres aber verwendet.

Die Inhalte bleiben in diesem Fall für immer unsichtbar.

Korrigierbar.

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.

Korrigierbar.

Das kann gewünscht sein, hat aber nichts mit einem generischen Ein- und Ausblenden auf Knopfdruck zu tun.

Ich denke, wir wissen beide, dass Frage und eigentliches Problem oft nicht ganz übereinstimmen. Es ist eine Erweiterung in eine vermutete Richtung.

Hinzu kommt, dass mit einem festen height-Wert gearbeitet werden muss, damit die Transition funktioniert.

Jaja. Die hatte mit dem Problem nichts zu tun, mein Beispiel war aus einem Experiment rauskopiert.

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

Korrigierbar. <! if [gt IE 8] > (oder so...)

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.

Wie? Das Verkleinern auf einen Punkt ist komplizierter? Gibts für Screenreader nicht etwas wie @medium aural { ... } im stylesheet?

Was ich damit sagen will: Es hat schon seine Gründe, warum Bibliotheken wie jQuery verwendet werden.

Ich habe KEIN Problem damit, wenn Bibliotheken wie jQuery verwendet werden - aus einer anderen Äußerung von Dir entnehme ich, dass Du das vermutest und dass Du Dich darüber ärgerst. Ich vertrete aber die Meinung, dass triviale Probleme auch trivial gelöst werden sollten. Ich baue doch keine Autofabrik wenn ich nur den Rückspiegel einstellen will. Will ich aber eine Webseite bauen, die browserseitig entsprechenden Aufwand erfordert, dann habe ich kein Problem auf passende Bibliotheken zurück zu greifen.

Nur mache ich eher auf "serveseitige Logik".

[Bibliotheken wie jQuery] setzen verschiedene Best Practices um.

Wobei "Best Practices" wieder eine Frage der Definition ist. Die Definition ist übrigens auch zeitabhängig.

So long.

Jörg Reinholz