Toggle-Navigation mit CSS :target Experiment
einsiedler
1 0 
Gunnar Bittersmann
0 einsiedler
Toggle-Navigation mit CSS :target Experiment
einsiedler
JürgenB
Tabellenkalk
Matthias ApselHallo liebe Forumer, ich unternehme gerad ein Toggle-Navigation mit CSS :target Experiment, das eigentlich auch ganz gut funktioniert: Toggle-Navigation mit CSS :target V1 Bis ich nun das Ganze in ein zentriertes mittiges div setze, (siehe: Toggle-Navigation mit CSS :target V2) dann wandert das (von links) "einschwebende" div vom äußersten linken Rand an und nicht vom linken Rand des mittleren (roten) "Fensters". Was ist nun falsch?
Freue mich um Hilfe.
Gruß der einsiedelnde
-
hallo
Hallo liebe Forumer, ich unternehme gerad ein Toggle-Navigation mit CSS :target Experiment, das eigentlich auch ganz gut funktioniert: Toggle-Navigation mit CSS :target V1 Bis ich nun das Ganze in ein zentriertes mittiges div setze, (siehe: Toggle-Navigation mit CSS :target V2) dann wandert das (von links) "einschwebende" div vom äußersten linken Rand an und nicht vom linken Rand des mittleren (roten) "Fensters". Was ist nun falsch?
Wünscht du also, dass ein Teil der Navigation immer sichtbar ist?
Aber ich sehe folgende Fehler:
- Die Abwesenheit eines Schliessen Buttons im Navigations-Block nötigt dich dazu, einen Button ausserhalb der Navigation sichtbar zu halten (egal wie das Fenster gescrollt ist).
- left/width 87vw ist dazu nicht geeignet
- Auf mobiles willst du sowieso die Navigation über die ganze Breite.
ferner: statt <div class="navMain"> verwende
- <nav id="navMain">
- <nav id="navLocal">
Da Navigationen selber Navigationsziele sind, ist es hier richtig eine id zu verschwenden.
Ferner halte ich es für interessant dass du ein Elternelement der Navigation statt die Navigation selber navigierst, um die Navigation via CSS zu verschieben. Interessant deshalb, weil damit sehr viel Styling auf :target reagieren kann. Trotzdem wollen wir eigentlich die Navigation navigieren, und nicht irgend einen Elternkontext, der noch alles andere enthält.
Ferner soll es ungünstig sein, Elemente von jenseits des Bildschirms einzuschieben. Die Kosten sind hier verschieden für verschiedene Richtungen. Es soll weniger kosten, die Navigation von oben einzuschieben.
Alternativ: verzichte auf Effekte.
Ferner: denke jetzt schon daran, dass deine Navigation wohl umfangreicher werden wird und du einen Skiplink vor der Navigation brauchst.
Ferner plane jetzt schon ein <header role="banner"> ein.
Ferner: überlege, welcher Inhalt den Main-Content repräsentiert und verwende für diesen <main id="maincontent">. Dieser soll das Ziel des Skiplinks sein.
-
@@einsiedler
ich unternehme gerad ein Toggle-Navigation mit CSS :target Experiment […] Was ist nun falsch?
Der Ansatz.
Jeder Click auf Öffnen-/Schließen-Link hinterlässt einen Eintrag in der Browser-History. Der Back-Button verkommt dadurch zur Witzfigur. Miese UX. Nicht machen!
Außerdem bekommen Nutzer das Öffnen-/Schließen-Dingens als Link präsentiert; es sollte aber ein Button sein! Button heißt
<button>.:targetist zum Ein-/Ausklappen der Navigation ungeeignet.Eine geeignete Technik hatte ich dir letztens erst gezeigt.
das eigentlich auch ganz gut funktioniert: Toggle-Navigation mit CSS :target V1
Im Firefox ist bei Tastaturnavigation nicht zu erkennen, wenn der Öffnen-/Schließen-Link den Fokus hat. Eigentlich nicht ganz gut.
LLAP 🖖
--
„Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann-
hallo
@@einsiedler
ich unternehme gerad ein Toggle-Navigation mit CSS :target Experiment […] Was ist nun falsch?
Der Ansatz.
Jeder Click auf Öffnen-/Schließen-Link hinterlässt einen Eintrag in der Browser-History.
Das ist ja an sich nicht schlecht!
Der Back-Button verkommt dadurch zur Witzfigur.
Der back-Button hat dadurch eine Funktion!
Miese UX. Nicht machen!
Es ist die beste zuverlässige no-JS-Version, die ich kenne.
An dieser Stelle schuldest du eine ausführliche Begründung, warum diese UX schlechter ist als die anderer Ansätze.
Außerdem bekommen Nutzer das Öffnen-/Schließen-Dingens als Link präsentiert; es sollte aber ein Button sein! Button heißt
<button>.Nö. Buttons sind für Javascript. Hier haben wir eine no-js Lösung.
-
@@beatovich
Jeder Click auf Öffnen-/Schließen-Link hinterlässt einen Eintrag in der Browser-History.
Das ist ja an sich nicht schlecht!
Doch …
Der back-Button hat dadurch eine Funktion!
Das beim Back-Button das Menü wiederholt auf- und zuklappt, ist nicht dessen Funktion. Beim Back-Button erwartet man, dass man zur vorigen Seite gelangt.
Es ist die beste zuverlässige no-JS-Version, die ich kenne.
Ich kenne ein andere zuverlässige No-JS-Version: Ohne JavaScript ist das Menü geöffnet; es wird erst mit JavaScript zugeklappt.
An dieser Stelle schuldest du eine ausführliche Begründung, warum diese UX schlechter ist als die anderer Ansätze.
Hatte ich die Fehlfunktion des Back-Buttons und die falsche Verwendung des
a-Elements nicht ausführlich genug begründet?LLAP 🖖
--
„Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann-
Lieber Gunnar,
Das beim Back-Button das Menü wiederholt auf- und zuklappt, ist nicht dessen Funktion. Beim Back-Button erwartet man, dass man zur vorigen Seite gelangt.
falsches "das" (du wolltest "dass") - aber egal. Auf kleinen mobile devices kriegt man das Menü sonst nicht weg, wenn man nicht den Back-Button benutzt (und der Button selbst nicht erreichbar ist). Es ist dort in gewisser Weise sogar intuitiv: "Was? Nee, das wollte ich nicht! Zurück zu vorher!" Dabei bedeutet "vorher" nicht zwingend "vorherige Seite", sondern eher "vorheriger Zustand". Wenn das also auch mit dem Back-Button geht, dann ist das sinnvoll. Dass es nur mit dem Back-Button geht, sicherlich nicht.
Liebe Grüße,
Felix Riesterer.
-
hallo
Das beim Back-Button das Menü wiederholt auf- und zuklappt, ist nicht dessen Funktion. Beim Back-Button erwartet man, dass man zur vorigen Seite gelangt.
seit wann?
Es ist die beste zuverlässige no-JS-Version, die ich kenne.
Ich kenne ein andere zuverlässige No-JS-Version: Ohne JavaScript ist das Menü geöffnet; es wird erst mit JavaScript zugeklappt.
Du wolltest sagen: Ohne Javascript haben wir ein HTML, das allein statisch positioniert vorliegt.
Mit Javascript bauen wir das GANZE HTML um, weil so viel ergänzt, ersetzt werden muss.
Da mache ich mir die Arbeit einfacher:
<a href="sitemap.html">...</a>
An dieser Stelle schuldest du eine ausführliche Begründung, warum diese UX schlechter ist als die anderer Ansätze.
Hatte ich die Fehlfunktion des Back-Buttons und die falsche Verwendung des
a-Elements nicht ausführlich genug begründet?Nein!
Lass mich aber die Forderungen und Mängelliste etwas aufzählen:
- Eine :target positionierte Box (tpB) soll ersetzt werden, wenn JS verfügbar ist.
- Eine tpB soll nur attribute enthalten, die in einem no-JS Kontext Sinn machen.
- Eine tpB soll in der Box selber Schliessen buttons (am Besten 2) enthalten!
- Die tpB soll in der Box selber keine Navigationsziele enthalten (diese würden nämlich das :target verändern).
- Skiplinks haben ausserhalb der Box zu liegen, und sind notwendig.
tpB's erzeugen im übrigen das gleiche Problem, das jede Form von internem Link erzeugt: Eine Fragment-ID wird erzeugt und wird mitkopiert, falls man die Seite bookmarken oder verlinken will. Das kann bei tpB's besonders irritieren.
Das halte ich für relevant, während dein Back-Button Hinweis schlicht irrelevant ist.
-
Hallo,
-
dass sich beim (Browser-)Back-Button die Navigation schließt, habe ich noch nie gesehen und würde ich auch nicht erwarten,
-
wenn beim Back-Button der vorherige Zustand der Seite hergestellt wird, finde ich das OK und intuitiv,
-
das Schließen des Menüs ist für mich nicht das Herstellen des vorherigen Zustands.
Gruß
Jürgen-
hallo
Hallo,
-
dass sich beim (Browser-)Back-Button die Navigation schließt, habe ich noch nie gesehen und würde ich auch nicht erwarten,
-
wenn beim Back-Button der vorherige Zustand der Seite hergestellt wird, finde ich das OK und intuitiv,
-
das Schließen des Menüs ist für mich nicht das Herstellen des vorherigen Zustands.
Der vorherige Zustand ist eine illusion.
-
Hallo,
Der vorherige Zustand ist eine illusion.
Um es mit Magritte zu sagen: Dies ist kein Zustand…
Gruß
Kalk
-
-
-
hallo
Lass mich aber die Forderungen und Mängelliste etwas aufzählen:
- Eine :target positionierte Box (tpB) soll ersetzt werden, wenn JS verfügbar ist.
- Eine tpB soll nur attribute enthalten, die in einem no-JS Kontext Sinn machen.
- Eine tpB soll in der Box selber Schliessen buttons (am Besten 2) enthalten!
- Die tpB soll in der Box selber keine Navigationsziele enthalten (diese würden nämlich das :target verändern).
- Skiplinks haben ausserhalb der Box zu liegen, und sind notwendig.
tpB's erzeugen im übrigen das gleiche Problem, das jede Form von internem Link erzeugt: Eine Fragment-ID wird erzeugt und wird mitkopiert, falls man die Seite bookmarken oder verlinken will. Das kann bei tpB's besonders irritieren.
Ergänzung: betrifft auch andere Mchanismen.
Warum brauchen wir einen Skiplink? Weil zu viele fokusierbare Elemente zwischen dem Beginn der Seite und dem Hauptinhalt liegen.
Ohne JS gibt es keine Möglichkeit, eine Navigation zu überspringen, daher der Skip-Link.
Ohne diese Tatsache hätte ich vor ein paar Wochen meine eigene Navigation kaum von einer tpB zu einer JS-Navigation umgestellt.
-
Hallo beatovich,
Das beim Back-Button das Menü wiederholt auf- und zuklappt, ist nicht dessen Funktion. Beim Back-Button erwartet man, dass man zur vorigen Seite gelangt.
seit wann?
Seit Anbeginn der Zeit.
Bis demnächst
Matthias--
Pantoffeltierchen haben keine Hobbys.-
hallo
Das beim Back-Button das Menü wiederholt auf- und zuklappt, ist nicht dessen Funktion. Beim Back-Button erwartet man, dass man zur vorigen Seite gelangt.
seit wann?
Seit Anbeginn der Zeit.
Nö. Seit Anbginn wurde erwartet, zum schlichtweg vorletzten history-Eintrag zu gelangen. Und das war und ist immer noch manchmal diesselbe Seite.
-
-
-
-
-
Irgendwie habe ich das Gefühl das zu viel "drumherum geschwafelt" wird und keine Lösungsansätze geboten werden. Aber lasst mich mal erläutern weshalb ich dies bräuchte (wenn es keinen Sinn macht dann eben auch nicht!) Folgende Problemstellung: BISHER ist es so das wenn ich auf der Arbeiten-Seite eine Arbeit, meinetwegen "Drifters,2012" anklicke dass sich ein neues Fenster öffnet und dann halt die entsprechende Dokumentation zu dieser Arbeit erscheint. Was ist aber nun wenn ich eine andere Arbeit, meinetwegen die nächste "Waldfrieden,2006"anklicken möchte, dann muss ich ja oben in Hauptmenue wieder Arbeiten anklicken um zum Hauptmenue zurückzukommen. Das finde ich erlich gesagt ein wenig umständlich (oder wäre das so normal?) Deshalb kam mir die Idee eben auf jeder Unterseite (für "Drifters,2012", "waldfrieden,2006" etc. von links ein Menue "einschwebt" , so wie das vom "Arbeiten" Hauptmenue. Illustriert habe ich das hier mal: Toggle-Navigation mit CSS :target V2 für eine Unterseite Ich hoffe jetzt wird es klarer wofür ich dies bräuchte, wenn es Sinn macht. Oder es gibt andere bessere Lösungen! Auchso ja, och bin immer bemüht eine Script-freie Lösung anzustreben, wenn dies möglich ist.
Bis später, Gruß der einsiedelnde
-
@@einsiedler
Auchso ja, och bin immer bemüht eine Script-freie Lösung anzustreben, wenn dies möglich ist.
„Nicht immer ein anstrebenswertes Ziel.“ Drehen wir uns im Kreis?
Ich bin immer bemüht, eine robuste Lösung anzustreben.
LLAP 🖖
--
„Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann-
Hmmmm, ja, diese Beispielseite favorisierte Beispielseite die ich vom Prinzip her ganz nett finde ist also "vollkommener Unsinn"! Mal bei "works" gucken, was dann Menuetechnisch passiert... Ja, okay....
-
-
