Sandwich - Menue DEMO ohne irgentw. Scripte

[einsiedler]

Hallo liebe Forumer,

ich habe mal ausprobiert wie ein Sandwich - Menue (ohne jegl. Scripte) funtioniert

(um dies ggf. auf meine Websites anzuwenden)

Dies funktioniert auch schon ganz gut (wohl auch bei allen mobilen??) (siehe) :

Demo Version Sandwich Menue (ohne jegl. Scripte)

Jedoch habe ich noch folgendes Problem: Oben im Navigations - Menue ist das Scroll - Element

zu sehen.

Klar an der richtigen Stelle (hier):

.main-menu {
  position: absolute;
  left: -99vw;
  top: 0;
  height: 100%;
	overflow-y: scroll;
	overflow-x: visible;
	transition: left 0.2s ease,
				      box-shadow 0.2s ease;
	z-index: 999;
}

muss man overflow-y: scroll; durch hidden; ersetzen.

Gut, das geht....

AAAAAAAAABER...

Im Fall wenn der Inhalt des Bildschirmfensters extrem vergrössert wird (siehe hier:)

SCREEN vom Sandwich-Demo Problem

Nämlich dann, wenn overflow-y: scroll; durch hidden; ersetze dann scrollt das Menü

nicht mehr (also bei einer extremen Vergrößerung wie auf dem screen!)

Meine Frage: Wie muss ich jetzt vorgehen das eventuell beides gegeben ist?

Hilft mir eventuell ein ::before // ::after in dem Fall weiter?

Ich habe schon mehreres ausprobiert, u.a. im Fall von: @media (min-width: 768px) {

und hab dort ein overflow-y: scroll; eingefügt.

Half aber NICHTS!

Was muss ich tun???

Grüße der einsiedelde

[beatovich]

hallo

Zu deinem checkbox-hack

Der Focus bleibt nicht auf dem Label. Die checkbox selbst ist nicht sichtbar.

Es ist nicht Tastatur-bedienbar.

Wenn du ein aria-expanded nicht manipulierst, dann solltest du es auch nicht definieren.

Tipp: benutze für eine Version ohne Javascript die Methode

<a id="menubutton" href="#menucontent">Menu</a>
<div id="menucontent">

<a href="#menubutton">Menu</a>
</div>

Aktivierung über :target

[einsiedler]

Heißt das, das ich alles über Bord werfen soll/muss?

Köntest du ein wenig konkreter (in der Anwendung) werden?

(Ich kann besser lernen wenn ich z.B. ein Beispiel sehe!)

MFG der einsiedelnde

[beatovich]

hallo

Heißt das, das ich alles über Bord werfen soll/muss?

Köntest du ein wenig konkreter (in der Anwendung) werden?

MFG der einsiedelnde

Erstmal muss ich sagen, dass jede Javascript freie Lösung von Klappboxen zu mangelhaftem Verhalten führt.

Die Methode, die Anzeige über :target zu steuern, halte ich mit Einschränkung für die zuverlässigste (solange das Aktivieren eines Links innerhalb des Menucontent = target-Verlust die Box auch schliessen soll)

Du hast nun zwei Viewport-Kontexte:

• schmale Bildschirme

hier soll der Menubutton angezeigt werden.

#menubutton{display:inline-block}
#menucontent{ /* visuell verbergen, aber nicht display:none */ }
#menucontent:target{ /* visuell anzeigen */ }

• Desktopbildschirme

#menubutton{display:none}
#menucontent a[href="#menubotton"]{ display:none }

[Gunnar Bittersmann]

@@einsiedler

ich habe mal ausprobiert wie ein Sandwich - Menue (ohne jegl. Scripte) funtioniert

Sandwich? Ach so, nicht länglich, sondern rund: Burger.

BTW, du plenkst. Der Bindestrich steht ohne Leerzeichen drumrum.

Dies funktioniert auch schon ganz gut

Nö, der Checkbox-Hack funktioniert nicht gut. Nicht für Screenreader-Nutzer, die dann Blödsinn vorgelesen bekommen.

Wie beatovich schon sagte, ist „ohne JavaScript“ nicht immer ein anstrebenswertes Ziel. (An den Fallback sollte man natürlich denken: ohne JS ist das Menü auf schmalen Viewports immer geöffnet.)

Was funktionieren sollte, ist dieses Menü. Beschreibung in diesem Posting und diesem Thread.

LLAP 🖖

[einsiedler]

Oooh schöööön, nunja, das wenige js beeinträchtigt nichts (muss morgen nochmal

ausprobieren wenn ich alle scripte im Browser verbiete....)

Was mir nur auffällt ist, das ist das script nur hinter meiner </html> packen muss

sodass es funktioniert. An anderer Stelle nicht! komisch (Auch extern NICHT!)

Noch eine Nachfrage, was unterscheidet diese Version Version A von dieser Version Version B

Zeitlich? Aber was ist dann die FINAL-Version?

Vielen Dank ersteinmal und gute Nacht!

der einsiedelnde

[Gunnar Bittersmann]

@@einsiedler

Was mir nur auffällt ist, das ist das script nur hinter meiner </html> packen muss sodass es funktioniert. An anderer Stelle nicht! komisch (Auch extern NICHT!)

?? Dann machst du was falsch.

Noch eine Nachfrage, was unterscheidet diese Version Version A von dieser Version Version B

Bei Version A kann man das Menü (bei kleinem Bildschirm) mit Escape-Taste schließen, bei Version B nicht.

LLAP 🖖

[einsiedler]

Normalerweise bindet man js doch folgendermaßen ein:

<script>
<!--
... hier das Script
-->
</script>

So habe ich es auch gemacht. Innerhalb von <head> </head>

noch vor dem </body> Abschluß...

Aber nichts.…

Aaaaah, muss ich noch ein MIME-Type angeben? Bei html5?

Gruß der einsiedelnde

[Matthias Apsel]

Hallo einsiedler,

Aaaaah, muss ich noch ein MIME-Type angeben? Bei html5?

Nein.

Bis demnächst
Matthias

[beatovich]

hallo

Normalerweise bindet man js doch folgendermaßen ein:

<script>
<!--
... hier das Script
-->
</script>

Wichtig ist eher wie oder wann man es ausführt

function init(){

}

document.addEventListener("DOMContentLoaded", init, false);

[einsiedler]

WIE und WO binde ich nun das js ein?

Guckst Du mal bitte drüber : source code listing

B) Wie stelle ich es nun an das als Fallback eine :target Lösung anstrebe?

Wenn also kein script funktioniert!

Wäre das zu kompliziert?

DANKE!

mfg der einsiedelnde

[beatovich]

hallo

WIE und WO binde ich nun das js ein?

Guckst Du mal bitte drüber : source code listing

Binde es im head ein, notiere aber den Code in der von mir vorgeschlagenen init() Funktion. Diese wird dann aufgerufen wenn der DOM-Content geladen ist.

[Orlok]

Hallo beatovich

Binde es im head ein, notiere aber den Code in der von mir vorgeschlagenen init() Funktion. Diese wird dann aufgerufen wenn der DOM-Content geladen ist.

Wenn das Skript im head eingebunden wird, dann bitte mit gesetztem defer-Attribut. Ist das defer-Attribut nicht gesetzt, dann wird für die Ausführung des Skripts die Arbeit des HTML-Parsers unterbrochen. Das möchte man in aller Regel vermeiden.

        <script src="path/to/script.js" defer="defer"></script>
    </head>

Die Verzögerung der Skriptausführung mittels defer-Attribut geht allerdings nur bei solchen Skripten, die aus einer Datei geladen werden und nicht bei Skripten, die direkt im Dokument notiert sind. Direkt im Dokument enthaltene Skripte sollten stattdessen am Ende von body notiert werden:

        <script> /* code */ </script>
    </body>

FYI: Ich habe zum Thema "Einbindung von Skripten und Modulen" vor einiger Zeit mal einen etwas ausführlicheren Beitrag geschrieben. → async und defer

Viele Grüße,

Orlok

[Gunnar Bittersmann]

@@einsiedler

Normalerweise bindet man js doch folgendermaßen ein:

<script>
<!--
... hier das Script
-->
</script>

Nein. Das Auskommentieren des Codes mit HTML-Kommentarzeichen ist nichts, was man normalerweise macht.

LLAP 🖖

[klawischnigg]

Hi there,

@@einsiedler

Normalerweise bindet man js doch folgendermaßen ein:

<script>
<!--
... hier das Script
-->
</script>

Nein. Das Auskommentieren des Codes mit HTML-Kommentarzeichen ist nichts, was man normalerweise macht.

Naja, vor 20+ Jahren war das gängige Praxis. Heutzutage ist es natürlich etwas unwahrscheinlich auf einen Browser zu treffen, der nativ kein Javascript beherrscht. Zudem denk ich mir, Leute die so etwas verwenden, die dürfen sich an einem Javascript-Code mitten im Dokument auch nicht stören, die sind mit Sicherheit noch ganz andere Probleme gewohnt...😉

[Gunnar Bittersmann]

@@klawischnigg

Naja, vor 20+ Jahren war das gängige Praxis.

Und vor 15 Jahren war’s dann

<script type="text/javascript">
//<![CDATA[

  foo();

//]]>
</script>

Heutzutage ist es natürlich etwas unwahrscheinlich, auf Webseiten zu treffen, die als XHTML verarbeitet werden. Schade eigentlich.

LLAP 🖖