display:none wird zurückgesetzt durch history.back() in Chrome
Kunst-eyids
- css
- javascript
- php
Ich blende ein Menu (<nav id="navID>) durch click-Event auf einem A-Tag mit Bild ein oder aus. Wenn ich den Zurück-Button benutze - oder history.back() - bleibt das Menu im Chrome immer geöffnet.
Im Firefox funktioniert alles korrekt. Beim Safari flackert das Menü kurzfristig auf und ist dann nicht mehr sichtbar.
@@Kunst-eyids
Ich blende ein Menu (<nav id="navID>) durch click-Event auf einem A-Tag mit Bild ein oder aus.
<a id="hamburgerLink">
ist dafür falsch. Ein a
-Element ohne href
-Attribut ist kaum mehr als ein span
– es ist kein interaktives Element; es ist per Tastatur nicht bedienbar.
Aber auch mit href
-Attribut wäre ein a
-Element falsch. Für Interaktionen auf einer Seite ist das button
-Element zu verwenden. Den Button kannst du mit CSS so stylen, dass er keinen Rahmen einen transparenten Rahmen[1] und transparenten Hintergrund hat.
Und der Button muss unbedingt mit ins nav
-Element rein! (Sonst finden ihn Screenreader-Nutzer schlecht.) Das heißt dann, du blendest dann nicht das nav
-Element ein/aus, sondern das ul
-Element darin.
Zu deinem JavaScript: Das sollte nicht nur das Menü ein- und ausblenden, sondern den Zustand ein- bzw. ausgeblendet auch am Button anzeigen: aria-expanded="false"
bzw. "true"
. Screenreader sagen das dann an. Außerdem könntest du das auch nutzen, um bei geöffnetem Menü das Hamburger-Icon durch ein Kreuz × zu ersetzen.
function menuEinAus(){ document.getElementById("navID").style.display=(document.getElementById("navID").style.display=="block"?"none":"block"); }
Es macht auch wenig Sinn, das Element „navID“ bei jedem Auf- und Zuklappen erneut im DOM zu suchen. Das sollte einmalig nach dem Laden der Seite geschehen (also außerhalb der Funktion menuEinAus()
) und in einer Variablen gespeichert werden.
Brauchst du aber auch gar nicht, wenn du wie oben gesagt aria-expanded
verwendest. Dann kast du das dem Button folgende ul
-Element per CSS ein- und ausblenden:
[aria-expanded="false"] + ul {
display: none;
}
Eine weitere Möglichkeit wäre das Ändern des hidden
-Attributs - wie in diesem Beispiel. Es ist sowieso i.a.R. keine gute Idee, CSS-Eigenschaften direkt mit JavaScript zu ändern.
Was bei dir auch nicht stimmt, sind die Hierarchie-Ebenen der Überschriften. Nach h1
muss h2
kommen, nicht h6
. (Auch wichtig für Screenreader-Nutzer.) Die Schriftgrößen gibst du per CSS an.
Wenn ich den Zurück-Button benutze - oder history.back() - bleibt das Menu im Chrome immer geöffnet.
Zu den Eigenarten der Browser beim Zurückgehen kann ich wenig beitragen.
🖖 Живіть довго і процвітайте
Rahmen von Buttons nicht entfernen wegen forced-colors mode. Siehe Tweet, Artikel Windows High Contrast Mode, Forced Colors Mode And CSS Custom Properties von Eric Bailey und Vortrag Practical Styling in Forced Colors Mode von Mike Herchel ↩︎
Herzlichen Dank, das werde ich jetzt mal umsetzen. Die Sache mit den H1 usw. habe ich im Blick. Kommt aber später.
Ich blende ein Menu (<nav id="navID>) durch click-Event auf einem A-Tag mit Bild ein oder aus. Wenn ich den Zurück-Button benutze - oder history.back() - bleibt das Menu im Chrome immer geöffnet.
Du kannst ja mal versuchen, ob ein
history.replaceState( null, null, window.location.pathname );
unmittelbar nach dem Ändern der Anzeige dem abhilft. Möglicherweise willst Du das nur machen, wenn (nach dem) das Menü ausgeblendet wurde. Aber die nicht ganz sach- und fachgerechte Verwendung des Links statt eines Buttons könnte tatsächlich die Ursache dafür sein, dass mancher Browser über die history bzw. die Aufnahme eines Status in die selbe anders denkt als andere:
Der eine Browser denkt offenbar: „O.k.: <a>
ausgelöst → Status in History aufnehmen“, der andere aber: „Nope: Kein href
, keine neue Seite geholt → nicht in History aufnehmen.“
@@Raketenwilli
Aber die nicht ganz sach- und fachgerechte Verwendung des Links statt eines Buttons
„Nicht ganz sach- und fachgerecht“? Die Untertreibung des Jahrhunderts!
… könnte tatsächlich die Ursache dafür sein …
Nö. Auch bei sach- und fachgerechter Verwendung eines Buttons zeigt Chrome dieses Verhalten: Testseite. It’s a feature, not a bug?
Was man vielleicht machen könnte: Bei beforeunload
das Menü ausblenden. Testseite mit.
🖖 Живіть довго і процвітайте
Hallo Gunnar,
Was man vielleicht machen könnte: Bei
beforeunload
das Menü ausblenden. Testseite mit.
könnte man natürlich - aber wozu? Wenn ich die Seite verlassen will, ist es mir egal, in welchem Zustand ich sie verlasse.
Und wenn beforeunload auch beim Zurückverfolgen von seiteninternen Links feuert, dann würde ich das für einen Implementierungsfehler halten. Denn dabei verlasse ich die Seite nicht, es kommt also nicht zu einem unload.
Sage ich als jemand, der die Zurück-Navigation ohnehin fast nie benutzt.
Einen schönen Tag noch
Martin
@@Der Martin
Und wenn beforeunload auch beim Zurückverfolgen von seiteninternen Links feuert
Ich glaube, hier hast du einen Denkfehler.
Ich bin auf der home page, clicke auf den Link zu far far away. Die Seite wird also verlassen, beforeunload
feuert und schließt das Menü auf der alten Seite.
Dann bin ich far far away, drücke den Zurück-Button, um wieder nach home zu kommen. Ich finde die Seite so vor, wie ich sie verlassen habe: mit geschlossenem Menü.
🖖 Живіть довго і процвітайте
Hi,
Und wenn beforeunload auch beim Zurückverfolgen von seiteninternen Links feuert
Ich glaube, hier hast du einen Denkfehler.
gut erkannt. 😉
Ich bin auf der home page, clicke auf den Link zu far far away. Die Seite wird also verlassen,
beforeunload
feuert und schließt das Menü auf der alten Seite.Dann bin ich far far away, drücke den Zurück-Button, um wieder nach home zu kommen. Ich finde die Seite so vor, wie ich sie verlassen habe: mit geschlossenem Menü.
Ja, dass es sich um ein Zwei-Schritt-Problem handelt, hatte ich so tatsächlich nicht verstanden.
Aber: Möchte man[1] eine Seite, wenn man zu ihr zurückkehrt, nicht so vorfinden, wie man sie verlassen hat? Hat man sie also mit geöffnetem Menü verlassen, möchte man sie doch auch genau so wieder antreffen.
Einen schönen Tag noch
Martin
Ich nicht. Ich möchte, wenn ich die Zurück-Funktion schon mal nutze, dass die Seite, zu der ich zurückkehre, komplett neu geladen wird. ↩︎
@@Gunnar Bittersmann
… zu far far away.
Wer weiß noch, wo der Name herkommt?
🖖 Живіть довго і процвітайте
Hallo,
… zu far far away.
Wer weiß noch, wo der Name herkommt?
ich kenne ihn aus Shrek (zweite Folge, AFAIR).
Einen schönen Tag noch
Martin
@@Der Martin
… zu far far away.
Wer weiß noch, wo der Name herkommt?
ich kenne ihn aus Shrek (zweite Folge, AFAIR).
Genau das meinte ich.
Das hier hätte ich auch gelten lassen müssen?
🖖 Живіть довго і процвітайте
n'Abend,
… zu far far away.
ich kenne ihn aus Shrek (zweite Folge, AFAIR).
Genau das meinte ich.
na also. Zwei Dumme, ein Gedanke.
Das hier hätte ich auch gelten lassen müssen?
Vermutlich ja. Sagt mir aber nichts.
Einen schönen Tag noch
Martin
@@Der Martin
Das hier hätte ich auch gelten lassen müssen?
Vermutlich ja. Sagt mir aber nichts.
Ich bin ja damals auch(?) mit ABBA aufgewachsen, hab aber auch das ein oder andere Lied von anderen aus der Zeit im Ohr.
🖖 Живіть довго і процвітайте
Hallo,
Das hier hätte ich auch gelten lassen müssen?
Vermutlich ja. Sagt mir aber nichts.
Ich bin ja damals auch(?) mit ABBA aufgewachsen, hab aber auch das ein oder andere Lied von anderen aus der Zeit im Ohr.
ich auch. Chris de Burgh, Jean-Michel Jarre, Jennifer Rush, Fleetwood Mac, Sandra. Später auch a-ha, Roxette, ein bisschen Queen, Mike Oldfield, Sally Oldfield, Enya, Midnight Oil, Erasure.
Kim Wilde hätt' ich fast vergessen.
Aber Far Far Away von ... was war's nochmal, Sable? Nee, Slade. Nie gehört.
Einen schönen Tag noch
Martin
@@Der Martin
Slade. Nie gehört.
🖖 Живіть довго і процвітайте
Hallo Gunnar,
Slade. Nie gehört.
da meldet sich tatsächlich eine Stimme tief aus dem Unterbewusstsein:
Das habe ich schonmal gehört.
Hat aber wohl keinen nachhaltigen Eindruck hinterlassen.
Einen schönen Tag noch
Martin
Hallo,
Aber Far Far Away von ... was war's nochmal, Sable? Nee, Slade. Nie gehört.
das passt auch eher zu meiner Generation. Wie Pink Floyd oder Uriah Heep.
Gruß
Jürgen
@@Gunnar Bittersmann
Testseite. It’s a feature, not a bug?
Wo wir gerade dabei sind: bei der Gelegenheit gleich noch einen Bug gemeldet.
Dazu sind Feature-Flags ja da: dass Entwickler neue Features testen können, aber nicht produktiv verwenden.
🖖 Живіть довго і процвітайте
Ja, das interessant, dass der Chrome das Verhalten auch beim Button zeigt.
Danke, Gunnar, für die Testseite. Ich habe mich für die Lösung ohne beforeunload entschieden. Es ist vielleicht gar nicht so schlecht, wenn das Menü offen bleibt. So oft wird der Back-Button ja nicht genutzt. Und durch die Breadcrumbs hat man ja auch noch eine Orientierung.
Gruß Irmin
@@Kunst-eyids
Das Entwicklertool offenbart noch einen weiteren Fehler:
Du bindest das Menü anscheinend serverseitig in deine Seite ein, und das Include fängt mit einem BOM (U+FEFF) an und damit gelangt das Zeichen mitten in deinen HTML-Quelltext. Das Zeichen U+FEFF sollte aber nur (wenn überhaupt) ganz am Anfang einer Ressource stehen.
Für UTF-8 brauchst du kein BOM. Speichere dein Include (und alle anderen Dateien) in UTF-8 ohne BOM.
🖖 Живіть довго і процвітайте
Bei den inkludierten Dateien (für die Bildergalerien, nicht für das Menü) war tatsächlich eine mit BOM gespeichert. Habe das geändert. Die Navigation steht direkt in der Seite. Danke für den Hinweis. In welchem Entwicklertool hat sich das gezeigt?
@@Kunst-eyids
In welchem Entwicklertool hat sich das gezeigt?
Firefox, Panel Debugger.
🖖 Живіть довго і процвітайте