Javascript-Problem

[Gunnar Bittersmann]

@@Friedel

Wenn du schon serverseitig die Unterscheidung triffst, warum lässt du dann nicht auch die Buttons per PHP generieren? Das würde die Sache wirklich sehr viel einfacher machen. Tatsächlich habe ich mehrfach erwogen, das zu machen. Aber das wäre ein fauler Kompromiss bzw. eine Notlösung. Mit Php generiere ich eine semantisch korrekte Seite. Sie enthält alle notwendigen Funktionen.

Die Grundlage für progressive enhancement. \o/

Diese Seite wird von Suchmaschinen, Blindenbrowsern, Textbrowsern, Screenreadern und Javasript-Verweigerern auch so gebraucht.

Da wirfst du ein bisschen viel in einen Topf. Bei Suchmaschinen, Blindenbrowsern, Textbrowsern, Screenreadern wird JavaScript durchaus ausgeführt. Und „das Problem sind nicht die Leute, die bewusst JavaScript in ihrem Browser deaktivieren. Wenngleich das auch beachtet werden sollte, das ist beileibe nicht die Hauptursache für JavaScript-Fehler.“ (wie Jeremy Keith sagte)

Mit Javascript ergänze ich noch einige Funktionen für mehr Komfort. Buttons, die nur in Komfort-Variante einen Zweck haben, sollten auch nur dort existieren.

Das ist völlig richtig. Du kannst das aber auch einfacher haben, indem du all diesen Buttons, die ohne JavaScript keine Funktion haben, im HTML ein disabled-Attribut mitgibst, welches du mit JavaScript entfernst.

Dann sind das zwar auch wenn JavaScript nicht ausgeführt wird button-Elemente, aber ich denke, das ist auch gut so. Es sollen ja Buttons sein – und das darf sich durchaus im HTML widerspiegeln.

Für den Nutzer verhalten sich <button disabled> ohne JavaScript nicht wie Buttons: sie sind keine interaktiven Elemente, sie sind nicht in der Tab-Reihenfolge bei Tastaturbedienung. Alles gut also.

Wenn du aber immer noch aufwendigere DOM-Umbauten in Erwägung ziehen solltest, dann würde ich den Inhalt der mit JavaScript zu generierenden Buttons in ein span (oder ein custom element wie x-button) tun und dieses dann komplett in den Button hängen. Beispiel.

Wenn’s auch in Uralt-Browsern funktionieren soll, implementierst du das eben mit function statt => und var statt let. Und wenn’s auch in Steinzeit-Browsern funktionieren soll, dann mit getElementsByClassName() und for-Schleife.

Außerdem möchte ich Sachen, die nur in manchen Browsern funktionieren, nach Möglichkeit nicht verwenden. Im Internet Explorer funktioniert das laut https://wiki.selfhtml.org/wiki/JavaScript/DOM/Element/classList erst ab Version 10.

Aber Steinzeit-Browser, echt jetzt? Ich darf dich an deine Worte erinnern: „Sie [die Seite] enthält alle notwendigen Funktionen.“ Die Seite funktioniert also auch in IE < 10. Der halbe Nutzer, der noch mit einem IE < 10 dagerkommt, hat dieselbe UX wie andere Nutzer, bei denen JavaScript nicht ausgeführt wird. So what?

Jedenfalls habe ich nicht vor, Workarrounds für die weit verbreiteten Browser ie7 bis ie10 zu bauen.

Sollst du auch nicht. Die Seite funktioniert ja. Nochmal Jeremry Keith: „Es ist ein verbreiteter Irrglaube, dass progressive enhancement heißt, seine Zeit in alte Browser zu stecken – das Gegenteil ist der Fall. Die Grundfunktionalität zu erstellen dauert nicht allzu lange. Wenn man das getan hat, kann man seine Zeit damit verbringen, mit den neusten und großartigsten Browsertechnologien zu experimentieren; sicher in dem Wissen, dass selbst wenn diese noch nicht weitgehend unterstützt werden, man den Fallback ja bereits hat.“

Auch das hidden-Attribut kenne ich nicht, aber laut https://developer.mozilla.org/de/docs/Web/HTML/Globale_Attribute/hidden funktioniert es erst ab IE11.

[hidden] { display: none !important } ins Stylesheet geschrieben – und schon funktioniert’s auch in IE < 11.

was daran [am hidden-Attribut] besser sein soll, als display:none;.

display ist eine Darstellungs-Angabe; hidden ist eine funktionale Angabe. Ob (nicht wie) etwas dargestellt werden soll, sollte durchaus im HTML/DOM stehen – als Attribut des betreffenden Elements.

Außerdem will man womöglich für nicht angezeigte Elemente den Platz freihalten. Kleiner Eintrag ins Stylesheet: [hidden] { display: block; visibility: hidden }.

Und außerdem will man sich nicht den Kopf zerbrechen, auf welchen Wert man display setzen muss, um ein verstecktes Element wieder anzuzeigen. Beispiel (unten).

Das aria-expanded-Attribut kannte ich bisher nicht. Und in selfhtml steht dazu auch wenig brauchbares. Die von dir verlinkte Seite habe ich gleich wieder zu gemacht. Wenn mich mein Pc-Lautsprecher ungefragt anbrüllt, nachdem ich eine Seite öffne, mache ich sie wieder zu und besuche sie nicht wieder.

?? Mich brüllt bei Menus & Menu Buttons nichts an.

Außerdem lerne ich neue Sachen sehr viel leichter, wenn ich sie auf Deutsch erklärt bekomme.

Es wäre sicher eine lohnende Aufgabe, die ganzen Artikel von Inclusive components ins Deutsche zu übersetzen.

Das ist auch Sinn der Sache. Es gibt 4 mögliche Zustände: kein class-Attribut, class="offen", class="zu" und class="hi". Beim Anklicken des Buttons bzw. Links soll folgendes passieren: Wenn es vorher class="zu" war, soll es danach class="offen" sein. In allen anderen Fällen soll es danach class="zu" sein.

Den Sinn habe ich nicht verstanden. class="hi" taucht im Weiteren nicht auf. Und für „offen“ und „zu“ sollte ein Flag reichen – eben das aria-expanded-Attribut. (Oder zusätzlich noch ein hidden-Attribut am betreffenden Element; das macht dann aber zusätzliche Arbeit.)

LLAP 🖖