Problem mit Hamburger navigation container
0 
Felix Riesterer
0 0 
Rolf B
0 
Gunnar Bittersmann
0 Gunnar Bittersmann
0
Problem mit Hamburger navigation container
AugeHallo in die Runde, jetzt muß ich mich doch mal an die Pros wenden. Bin im Prinzip blutiger Anfänger und habe mir für meine hoffentlich bald online gehende Seite einen Banner-Logo-Block erstellt, der halt die üblichen Elemente hat: links das Icon, dann der Logo-Text und rechtsbündig das Hamburger-Menü. Um die Positionierung und Größe-Anpassung für mich einfacher zu machen, kam ich auf den fulminanten Gedanken, das ganze besser in einen Container zu „wrappen" - gedacht, getan. Nun mußte ich leider feststellen, daß es selten gut ausgeht wenn Amateure Extrawürste basteln. Anstatt den gewünschten Container zu bekommen, adressiert das CSS offenbar nicht wie gewünscht und erstellt stattdessen ein zweites Banner-Element direkt unter dem ersten Banner und wendet das gewünschte Styling auf dieses zweite Element an. Habe jetzt alles mögliche versucht von der Erhöhung der Spezifität bis zur Entfernung der flex-Regel usw. - nun bin ich ratlos und würde mich über Hilfe massiv freuen. Was mache ich falsch? Hier der Code:
<!DOCTYPE html>
<html lang="de" >
<head>
<meta charset="UTF-8">
<title>Banner-Debugging</title>
<style>
html {
font-family: Georgia, Ubuntu, Roboto;
font-size: 1.0em;
margin: 0;
padding: 0;
line-height: 1.15;
word-wrap: break-word;
-webkit-text-size-adjust: 100%;
-moz-text-size-adjust: 100%;
text-size-adjust: 100%;
color: #222;
background-color: #f0f0f0;
scroll-behavior: smooth;
}
body {
box-sizing: border-box;
margin: 0 auto 0 auto;
padding: 0;
min-height: 100vh;
max-width: 60em;
border: 1px solid #222;
border-radius: 0;
color: #222;
background-color: #fff;
font-size: 1.0em;
line-height: 1.40;
display: flex;
flex-direction: column;
justify-content: space-between;
}
/* Das ist der Übeltäter */
.banner-container {
position:fixed;
width: 100%;
height: 16em;
display: flex;
align-items:center;
justify-content: space-between;
background-color: red;
}
.icon {
top: 20px;
left: 20px;
fill: #000;
margin-right: 1.5em;
height: 48px;
width: 44px;
text-decoration: none;
transform: translateX(-10px);
vertical-align: middle;
}
.logo {
top: 1.8em;
left: 0;
padding-left: 1.5em;
z-index: 6;
font-size: 1.3em;
font-weight: 900;
font-family: Ubuntu;
text-transform: uppercase;
margin-left: 1.5em;
}
.icon, .logo {
position: fixed;
display: inline-block;
}
body input+label {
position: fixed;
top: 40px;
right: 40px;
height: 20px;
width: 15px;
z-index: 5;
}
body input+label span {
position: absolute;
width: 100%;
height: 2px;
top: 50%;
margin-top: -1px;
left: 0;
display: block;
background: #020304;
transition: 0.5s;
}
body input+label span:first-child {
top: 3px;
}
body input+label span:last-child {
top: 16px;
}
body label:hover {
cursor: pointer;
}
body input:checked+label span {
opacity: 0;
top: 50%;
}
body input:checked+label span:first-child {
opacity: 1;
transform: rotate(405deg);
}
body input:checked+label span:last-child {
opacity: 1;
transform: rotate(-405deg);
}
body input~nav {
background: white;
position: fixed;
top: 0;
left: 0;
width: 100%;
height: 100px;
z-index: 3;
transition: 0.5s;
transition-delay: 0.5s;
overflow: hidden;
}
body input~nav>ul {
list-style-type: none;
padding-left: 0;
text-align: center;
position: absolute;
top: 35%;
left: 20%;
right: 20%;
}
body input~nav>ul>li {
opacity: 0;
transition: 0.5s;
transition-delay: 0s;
}
body input~nav>ul>li>a {
text-decoration: none;
text-transform: uppercase;
color: #020304;
font-weight: 700;
font-family: sans-serif;
display: block;
padding: 30px;
}
body input:checked~nav {
height: 100%;
transition-delay: 0s;
}
body input:checked~nav>ul>li {
opacity: 1;
transition-delay: 0.5s;
}
</style>
</head>
<body>
<div class="banner-container">
<div class="logo">
<svg class="icon">
<path d="M24,33a8,8,0,0,0,8-8V9A8,8,0,0,0,16,9V25A8,8,0,0,0,24,33ZM20,9a4,4,0,0,1,8,0V25a4,4,0,0,1-8,0Z"/>
<path d="M38,25a2,2,0,0,0-4,0,10,10,0,0,1-20,0,2,2,0,0,0-4,0A14,14,0,0,0,22,38.84V43H21a2,2,0,0,0,0,4h6a2,2,0,0,0,0-4H26V38.84A14,14,0,0,0,38,25Z"/>
</svg>
logotext.de
</div>
<input id="menu-toggle" type="checkbox" name="menu-toggle">
<label for="menu-toggle">
<span></span>
<span></span>
<span></span>
</label>
<nav>
<ul>
<li><a href="./index.html" target="_blank">Heimat</a></li>
<li><a href="faq.html" target="_blank">FAQ</a></li>
<li><a href="content.html" target="_blank">Index</a></li>
<li><a href="imprint.html" target="_blank">Impressum</a></li>
</ul>
</nav>
<header>
</header>
</div>
</body>
</html>
Quelltext hier
-
Lieber Bendroid,
kannst Du Deine Code-Wüste als Online-Beispiel präsentieren? Dann fällt es deutlich leichter Dir zu helfen.
Liebe Grüße
Felix Riesterer
-
Oops, da habe ich offensichtlich den Standard-Kardinals-Anfängerfehler begangen (ich sage ja, blutiger Anfänger: das erste Mal das ich öffentlich Code poste). Hallo und danke für den Hinweis! Habe jetzt ein CodePen angelegt, der Link wäre: CodePen-Beispiel
Danke für eure Geduld!
Grüße, Ben
-
Hallo Bendroid,
und das Problem ist jetzt was genau?
Dass der rote Streifen sichtbar ist, liegt an
height:16emdes Banner-Containers.Im Übrigen ist dein Layout ein erbitterter Krieg zwischen verschiedenen Layoutsystemen (Flexbox vs absolute Positionierung), das kann nie gut gehen. Hinzu kommt eine Überdosis position:fixed - das genügt eigentlich für den Banner-Container, der Rest braucht das nicht. Meine ich.
Dass deine Vorgehensweise aus Sicht der Zugänglichkeit inkorrekt ist, hat Gunnar ja schon gesagt. Zugängliches Webdesign ist schwierig, das merkt man sofort, wenn man den von Gunnar verlinkten Artikel von Heydon Pickering liest. Schwierig deshalb, weil man einen Haufen Werkzeuge vom Browser bekommt, und jedes davon irgendwelche Macken hat oder nicht zu den Werkzeugen des Users passt.
Ohne JavaScript kommst Du bei einem solchen Popup-Menü nicht weiter, wenn ich Pickering richtig verstehe. Wobei dieses Verstehen ebenfalls schwierig ist. Entweder kann der Mann nicht erklären, oder er packt viel zu viel in den Artikel, oder ich bin zu doof. Ich habe diesen Artikel schon mehrfach zu verstehen versucht, und ich verstehe definitiv NICHT, was aus seiner Sicht jetzt die korrekte Implementierung ist. Es sind Textmassen über "hm, dies ist doof und jenes ist blöd und das da geht nicht" - und was ist jetzt die Empfehlung? Auf Popupmenüs zu verzichten, scheint mir. Grund: Eine zugängliche Webseite verzichtet auf jegliches fancy Layout und bietet möglichst nur flache Informationen. Also, optisch flach. Inhaltlich nicht. Was natürlich für diejenigen, die sehen können und visuelle Effekte wünschen, eine Schock ist.
Zugängliche Seiten sind im Grunde genommen zwei Seiten in einer. Die eine Seite sieht schick aus und bietet visuellen Schnickschnack, die andere Seite sieht man überhaupt nicht, sie wird nämlich vorgelesen, und muss so gestaltet sein, dass man sie durch Vorlesen erfassen kann. Und eine solche Seite muss mit mehreren Eingabetechniken klarkommen: Maus, Touch, Tastatur, und Sprachsteuerung. Letzteres ist dem PC Normalbenutzer unvertraut und scheint völlig unwichtig. Und deswegen ist eine große Anzahl von Webseiten eine Diskriminierung von Menschen, die auf Assistenztechniken angewiesen sind. Unser Wiki leider auch, aber unsere Wikisoftware kann es nicht besser.
Ich habe mich gestern mal damit beschäftigt, die neuen popovers als Popup-Menü zu verwenden, in der Hoffnung, dass die Browser hier die Zugänglichkeit automatisch mitbringen. Geht grundsätzlich, aber schick ist anders. Man kann Popovers zwar stylen, aber sie liegen im sogenannten Top-Layer und verlieren deshalb den Positionsbezug zu ihrem Elternelement. Eine Focus-Trap bekommt man auch nicht geschenkt. Mist 😟
Rolf
--
sumpsi - posui - obstruxi-
Grüß Dich Rolf,
danke erstmal für Deine Antwort.
Ich merke schon, daß ich gestern nicht wirklich das Problem herausstellen konnte. Es geht darum: natürlich könnte ich jetzt einfach
heightin der banner-container-Klasse auf 0 setzen und das rote Ding wäre weg. Damit ist mir leider nun gar nicht geholfen, weil die banner-container-Klasse ja überhaupt nicht für das rote Teil gedacht ist, sondern den korrekten, ursprünglichen Banner-Block darüber adressieren soll. Und genau das kriege ich nicht hin. Was immer ich verändere und ausprobiere, stets bleibt es dabei, daß das rote Untier adressiert und gestylt wird und nicht der darüberliegende korrekte Banner-Block. Und das ist das Problem.Deine Hinweise werde ich mir zu Herzen nehmen und schauen, was ich da verändert kriege. Ich würds gern besser machen...
Hauptsächlich geht es mir jedoch jetzt darum, den korrekten Banner-Block mit der banner-container-Klasse zu stylen, das er überhaupt auf die Klasse anspricht anstatt auf das rote Teil, das weiß der Teufel wo her kommt und natürlich weg muß.
Hoffentlich ist das Problem nun klarer geworden.
Grüße, Ben
-
-
-
-
@@Bendroid
Zunächst einmal die Frage: Warum soll ein Menü mit vier Items überhaupt hinter einem Hamburger-Icon versteckt werden? Das sollte auch auf kleinen Viewports so wenig Platz beanspruchen, dass man es gleich komplett anzeigen kann, ohne Nutzern zusätzliche Interktionen zum Öffnen aufzubürden.
<input id="menu-toggle" type="checkbox" name="menu-toggle"> <label for="menu-toggle"> <span></span> <span></span> <span></span> </label>Ins
label-Element gehört eine Beschriftung, in dem Fall „Menü“. Diese kann visuell vesteckt werden.3×
spanfür drei Linien? Ein Hamburger-Icon macht man mit SVG oder mit Unicode-Zeichen (spontan fallen mir ≡ U+2261 IDENTICAL TO und ☰ U+2630 TRIGRAM FOR HEAVEN ein).Der Checkbox-Hack (Checkbox zur Steuerung der Sichtbarkeit des Menüs) ist keine gute Idee. Nicht verwenden! Verwende stattdessen einen
<button>. Am besten einen, der den Zustand „Menü nicht geöffnet“ bzw. „Menü geöffnet“ angibt, siehe Navigation menu buttons in Inclusive Components: Menus & Menu Buttons.Wichtig ist, dass das Steuerungselement für die Sichtbarkeit des Menüs innerhalb des
nav-Elements ist. Anderenfalls hätten Screenreader-Nutzer arge Probleme, dieses zu finden.<nav> <button aria-expanded="false"> <span class="visually-hidden">Menü</span> <span aria-hidden="true">≡</span> <button> <ul> ⋮ </ul> </nav>So sollte das Markup aussehen. Mit JavaScript schaltet man
aria-expandedzwischen"false"und"true"um. Das wäre dann auch das einzige, was JavaScript tun muss, die Sichtbarkeit des Menüs kann man dann per Geschwister-Kombinator wieder CSS überlassen:[aria-expanded="false"] + ul { display: none }Auch animiertes Rein-/Rausfahren ist mit etwas mehr JavaScript und CSS möglich, Beispiel.
🖖 Живіть довго і процвітайте
PS: Hatte ich schon erwähnt, dass das Hamburg-Icon für Menüs keine so gute Idee ist? 🤪
--
Ad astra per aspera-
@@Gunnar Bittersmann
Auch animiertes Rein-/Rausfahren ist mit etwas mehr JavaScript und CSS möglich, Beispiel.
PS: Hatte ich schon erwähnt, dass das Hamburg-Icon für Menüs keine so gute Idee ist? 🤪
Beide gezeigten Beispiele sind nicht perfekt. Was fehlt: entweder focus trap (d.h. man kommt per Tastatur nicht aus dem geöffneten Menü heraus, ohne es vorher zu schließen) oder das Menü schließt sich automatisch, wenn der Tastaturfokus aus dem Menü rausgeht.
Zumindest hatte ich daran gedacht zu implementieren, dass man das Menü auch per ESC-Taste schließen kann.
🖖 Живіть довго і процвітайте
--
Ad astra per aspera -
Hallo und danke für die Antwort und die Hinweise.
Zu Deiner ersten Frage: da kommen noch mehr Verweise rein, bisher bin ich bei acht - hatte das Beispiel im Interesse des Lesers „runtergestripped" und von redundanten Elementen befreit ohne auf den Gedanken gekommen zu sein, gleich ein CodePen zu benutzen (MVE heißt das, hab ich kürzlich gelernt, nicht wahr? - Minimal viable example). Nunja, man lernt halt ohne Ende dazu momentan.
Letztlich, um kurz zum Hintergrund was zu sagen, bin ich seit drei Monaten dabei, dies ist mein allererstes quasi Hobby-Projekt was mehr zum Lernen gedacht ist, als das dafür eine Notwendigkeit besteht. Insofern bin ich selbstverständlich für jeden Hinweis dankbar. Werde Deinen Rat befolgen und den Checkbox-Hack durch ein Button-Element ersetzen.
Zu den Aria-Rollen: momentan bin ich froh, daß ich weiß was Aria bedeutet und warum man das verwenden sollte, allerdings ist Accessibility etwas, worauf ich mich in der zweiten Runde verstärkt konzentrieren werde. Aktuell bin ich noch zu sehr mit den Basics beschäftigt.
Und warum das Hamburger Menü? Ehrlich gesagt, einfach weil ich finde das es top aussieht. Ich hab mir die von Dir gepostete Seite angeschaut und verstehe die Argumente - aber wie gesagt, im Moment noch Basics, Hobbyprojekt ohne irgendwelche Produktions-Hintergründe.
Der Tip mit den Unicode-Zeichen anstatt leerer Span-Elementen war spitze, danke speziell dafür nochmal.👍
Auch Deine weiteren Beispiele habe ich mir natürlich angeschaut, möchte aber vorerst doch bei meinem Hamburger bleiben. 😌
-
Damit es übersichtlich bleibt ein neuer Post, noch kurz zwei Worte zur Verwendung von JavaScript:
Als ich vor drei Monaten mit dem Projekt anfing und mich statt für WordPress fürs Lernen entschied, hatte ich eigentlich im Sinn komplett ohne JS auszukommen. Ich habe (früher) selber immer zu den Leuten gehört, die den Browser gerne abgedichtet haben und Java und JS deaktiviert hatten, stammt wohl noch aus den Zeiten der „mißbräuchlichen" JS-Verwendung, als Seiten Ersteller mit JS Blink-Effekte und rollende Buchstaben und all den Käse fabriziert hatten.
Jedenfalls wollte ich, daß meine Seiten komplett ohne JS funktionieren.
Von der Direktive bin ich jetzt bereits zweimal abgewichen, einmal für back-to-top-Links und für einen Scroll-Indikator (habe relativ lange Artikel).
Dennoch bleibt mein Wunsch weiterhin, wo nicht unumgänglich nötig auf JS zu verzichten. Das zur Information.
Sollten noch Fragen auftauchen zu dem CodePen-Beispiel - nur zu. Habe das mißliebige überzählige Element rot gekennzeichnet, bin gespannt ob wir das endlich wegkriegen (ich glaub seit knapp ner Woche bin ich da am Versuchen und Probieren).
Nochmal herzlichen Dank an alle, die hier weiterhelfen und beste Grüße aus Berlin.
Ben
P.S: @Gunnar - Das Menü mit Esc zu schließen ist eine hervorragende Idee, bin selber absoluter Tastatur-Mensch (wenn ich überhaupt am Rechner sitze; das aktuelle Projekt habe ich zu 80 Prozent auf dem Mobile erstellt).
Falls Du dazu ein Code-Beispiel hättest, wie man das Implementieren könnte, wäre ich sehr interessiert.
-
@@Bendroid
P.S: @Gunnar - Das Menü mit Esc zu schließen ist eine hervorragende Idee, bin selber absoluter Tastatur-Mensch (wenn ich überhaupt am Rechner sitze; das aktuelle Projekt habe ich zu 80 Prozent auf dem Mobile erstellt).
Falls Du dazu ein Code-Beispiel hättest, wie man das Implementieren könnte, wäre ich sehr interessiert.
Das hätte ich: das schon gezeigte Beispiel.
Zeilen 38–47:
const keyupHandler = (event) => { if (event.code === 'Escape') { this.close(); this.controlElement.focus(); } } this.element.addEventListener('keyup', keyupHandler); this.controlElement.addEventListener('keyup', keyupHandler);In der Eventhandlerfunktion
keyupHandlerwird geprüft, ob das Event durch die Esc-Taste ausgelöst wurde. Wenn ja, wird das Menü geschlossen und der Tastaturfokus wieder auf den Button zum Öffnen/Schließen des Menüs gesetzt.Im anderen Beispiel mit Hamburg-Menü steht dasselbe in Grün in den Zeilen 31–37.
🖖 Живіть довго і процвітайте
--
Ad astra per aspera-
Hallo Gunnar,
addEventListener('keyup', keyupHandler)ist das auf Macs so üblich, dass ESC erst beim Loslassen der Taste reagiert? Die mir bekannte Welt reagiert bei Tastencodes auf keydown. Früher auch mal auf keypress, aber das ist ja mistbilligt.
Bei Buttons ist man es gewohnt, dass sie erst beim Loslassen reagieren.
Bei Dropdown-Menüs ist es unterschiedlich, eigentlich reagieren die sofort, nicht erst beim Loslassen, es gibt aber Ausnahmen, wenn man den Menüpunkt nicht nur klicken, sondern auch ziehen kann (bspw. die Favoritenordner in der Favoritenleiste von Chrome)
Touchflächen reagieren eigentlich auch erst beim Loslassen (um Touch und Drag zu unterscheiden...)
Keine AHnung, ob irgendeine Koriphäe dazu mal was verfasst hat.
Rolf
--
sumpsi - posui - obstruxi-
@@Rolf B
addEventListener('keyup', keyupHandler)ist das auf Macs so üblich, dass ESC erst beim Loslassen der Taste reagiert? Die mir bekannte Welt reagiert bei Tastencodes auf keydown. […] Keine AHnung, ob irgendeine Koriphäe dazu mal was verfasst hat.
Gute Frage. Ehrliche Antwort: Ich weiß es nicht.
Ich weiß nicht mehr, warum ich
keyupund nichtkeydownverwendet habe. Wenn ich was rausfinde, geb ich Bescheid.🖖 Живіть довго і процвітайте
--
Ad astra per aspera
-
-
@Gunnar:
Okay, wieder nur mit Javascript. Danke dennoch. Wie gesagt, ich hab nichts gegen js, aber bei diesem aktuellen Projekt nur, wenn es unumgänglich notwendig ist.
Grüße, Ben
-
Hallo
Okay, wieder nur mit Javascript. Danke dennoch. Wie gesagt, ich hab nichts gegen js, aber bei diesem aktuellen Projekt nur, wenn es unumgänglich notwendig ist.
Betrachte das aktuelle Problem mal von außen.
Du willst ein Hamburger-Menü realisieren, damit das Menü, egal, wie groß es konkret auch ist, nicht zuviel Platz einnimmt. Andererseits soll die Navigation auch ohne JS funktionieren. Und du willst mit möglichst wenig Einsatz von JS auskommen.
Anforderumg 1: Das Menü muss ohne JS funktionieren. Wenn JS also, aus welchem Grund auch immer, nicht verfügbar ist oder nicht funktioniert, muss dass Menü offen sein, damit es in solchen Fällen zugänglich ist. Dann braucht es auch keinen Button zum öffnen und schließen des Menüs, denn der wäre dann funktionslos. Damit, dass das Menü in diesem Fall eben doch den benötigten Platz beansprucht, musst du leben. Kannst du aber auch. Webseiten lassen sich nämlich ziemlich einfach scrollen, wenn man als Autor das nicht kaputt macht.
Anforderung 2: Das Menü wird mit einem Button geöffnet und geschlossen. Hier kommt notwendigerweise JS zum Einsatz, um auf die Betätigung des Buttons zu reagieren. Weiterhin muss das JS die durch die Anforderung 1 definierten Vorgaben umsetzen. Dort hatte ich vorgegeben, dass das Menü ohne JS offen sein soll und dass der Button zum Öffnen und Schließen des Menüs nicht vorhanden sein solle.
Das Ergebnis ist also ein initial offenes Menü, das nach dem Laden der Seite per JS geschlossen und mit dem zur Bedienung benötigten Button versehen wird. Weiterhin wird im JS ein Event registriert, damit auf die Betätigung des Buttons reagiert werden kann und der Code zum öffnen und schließen des Menüs wird in einer Funktion hinterlegt, die bei eintreten des Events ausgeführt wird.
Wie das Menü per JS mit einem Aria-Attribut versehen wird und mit der zugehörigen CSS-Regel geschlossen wird, hat Gunnar gezeigt. Wie im JS-Skript auf die Betätigung des Buttons reagiert wird, um das Menü zu öffnen oder zu schließen, hat er auch gezeigt. Das Wissen zur Erzeugung des Buttons und zur Registrierung des Events [1] kannst du dir im hauseigenen Wiki aneignen.
Das sollte mit geschätzten 20 bis 30 Zeilen JS-Code umsetzbar sein.
Tschö, Auge
--
„Habe ich mir das nur eingebildet, oder kann der kleine Hund wirklich sprechen?“ fragte Schnapper. „Er behauptet, nicht dazu imstande zu sein“ erwiderte Victor. Schnapper zögerte (…) „Nun …“ sagte er schließlich, „ich schätze, er muss es am besten wissen.“ Terry Prattchett, Voll im Bilde
infrage kämen click, touchstart und das alle Bedienfälle umfassen sollende pointerdown ↩︎
-
@@Auge
Das Ergebnis ist also ein initial offenes Menü, das nach dem Laden der Seite per JS geschlossen und mit dem zur Bedienung benötigten Button versehen wird.
Dabei dürfte sich aber kaum vermeiden lassen, dass die Nutzer das geöffnete Menü für einen kurzen (oder sollte ich sagen: mehr oder weniger langen) Augenblick zu sehen bekommen, bevor es wie von Geisterhand verschwindet. Nicht die beste UX. Das sollte man vermeiden.
Was wären die Alternativen? Ohne JS ist „≡“ ein Link zu einer anderen Seite mit dem Menü? Auch nicht so prickelnd. Dann vielleicht doch der
:target- oder der Checkbox-Hack, was per JS durch die gute Lösung mit Button ersetzt wird.Das Wissen zur Erzeugung des Buttons
… halte ich hier nicht für notwendig. Einfacher und performanter ist es, den Button mit HTML zu erzeugen – mit gesetzten
hidden-Attribut, was per JS entfernt wird.🖖 Живіть довго і процвітайте
--
Ad astra per aspera-
Interessante Betrachtungen. Wenn jetzt noch jemand sich zu meiner ursächlichen CSS-Problematik - das nicht-ansprechen der entsprechenden Klasse auf das gewünschte Element - äußern würde, wäre das natürlich die Apotheose schlechthin.
Oder handelt es sich tatsächlich um einen derart harten Brocken, daß da niemand ran will?
Grüße, Ben
-
@@Bendroid
Interessante Betrachtungen. Wenn jetzt noch jemand sich zu meiner ursächlichen CSS-Problematik - das nicht-ansprechen der entsprechenden Klasse auf das gewünschte Element - äußern würde, wäre das natürlich die Apotheose schlechthin.
Oder handelt es sich tatsächlich um einen derart harten Brocken, daß da niemand ran will?
Du warst da inzwischen selber dran, wenn ich mir deinen Codepen so ansehe?
Das Ding sieht ja jetzt gut aus. Nur dass das Ding nicht funktioniert.
🖖 Живіть довго і процвітайте
--
Ad astra per aspera
-
-
-
-
-
@@Bendroid
Jedenfalls wollte ich, daß meine Seiten komplett ohne JS funktionieren.
Von der Direktive bin ich jetzt bereits zweimal abgewichen, einmal für back-to-top-Links und für einen Scroll-Indikator (habe relativ lange Artikel).
Wozu brauchst du für Zurück-nach-oben-Links JavaScript? Um sie nicht selbst nach jedem Abschnitt ins HTML schreiben zu müssen, so wie im Beispiel back-to-top links?
Auch für einen Scroll-Indikator brauchst du kein JavaScript; das geht mit scroll driven animations (in Chromium-Browsern; in Firefox mit gesetztem Flag layout.css.scroll-driven-animations.enabled), so wie im Beispiel scrolling indicator.
Da es sich um ein zusätzliches Gimmick handelt, kann man hier auf progressive enhancement setzen und muss keinen Fallback für andere Browser implementieren.
Der Sinn von diesen Dingern hat sich mir noch nie erschlossen. Ich habe bereits einen Scroll-Indikator: die Scrollbar. Die zeigt die Scrollposition an, und das auch in der richtigen Richtung: vertikal, d.h. in Scrollrichtung. Wozu noch eine zusätzliche Anzeige, und die auch noch um 90° zur Scrollrichtung gedreht?
🖖 Живіть довго і процвітайте
--
Ad astra per aspera-
@@Gunnar Bittersmann
Auch für einen Scroll-Indikator brauchst du kein JavaScript; das geht mit scroll driven animations (in Chromium-Browsern; in Firefox mit gesetztem Flag layout.css.scroll-driven-animations.enabled), so wie im Beispiel scrolling indicator.
„Brauchst du nicht“ heißt hier: solltest du nicht verwenden. Aus Performanzgründen. Das
scroll-Event feuert ständig und die Abarbeitung des Eventhandlers frisst ziemlich viel Ressourcen – insbesondere auf Mobilgeräten.Und wenn man doch irgendwas mit dem
scroll-Event macht, sollte man das unbedingt mit debouncing bzw. throttling tun. Siehe Ich throttle und Links dort in den Fußnoten.🖖 Живіть довго і процвітайте
--
Ad astra per aspera -
Hallo
Der Sinn von diesen Dingern hat sich mir noch nie erschlossen. Ich habe bereits einen Scroll-Indikator: die Scrollbar.
Ich gebe dir gänzlich recht. Allerdings gibt's kaum ein ja ohne aber. Also: Aber das funktioniert leider in einigen Betriebssystemen und/oder Programmen zunehmend schlechter. Das von Mobilgeräten mit beschränkter Anzeigebreite stammende Paradigma, die Scrollbalken nur anzuzeigen, wenn gescrollt wird (was auf Mobilgeräten kein Problem ist, da das per Finger erfolgt), überträgt sich zunehmend auf Desktop-Systeme.
Da werden Scrollbalken nur als wenige Pixel breite, unauffällig gefärbte Striche angezeigt, die man mit dem Auge erst einmal finden und mit der Maus treffen muss. In manchen Systemen wird mit einem Klick ober- oder unterhalb des Balkens zu der Position des Mauszeigers gescrollt, statt eine Bildschirmhöhe weiter. Es gibt hier und da auch keine Buttons mehr für auf- und abwärts, was alles in allem dazu führt, dass man nur noch mit dem Mausrad oder, wenn das nicht anderweitig unterbunden wird, mit der Tastatur scrollen kann.
Das macht die Seitenhöhe schlecht erfassbar und das System schlechter bedienbar, als es das früher war. Irgendwo habe ich kürzlich diesbezüglich vom „War on Scrollbars“ gelesen. Ein passender Begriff, wie ich finde. 🙁
[edit]: Ich habe den Artikel Scrollbars are becoming a problem, in dem vom War on Scroolbars die Rede war, gefunden.
Tschö, Auge
--
„Habe ich mir das nur eingebildet, oder kann der kleine Hund wirklich sprechen?“ fragte Schnapper. „Er behauptet, nicht dazu imstande zu sein“ erwiderte Victor. Schnapper zögerte (…) „Nun …“ sagte er schließlich, „ich schätze, er muss es am besten wissen.“ Terry Prattchett, Voll im Bilde
-
-
-
-