Scroll-Bereich eines Buttons innerhalb einer Grid-Area

[einsiedler]

Hallo liebe Forumer, seid gestern plage ich mich mit einer Sache herum

Der bläulich einfärbte Bereich ist meine betroffene Grid-Area

.top-link {		
      	grid-area: main-content / main-nav;}

Link zur Problemseite

In diesem Bereich soll ein Scroll-Up Button welcher erst nach ein wenig herunter-scrollen erscheinen soll (im sichtbaren Bereich wäre er ja unsinnig), dann schließend mit auf- oder abscrollt sodass er immer angeklickt werden könnte.

Nach diesem Prinzip: Ein Gif als Demo

Es muss also noch ein scrollbereich geben innerhalb der (blaugefärbten) Grid-Area, aber erst wenn ein wenig weiter heruntergescrollt wird, der dann bis ganz nach unten zum grid-row-end reicht.

Momentan habe ich keine Vorstellung wie man da herangeht.

Ich möchte lediglich einen Ansatz sodass ich es mir besser Vorstellen kann, keine Komplettlösung.

Grüße der einsiedelnde

[Felix Riesterer]

Lieber einsiedler,

für diesen back-to-top-Button eignet sich position:fixed (verlinkte Seite zeigt genau Deinen Anwendungsfall), oder position:sticky, womit man Elemente beim Scrollen sozusagen an einer bestimmten Stelle „festhalten“ kann.

Was dieses <div class="scroll-top">...</div> angeht, so stellt sich die Frage, ob Du mehrere solcher Buttons anbieten möchtest, damit sich eine Klasse hier lohnt. Mein Verdacht ist aber, dass Du stattdessen besser mit einer ID hantieren solltest: #scroll-top { ... }. Mir will auch nicht einleuchten, warum Du hier dermaßen Elemente verschachtelst und dabei mit Klassen (und einer ID) um Dich wirfst:

<div class="scroll-top">
  <ul id="skiptop-label" class="scroll-top_link">
    <li><a href="#skip-to-top"><span>skip to top</span></a></li>
  </ul>
</div>

Es genügt dieses Markup hier vollkommen:

<a href="#skip-to-top" id="scroll-top">skip to top</a>

Liebe Grüße

Felix Riesterer

[einsiedler]

Hallo,

gut, ja, das div drumherum bräuchte ich wohl nicht unbedingt.

Aber geht es auch wirklich?

Das gelb-umrandete stellt meinen sichtbaren Monitorbereich dar. Wenn ich nun ein wenig herunterscrolle erscheint der Button , er bleibt am unteren Rand (wenn er im sichtbaren Bereich rutscht) bis ich ihn ganz nach unten zum grid-ende scrolle.

Das ist es worum es mir geht.

Brauche ich da nicht ein umschliessende flexbox (das lange nach unten reichende schwarze Rechteck)?

Ich habe da komischerweise Startschwierigkeiten kann mich da bitte jemand anleiten?

Gruß der einsiedelnde

[Felix Riesterer]

Lieber einsiedler,

ich habe schon verstanden, was Du willst. Mir ist nur nicht klar, ob Du mit meinen Hinweisen wirklich etwas anfangen kannst.

Liebe Grüße

Felix Riesterer

[Rolf B]

Hallo Felix,

ich krieg's jedenfalls nicht hin.

Rolf

[Gunnar Bittersmann]

@@einsiedler

In diesem Bereich soll ein Scroll-Up Button welcher erst nach ein wenig herunter-scrollen erscheinen soll

Scheint mir, als wolltest du solch eine Lösung, wie ich sie für Discovery entdeckt habe. (No pun intended.) Und hurra, die 5. Staffel läuft endlich.

IntersectionObserver setzt eine Klasse, welche die Sichtbarkeit der Trennlinie unterm Header sowie des Footers regelt. Beschrieben in diesem Posting und dieser Präsentation.

Bei dir wäre es es dann eben die Sichtbarkeit des Buttons Links.

Kwakoni Yiquan

[einsiedler]

Ich habe mal ein wenig herumexperimentiert.

<!-- SKIP - to TOP LINK -->	
		<div id="skiptop" aria-labelledby="skiptop-label" class="scroll-top-wrapper">
			<h2 class="visually-hidden">Skip-to-TOP</h2>
			<ul id="skiptop-label" class="scroll-top_link">
				<li><a href="#skip-to-top"><span>skip to top</span></a></li>
			</ul>
		</div>

#skiptop {
		
	grid-area: main-content / main-nav;
	position: relative;}

.scroll-top-wrapper {
	position: absolute;
	top: 100vh;
	right: 0.25rem;
	bottom: -5em;
	width: 3em;
	pointer-events: none;
	display: inherit;
		grid-template-rows: inherit;}

.scroll-top_link {
	position: fixed;
	 position: sticky;
	 pointer-events: all;
	 top: calc(100vh - 5rem);
	 display: inline-block;
	 text-decoration: none;
	 font-size: 2rem;
	 line-height: 3rem;
	 text-align: center;
	 width: 3rem;
	 height: 3rem;
	 border-radius: 50%;
	 padding: 0.25rem;
	 border: 1px solid #254568;
	 background-color: #d6e3f0;
	 transition: transform 80ms ease-in;}

Damit habe ich zwar meinen gewünschten Effekt, aber durch das 100vh wird das Grid-Raster nach unten hin überschritten.

Warum ist das so?

% - Werte funktionieren nicht, was gibt es noch für Möglichkeiten?

Der Link zur betroffenen Seite ist immer-noch: Testseite V10A

So lieber Felix. soviel zu Deinem Einzeiler, jetzt trete mal in Aktion.

Aber auch an die anderen, bitte ich um Unterstützung. ich möchte mal voran kommen.

Grüße der einsiedelde

[Matthias Scharwies]

Guten Morgen!

Ich habe mal ein wenig herumexperimentiert.

Ja.

Deine ursprüngliche Problembeschreibung war:

In diesem Bereich soll ein Scroll-Up Button welcher erst nach ein wenig herunter-scrollen erscheinen soll (im sichtbaren Bereich wäre er ja unsinnig), dann schließend mit auf- oder abscrollt sodass er immer angeklickt werden könnte.

Momentan habe ich keine Vorstellung wie man da herangeht.

Ich möchte lediglich einen Ansatz sodass ich es mir besser Vorstellen kann, keine Komplettlösung.

Felix und Gunnar haben dir genau diese Ansätze gegeben, Gunnar sogar ein Beispiel.

Der Link zur betroffenen Seite ist immer-noch: Testseite V10A

Was mir auf den ersten Blick auffällt:

1. Die vertikale Überschrift ragt in meinem Surface (12''-Monitor) aus dem Viewport raus. Mach das weg! Less is more!
2. Navigation würde ich links positionieren (→ Lesefluss)
   • Das details ist ok, aber auf dem großen Monitor (40'') wäre Platz für alle Links der Navigationen
3. Site-Navigation wäre für mich als Laie ein Inhalt(sverzeichnis)

So lieber Felix. soviel zu Deinem Einzeiler, jetzt trete mal in Aktion.

Ist er doch schon. Du hast seinen Rat ignoriert.

Aber auch an die anderen, bitte ich um Unterstützung. ich möchte mal voran kommen.

Aufgabe an SELFHTML:

In diesem Bereich soll ein Scroll-Up Button welcher erst nach ein wenig herunter-scrollen erscheinen soll (im sichtbaren Bereich wäre er ja unsinnig), dann schließend mit auf- oder abscrollt sodass er immer angeklickt werden könnte.

1. Eine Seite hat so viel Inhalt, dass dieser erst durch Scrollen sichtbar wird.
   • HTML-Struktur (So einfach wie möglich)
     Du baust da im header Schachtelstrukturen mit div's und auch der top-Link besteht aus div,h2, ul, li, a WTF?
2. Sobald die Navigation unsichtbar wird, soll ein Top-Link erscheinen, der nach oben zielt.
   • Solche Berechnungen erfordern JS → siehe Gunnars Tip mit IntersectionOberserver
3. Der Top-Link (Pfeil nach oben) soll mittig am unteren Viewportrand positioniert werden
   • CSS Elemente zentrieren
     Du baust da eine Vielzahl von Grids auf, die man weder braucht noch versteht.
     → Imho ist die gewünschte Position nicht in einem Grid, sondern als Kind des body, den du ja auf Sichtbarkeit testest.

Das ist bei uns im Wiki noch eine Baustelle, die ich aber bis Ende des Monats schließen möchte.

Herzliche Grüße

Matthias Scharwies

[einsiedler]

Hallo Matthias,

Felix und Gunnar haben dir genau diese Ansätze gegeben, Gunnar sogar ein Beispiel.

Hmmm... nochmehr JS-Kram, ich wollte mich eigentlich davon befreien und das was ich schon habe, entsorgen. Und durch: html {scroll-behavior: smooth;} ersetzen.

@media screen and (prefers-reduced-motion: no-preference) {
  html {
    scroll-behavior: smooth;
  }
}

Ich muss darüber nachdenken.

Was mir auf den ersten Blick auffällt:

1. Die vertikale Überschrift ragt in meinem Surface (12''-Monitor) aus dem Viewport raus. Mach das weg! Less is more!

Das werde ich noch anpassen. Ist mir jetzt , der mit einem 32'' 4K Monitor arbeitet nicht aufgefallen ; O )

Nein, im Ernst, ich bin ja noch mitten drin und noch lange nicht fertig. Solche Anpassungen mach ich zum Schluss.

2. Navigation würde ich links positionieren (→ Lesefluss)
   • Das details ist ok, aber auf dem großen Monitor (40'') wäre Platz für alle Links der Navigationen

Stimmt schon, ist eine Überlegung wert. Das wollte ich ebenfalls so anpassen das sich die Haupt-Navigation bei einem bestimmten Querie, also (schmalen) Bildschirmfensterbreite zusammenzieht und erst dann ausgeklappt werden müsste. Das mit dem "details" wollte ich für die Hauptnavigation eigentlich noch ändern aber ich gewöhne mich gerade daran und lass es vielleicht. Es ist so einfach.

3. Site-Navigation wäre für mich als Laie ein Inhalt(sverzeichnis)

Klaro, hab schon nach passenden Begriffen gesucht.

So lieber Felix. soviel zu Deinem Einzeiler, jetzt trete mal in Aktion.

Ist er doch schon. Du hast seinen Rat ignoriert.

Sag ich nichts zu.

Aufgabe an SELFHTML:

In diesem Bereich soll ein Scroll-Up Button welcher erst nach ein wenig herunter-scrollen erscheinen soll (im sichtbaren Bereich wäre er ja unsinnig), dann schließend mit auf- oder abscrollt sodass er immer angeklickt werden könnte.

1. Eine Seite hat so viel Inhalt, dass dieser erst durch Scrollen sichtbar wird.
   • HTML-Struktur (So einfach wie möglich)
     Du baust da im header Schachtelstrukturen mit div's und auch der top-Link besteht aus div,h2, ul, li, a WTF?

Du meinst den Sub-Header, ich habe Zustände bekommen das so hinzubekommen und war letzlich so froh. Hier bestand die gleiche Probleblematik wie jetzt beim Top-Link. Dann zeig mir bitte wie es einfacher geht, mit nur wenigen Zeilen. Bei allem Respekt Deiner Könnerschaft die Du sicherlich hast, setz Dich mal daran und erkenne die Problematik mit der fehlenden Höhe der Grits. Dumm rum schwafeln kann ich auch. </Bei allem Respekt>

2. Sobald die Navigation unsichtbar wird, soll ein Top-Link erscheinen, der nach oben zielt.
   • Solche Berechnungen erfordern JS → siehe Gunnars Tip mit IntersectionOberserver

Richtig. Wenn es unbedingt sein muss. Ich muss darüber nachdenken.

3. Der Top-Link (Pfeil nach oben) soll mittig am unteren Viewportrand positioniert werden
   • CSS Elemente zentrieren

Nicht so einfach das zu finden was innerhalb eines Grit auch funtioniert. Beim Meisten davon passiert einfach schlichtweg NICHTS.

Du baust da eine Vielzahl von Grids auf, die man weder braucht noch versteht.

Sicher?

→ Imho ist die gewünschte Position nicht in einem Grid, sondern als Kind des body, den du ja auf Sichtbarkeit testest.

Definiert aber IST, wie gesagt das Grid-Raster mit :

.top-link {		
      	grid-area: main-content / main-nav;}

Und dann soll es sich auch bitteschön so verhalten und NICHT zum body.

Das ist bei uns im Wiki noch eine Baustelle, die ich aber bis Ende des Monats schließen möchte.

Muss ich mir anschauen, wenn es wirklich nicht anders geht.

Herzliche Grüße

Matthias Scharwies

Herzliche Grüße T.

Nachtrag: Wegen meiner Langsamkeit beim fortschreiten bin ich leicht angenervt. Das drückt sich leider bei meinem Posting aus.

[Matthias Scharwies]

Servus!

Du so: „Ich hab' ein Problem“

Felix gibt dir Tipps.

Du so: "Das ist es worum es mir geht."

Felix: „ich habe schon verstanden, was Du willst. Mir ist nur nicht klar, ob Du mit meinen Hinweisen wirklich etwas anfangen kannst.“

1 Tag später du: „So lieber Felix. soviel zu Deinem Einzeiler, jetzt trete mal in Aktion.“

Ich: „So musst du es machen“

Und dann wieder du:

Bei allem Respekt Deiner Könnerschaft die Du sicherlich hast, setz Dich mal daran und erkenne die Problematik mit der fehlenden Höhe der Grits. Dumm rum schwafeln kann ich auch. </Bei allem Respekt>

Das mit dem Grit(sic!) ist ein Irrweg.

Nicht so einfach das zu finden was innerhalb eines Grit auch funtioniert. Beim Meisten davon passiert einfach schlichtweg NICHTS.

Das mit dem Grit(sic!) ist ein Irrweg.

Du baust da eine Vielzahl von Grids auf, die man weder braucht noch versteht.

Sicher?

Ja!

Wir gehen jetzt Fahrradfahren und dann zu Freunden Grillen.

@everyone else Ich habe schon ein bisschen rumgespielt und stelle das (hoffentlich) übermorgen vor.

Herzliche Grüße

Matthias Scharwies

[Gunnar Bittersmann]

@@einsiedler

Felix und Gunnar haben dir genau diese Ansätze gegeben, Gunnar sogar ein Beispiel.

Hmmm... nochmehr JS-Kram, ich wollte mich eigentlich davon befreien und das was ich schon habe, entsorgen.

Du willst auf eine Nutzerinteraktion (Scrollen) reagieren. Um auf Nutzerinteraktionen zu reagieren, ist JavaScript oft das Richtige.

Und durch: html {scroll-behavior: smooth;} ersetzen.

@media screen and (prefers-reduced-motion: no-preference) {
  html {
    scroll-behavior: smooth;
  }
}

Ja, dafür braucht man kein JavaScript. Aber was hat das mit deinem Button Link zu tun, der erscheinen soll, wenn der Nutzer ein bisschen runtergescrollt hat?

Spoiler: nichts.

Vielleicht ließe sich da was mit scroll-driven animations hinbasteln – wenn es denn mal browserübergreifend funktioniert. (Gegenwärtig nur in Chromia, in Firefox hinter Feature-Flag, in Safari noch gar nicht.)

Vielleicht aber auch nicht, weil als keyframe selector nur Prozentwerte (und Aliasse from und to) erlaubt sind, keine absoluten Längen.

---

So lieber Felix. soviel zu Deinem Einzeiler, jetzt trete mal in Aktion.

Ist er doch schon. Du hast seinen Rat ignoriert.

Sag ich nichts zu.

Da sag ich jetzt mal auch nichts zu.

Kwakoni Yiquan

[einsiedler]

Hallo,

Ja, dafür braucht man kein JavaScript. Aber was hat das mit deinem Button Link zu tun, der erscheinen soll, wenn der Nutzer ein bisschen runtergescrollt hat?

Da direkt noch nichts, richtig, aber wenn der link einmal betätigt ist wird ja smooth heraufgesrollt, und beim (momentan) von mir genannten "Inhaltsverzeichnis" zu den datierten Artikeln heruntergescrollt.

Als JS habe ich neben dem üblichen jquery.min.js:

smooth-scroll.js

// Select all links with hashes
$('a[href*="#"]')
// Remove links that don't actually link to anything
    .not('[href="#"]')
    .not('[href="#0"]')
    .click(function(event) {
        // On-page links
        if (
            location.pathname.replace(/^\//, '') == this.pathname.replace(/^\//, '')
            &&
            location.hostname == this.hostname
        ) {
            // Figure out element to scroll to
            var target = $(this.hash);
            target = target.length ? target : $('[name=' + this.hash.slice(1) + ']');
            // Does a scroll target exist?
            if (target.length) {
                // Only prevent default if animation is actually gonna happen
                event.preventDefault();
                $('html, body').animate({
                    scrollTop: target.offset().top
                }, 600, function() {
                    // Callback after animation
                    // Must change focus!
                    var $target = $(target);
                    $target.focus();
                    if ($target.is(":focus")) { // Checking if the target was focused
                        return false;
                    } else {
                        $target.attr('tabindex','-1'); // Adding tabindex for elements not focusable
                        $target.focus(); // Set focus again
                    }
                });
            }
        }
    });

und noch button-menue.js

function globalClickManager(ev){
		// ev.target gibt uns das Element auf dem der Click geschah.

		// steuere expanded Buttons
		if(ev.target.hasAttribute("aria-expanded") ){
		ev.target.setAttribute("aria-expanded", ( ev.target.getAttribute("aria-expanded") == "false") ); 
			}
		// Buttons die lediglich den Click transferieren ähnlich zu label Elementen
		else if(ev.target.hasAttribute("data-for-id") ){
			document.getElementById( ev.target.getAttribute("data-for-id") ).click();
			}
		else if( Element.prototype.closest){
			if( ev.target.closest("nav") == null ){
				var temp = document.querySelector("nav [aria-expanded='true']");
				if(temp) temp.setAttribute("aria-expanded","false");
			}
		}
	}
	function init(){
		var col = document.querySelectorAll("nav [aria-expanded]");
		for(var i=0; i<col.length; i++){
			col[i].setAttribute("aria-expanded","false");
		}
		document.body.addEventListener("click",globalClickManager);
		}
	document.addEventListener("DOMContentLoaded", init, false);

Aber wie gesagt, beides möchte ich herausschmeissen, das erstere JS auf jeden Fall da genügt der Einzeiler: html {scroll-behavior: smooth;}. Für was genau das zweitere JS war, weiß ich nicht mehr. Also weg.

Ich schaue mir mal genauer Deine Verlinkungen an.

Momentan probiere ich folgendes: Wenn ich schon nicht das korrekte grid-row-ende zufassen bekomme, mache ich es umgekehrt: Nicht Angefangen von der Link-Oberkante bis ganz runter zum grid-row-ende (das ja nicht akzeptiert wird) sondern von der LINK-Unterkante bis rauf zum grid-row-start.

Ich gebe also einen Scrollbereich meinetwegen 90vh (wenn überhaupt vh anerkannt wird) und setze den link ans untere Ende, mal sehen wie dann das Scrollverhalten ist. Villeicht habe ich damit mehr Erfolg und das grid-raster-ende wird jetzt akzeptiert.

Das probiere ich noch aus bevor ich mich Deinen Workarround zuwende.

So lieber Felix. soviel zu Deinem Einzeiler, jetzt trete mal in Aktion.

Ist er doch schon. Du hast seinen Rat ignoriert.

Sag ich nichts zu.

Da sag ich jetzt mal auch nichts zu.

? Ähm...

Gruß der einsiedelnde

[MudGuard]

Hi,

Als JS habe ich neben dem üblichen jquery.min.js:

was ist daran üblich? Wir schreiben das Jahr 2024 …

Aber wie gesagt, beides möchte ich herausschmeissen,

Das ist von vornherein ausgeschlossen.

"Heraus" bedeutet eine Bewegung auf Dich zu ^[1], "schmeißen" ist (für den geschmissenen Gegenstand) eine Bewegung von Dir weg.

Also ist Herausschmeißen ein Widerspruch in sich a/k/a Oxymoron …

cu,
Andreas a/k/a MudGuard

---

1. von Dir weg wär's ja "hinaus" ↩︎

[einsiedler]

Zunächst : Werft den Purschen zu Poden...

Jawoll Prian... ;o)))

Gruß

[Felix Riesterer]

Lieber einsiedler,

Ich habe mal ein wenig herumexperimentiert.

<!-- SKIP - to TOP LINK -->	
		<div id="skiptop" aria-labelledby="skiptop-label" class="scroll-top-wrapper">
			<h2 class="visually-hidden">Skip-to-TOP</h2>
			<ul id="skiptop-label" class="scroll-top_link">
				<li><a href="#skip-to-top"><span>skip to top</span></a></li>
			</ul>
		</div>

darin sehe ich keinen Fortschritt. Noch mehr Markup für dieses GUI-Element... Ernsthaft jetzt?

So lieber Felix. soviel zu Deinem Einzeiler, jetzt trete mal in Aktion.

Du machst mir mit Deinem Verhalten so viel Lust darauf Dir zu helfen... nicht.

Liebe Grüße

Felix Riesterer

[einsiedler]

Gut, mag ja sein das das div aber auch die Überschrift darunter zuviel ist.

ul, li und das a benötige ich aber mindestens, für einen Scrollbereich und den eigentlichen Link, der ja aus zweierlei besteht und ebenso stylisch aufgehüpscht werden will.

Momentan probiere ich folgendes: Wenn ich schon nicht das korrekte grid-row-end zufassen bekomme, mache ich es umgekehrt: Nicht Angefangen von der Link-Oberkante bis ganz runter zum grid-row-end (das ja nicht akzeptiert wird) sondern von der LINK-Unterkante bis rauf zum grid-row-start.

Ich gebe also einen Scrollbereich meinetwegen 90vh (wenn überhaupt vh anerkannt wird) und setze den link ans untere Ende, mal sehen wie dann das Scrollverhalten ist. Villeicht habe ich damit mehr Erfolg und das grid-raster-ende wird jetzt akzeptiert.

Sonst muss Gunnars Lösung herangezogen werden.

Du machst mir mit Deinem Verhalten so viel Lust darauf Dir zu helfen... nicht.

Dann lass es halt, deine Einzeiler-Lösung ist immer noch nicht bewiesen. ; o ) ... Niiiiicht

Gruß der einsiedelnde

Nachtrag: Folgende Links haben mich auf Ideen gebracht:

https://codepen.io/5t3ph/pen/OJyyqWR

https://dev.to/5t3ph/pure-css-smooth-scroll-back-to-top-1cid

https://codepen.io/t_afif/pen/poLWLJG

https://codepen.io/jackherizsmith/pen/oNxVWrK

[Gunnar Bittersmann]

@@einsiedler

ul, li und das a benötige ich aber mindestens

Nein, ul/li sind falsch. Ein Link macht noch keine Liste.

Wenn du da Containerelemente brauchst, dann div.

Nachtrag: Folgende Links haben mich auf Ideen gebracht:

👍

Kwakoni Yiquan

[einsiedler]

Hallo liebe Forumer,

ich glaube... , ich habe es jetzt ...

Testseite-V10b.html

Der Scrollbereich wird endlich eingehalten...

Beim FF, Opera, Chrome und Edge (alle neueste Updates / Win 10) sieht es soweit gut aus.

Nur der FF 115.9.1esr 64bit und Edge 109.0.1518.140 64bit (Win7), hat eine andere window.innerHeight; (Stichwort: JavaScript - Fenstergröße / hier die HÖHE ermitteln) ist eine andere als bei den neuesten Browsern.

Es ergibt sich meine Frage, ob ich nun bei meinem top und max-width die mit Javascript ermittelte jeweilige Fensterhöhe ersetzen sollte oder nicht.

Die Werte:

.scroll-top_link {
	position: fixed;
	position: sticky;
	margin-top: 44rem;
	margin-bottom: 1.9rem;
	top:37em;	
	text-decoration: none;
	pointer-events: all;
	text-align: center;
}

Macht es Sinn oder sollte ich ich die Werte so anpassen das sie bei vielen meiner Browser einigermassen (in der Höhe) passen.

Könnte mir bitte jemand dieses einfache script schreiben?

Ich muss mich wohl an diese Scripte gewöhnen, die gehören einfach dazu.

Jetzt mache ich noch die vielen kleinen Anpassungen. Beim den Menüs "Inhalt" und "weiterführende Links" lasse ich es bei : details Es ist schlicht und einfach. Bei der Hauptnavigation, tja... da weiß ich noch nicht ob es bei details bleibt.

Danke an alle Helfer.

Gruß der einsiedelnde

[einsiedler]

Nachtrag: Zufrüh gefreut, ich brauch doch den IntersectionObserver

Bei 110% Schriftvergrößerung funktioniert es noch, obwohl die Werte von top und margin-top in der Höhe nicht stimmen

:o(((

[Matthias Scharwies]

Guten Morgen,

@JürgenB ich habe im Tutorial Komfort-Version mal ein paar Kleinigkeiten geändert:

Oben wird eine Basic-Variante ohne JavaScript, aber bereits mit dem ScrollSnap aus dem vorherigen Kapitel vorgestellt.

Das Kapitel zum Intersection Observer ist um zwei Varianten bereichert:

1. Rechts links-Pfeile kommt leider erst am Wochenende
2. Variante mit Skip-to-Top-Link
   • Der fixed Header ist jetzt Teil der ersten section und wandert beim Scrollen nach oben.
   • Sobald die Navigation unsichtbar wird, soll ein Skip-To-Top-Link erscheinen, der nach oben zielt.

Ich habe bewusst Varianten genommen, damit das Final-Beispiel nicht alle möglichen JS-Snippets enthält. Fixed Header und Pfeil nach oben macht keinen Sinn.

Hier mein JS: [[EDIT]] neue Version!

	const topLink = document.querySelector('#skip-to-top');
	const nav = document.querySelector('nav');
	let observer = new IntersectionObserver(function (entries) {
		entries.forEach(function (entry) {
			if (!entry.isIntersecting) {
				topLink.hidden = false;
			} else {
				topLink.hidden = true;
			}
		});
	}, {
		threshold: [0]
	});
	observer.observe(nav);

Könntest du / könntet ihr mal drüberschauen, ob euch noch was auffällt?

@einsiedler Schau dir das LiveBeispiel an,

1. Der Skip-to-Top-link ist Teil des Headers:

    <header>
      <a id="backlink" href="#willkommen"><img src="logo.svg" alt="Willkommen"></a>
      <a href="#willkommen" id="skip-to-top" hidden >skip to top</a>
      <hgroup>
        <h1>Schreinerei Meier</h1>
        <p>ihre Werkstatt für gutes Wohnen!</p>
      </hgroup>
      <nav>
        <ul>
          <li aria-current="location"><a href="#willkommen">Willkommen</a></li>
          <li><a href="#preise">Preise</a></li>
          <li><a href="#produkte">Produkte</a></li>
          <li><a href="#kontakt">Kontakt und Impressum</a></li>
        </ul>
      </nav> 
    </header>

2. Das CSS könnte man ausbauen - die Positionierung ist aber trivial:

main {
	position: relative;
}	

#skip-to-top {
	position: fixed;
	bottom: 1em;
	right: 50%;
	background-color: var(--green-darker2);
	color: gold;
	padding: 1em 2em;
}

#skip-to-top:hover {
  background-color: var(--red-darker2);
}

[/EDIT]

Wie gesagt, Das Beispiel mit den Vor- und Zurück-Pfeilen kommt später. Stay tuned!

Herzliche Grüße

Matthias Scharwies

[Gunnar Bittersmann]

@@Matthias Scharwies

	const topLink = document.getElementById('skip-to-top');
	const nav = document.querySelector('nav');

Warum document.getElementById()? Warum nicht einheitlich document.querySelector()?

---

			if (!entry.isIntersecting) {
				topLink.style.display = 'block';
			} else {
				topLink.style.display = 'none';
			}

Besser:

			topLink.style.display = !entry.isIntersecting ? 'block' : 'none';

oder andersrum

			topLink.style.display = entry.isIntersecting ? 'none' : 'block';

Noch besser:

			topLink.hidden = entry.isIntersecting;

mit <a href="#willkommen" id="skip-to-top" hidden>skip to top</a> im Markup.

Wie oft muss man das hidden-Attribut und seine Vorteile noch erwähnen, bis es Beachtung findet?

Kwakoni Yiquan

[Matthias Scharwies]

Servus!

@@Matthias Scharwies

	const topLink = document.getElementById('skip-to-top');
	const nav = document.querySelector('nav');

Warum document.getElementById()? Warum nicht einheitlich document.querySelector()?

---

			if (!entry.isIntersecting) {
				topLink.style.display = 'block';
			} else {
				topLink.style.display = 'none';
			}

Besser:

			topLink.style.display = !entry.isIntersecting ? 'block' : 'none';

oder andersrum

			topLink.style.display = entry.isIntersecting ? 'none' : 'block';

Noch besser:

			topLink.hidden = entry.isIntersecting;

mit <a href="#willkommen" id="skip-to-top" hidden>skip to top</a> im Markup.

Wie oft muss man das hidden-Attribut und seine Vorteile noch erwähnen, bis es Beachtung findet?

ok, werd' ich heute Abend ändern!

Was hältst du von der Position im HTML? Soll der Link ans Ende des Dokuments?

Herzliche Grüße

Matthias Scharwies

[Rolf B]

Hallo Gunnar,

topLink.style.display = !entry.isIntersecting ? 'block' : 'none';
topLink.style.display = entry.isIntersecting ? 'none' : 'block';

nein, weder noch.

Wenn überhaupt über style.display, dann so:

if (entry.isIntersecting)
   topLink.style.display = "none";
else
   topLink.style.removeProperty("display");

womit sich die Frage erübrigt, was der richtige display-Wert für topLink ist, wenn er nicht versteckt wird.

Ich bestreite damit nicht, dass hidden trotzdem eleganter ist. Man muss nur achtgeben, es kann nämlich passieren, dass hidden keinen Effekt hat.

Im Browser-Stylesheet steht

[hidden] { display: none; }

Wenn das auszublendende Element seine display-Eigenschaft über eine CSS-Regel im Autorenstylesheet bekommt (was bei Flexbox oder Grid immer so ist), dann ist diese Regel auf Grund der Kaskade spezifischer und die Browserregel hat keinen Effekt. Man muss sein eigenes Stylesheet dann um passende Regeln erweitern.

Deshalb kann es noch sinnvoller sein, eine eigene Klasse vorzusehen, die den Sachverhalt "wird gerade nicht gebraucht" darstellt und mit geeigneter Spezifität eine CSS Regel aktiviert, die die nötigen Styles zuweist. Diese Klasse kann man dann mittels classList.toggle bedarfsweise aktivieren.

topLink.classList.toggle("out-of-screen", entry.isIntersecting);

Rolf

[Gunnar Bittersmann]

@@Rolf B

Wenn überhaupt über style.display, dann so:

if (entry.isIntersecting)
   topLink.style.display = "none";
else
   topLink.style.removeProperty("display");

Nein.

womit sich die Frage erübrigt, was der richtige display-Wert für topLink ist, wenn er nicht versteckt wird.

Auch dafür brauchst du kein if-else-Konstrukt.

topLink.style.display = entry.isIntersecting ? 'none' : 'revert';

---

Ich bestreite damit nicht, dass hidden trotzdem eleganter ist. Man muss nur achtgeben, es kann nämlich passieren, dass hidden keinen Effekt hat.

Im Browser-Stylesheet steht

[hidden] { display: none; }

Wenn das auszublendende Element seine display-Eigenschaft über eine CSS-Regel im Autorenstylesheet bekommt (was bei Flexbox oder Grid immer so ist), dann ist diese Regel auf Grund der Kaskade spezifischer und die Browserregel hat keinen Effekt. Man muss sein eigenes Stylesheet dann um passende Regeln erweitern.

Nur um eine:

[hidden] { display: none !important }

Deshalb kann es noch sinnvoller sein, eine eigene Klasse vorzusehen

Womit sich das wohl erledigt hat.

Kwakoni Yiquan

[Rolf B]

Hallo Gunnar,

topLink.style.display = entry.isIntersecting ? 'none' : 'revert';

MDN:

The revert CSS keyword reverts the cascaded value of the property from its current value to the value the property would have had if no changes had been made by the current style origin to the current element.

Fett von mir. Die Spec macht mehr Worte, sagt aber das Gleiche.

Wenn das topLink-Element seinen gewünschten display-Wert aus dem User- oder Useragent-Stylesheet bekommt, dann wird revert funktionieren. Aber wenn es den display-Wert aus einem Autorenstylesheet bekommt, dann funktioniert es nicht. Weil style-Attribut und Autorenstylesheet der gleiche style origin sind.

Damit ist es eine Lösung, über deren Verwendbarkeit man nachdenken muss, bevor man sie anwendet – bzw. die einen nachträglich in die Ferse beißen kann, wenn man dem Element nachträglich im Autorenstylesheet eine display-Eigenschaft geben will. Und deshalb habe ich removeProperty vorgeschlagen.

.a {
  display: flex;
}

<div class="a">...</div>

Wenn Du jetzt dem div.a ein display:revert ins style-Attribut schreibst, ist die Flexbox weg. Die bleibt nur da, wenn Du display ganz entfernst - oder Müll zuweist, z.B. display: -g16n-whatever.

Aber wir sind uns ja einig: Finger weg von der style-Eigenschaft (bzw. vom Attribut), wenn man ein Element ausblenden will.

[hidden] { display: none !important }

Deshalb kann es noch sinnvoller sein, eine eigene Klasse vorzusehen

Womit sich das wohl erledigt hat.

Wenn es nur um das display:none geht, ja. Aber das war nicht das, was ich meinte. Es ist ja durchaus möglich, dass in dem Zustand "topLink nicht sichtbar" auch noch andere Dinge zu stylen sind. Weshalb ich ja auch von „kann sinnvoller sein“ sprach; vielleicht hätte ich das kann hervorheben sollen.

Rolf

[Matthias Scharwies]

Servus!

Ich bestreite damit nicht, dass hidden trotzdem eleganter ist. Man muss nur achtgeben, es kann nämlich passieren, dass hidden keinen Effekt hat.

Im Browser-Stylesheet steht

[hidden] { display: none; }

Wenn das auszublendende Element seine display-Eigenschaft über eine CSS-Regel im Autorenstylesheet bekommt (was bei Flexbox oder Grid immer so ist), dann ist diese Regel auf Grund der Kaskade spezifischer und die Browserregel hat keinen Effekt. Man muss sein eigenes Stylesheet dann um passende Regeln erweitern.

Danke für die Änderungen in der Referenz!

Es gibt als Rudiment der Eigenschaftsseiten noch:

• CSS/Tutorials/visibility
• CSS/Tutorials/opacity

Hier im display-Tutorial findet sich eher versteckt eine Abgrenzung:

CSS/Tutorials/Ausrichtung/display#Abgrenzung_zum_hidden-Attribut

Sollte man das in ein eigenes Kapitel/Tutorial packen?

Titel: Elemente verstecken – display: none oder hidden?

Deshalb kann es noch sinnvoller sein, eine eigene Klasse vorzusehen, die den Sachverhalt "wird gerade nicht gebraucht" darstellt und mit geeigneter Spezifität eine CSS Regel aktiviert, die die nötigen Styles zuweist. Diese Klasse kann man dann mittels classList.toggle bedarfsweise aktivieren.

topLink.classList.toggle("out-of-screen", entry.isIntersecting);

Das könnte dann auch da rein.

Herzliche Grüße

Matthias Scharwies

[Rolf B]

Hallo Matthias,

Sollte man das in ein eigenes Kapitel/Tutorial packen?

Ja, Tutorials/visibility und Tutorials/opacity gehören in einen gemeinsamen Artikel "Sichtbarkeit von Elementen".

Darin kann man auch auf display:none und bessere Alternativen eingehen, das Konzept visually-hidden beschreiben und musterimplementieren, und auch erklären, wie man Elemente vor Screenreadern "versteckt".

Wie meine Diskussion mit Gunnar zeigt, ist die Idee einer "show-this"-Klasse durchaus nicht selbsterklärend. Damit eine solche Klasse sinnvoll ist, braucht es den passenden königlichen Kontext, als universelles Gesetz ist sie nicht gedacht.

Rolf

[Matthias Scharwies]

Servus!

Hallo Matthias,

Sollte man das in ein eigenes Kapitel/Tutorial packen?

Ja, Tutorials/visibility und Tutorials/opacity gehören in einen gemeinsamen Artikel "Sichtbarkeit von Elementen".

Ist angelegt: CSS/Tutorials/Sichtbarkeit_von_Elementen

Grad noch gefunden: HTML/Tutorials/Formulare/Versteckte_Elemente - was es nicht alles gibt!

Herzliche Grüße

Matthias Scharwies

[Rolf B]

Hallo Matthias,

<input type="hidden"> gehört da nicht zu. Das sind Form-Elemente, mit denen der Server ganz bewusst Daten am Client platzieren kann, während ein Form bearbeitet wird. Beim POST des Forms kommen sie dann wieder zum Server zurück. Ein hidden input kann ein Ersatz für eine Session sein, es kann dazu dienen, Bots das Leben zu erschweren (ein Form wird nur akzeptiert, wenn in einem hidden input ein Einmalwert steht, den der Server parallel in der Session speichert), es kann aber auch genutzt werden, wenn auf einer Seite viele kleine Forms liegen und man in den POST-Daten eine Info haben will, welches davon submitted wurde.

Wird es als Sessionersatz verwendet, muss man das Element kryptographisch signieren, damit es nicht manipuliert werden kann.

Eine Bot-Abwehr ist damit nicht möglich, der Bot muss lediglich soweit aufgeschlaut werden, dass er das hidden-Element erkennt und mit postet. D.h. man fördert damit die Bot-Evolution, verhindert aber nicht wirklich was. Damals im carcassonne-online Forum hat es aber gereicht, um die Passwortdurchprobierbots zu stoppen, die uns wegen zu vielen Fehlversuchen ständig die User gesperrt haben 😁. Lang ist's her, länger als Corona 😟

Jedenfalls macht man solche Elemente nie sichtbar und sie sind auch nie für Assistenztechniken relevant.

Rolf

[einsiedler]

Hallo,

eine Frage, wenn ich diesen IntersectionObserver einsetzen würde: Wäre es auch möglich zu differenzieren, ich meine das was er überwacht, denn ich benutze mehrere nav-Elemente. Dann würden ja alle befeuert werden, was ich nicht möchte. Also eine nav samt ID oder CLASS - Angabe?

Gruß der einsiedelnde

[Matthias Scharwies]

Servus!

Hallo,

eine Frage, wenn ich diesen IntersectionObserver einsetzen würde: Wäre es auch möglich zu differenzieren, ich meine das was er überwacht, denn ich benutze mehrere nav-Elemente. Dann würden ja alle befeuert werden, was ich nicht möchte.

Schau mal hier:

const nav = document.querySelector('nav');

Also eine nav samt ID oder CLASS - Angabe?

Da könntest du doch auch einen anderen Selektor einsetzen, z.B.

const nav = document.querySelector('#main-nav');

Oder etwas ganz anderes, dann aber evtl. den Namen der Variablen, bzw. Konstanten ändern.

Herzliche Grüße

Matthias Scharwies

[einsiedler]

Hallo,

DANKE Dir, ich werde nun auch mal eine Variante a la Tischlerei soundso "bauen" um zu sehen wie dies aussähe und funktionieren würde.

Gruß der einsiedelnde

[nichtleer]

Der Skip-to-Top-link ist Teil des Headers:

Ich würde einen Skip-to-Top-Link strukturell am Ende einer Seite erwarten. Entweder als letztes Kind von main oder als erstes Kind von footer.

2020 zeigte Stephanie Eckles in ihrem Artikel Pure CSS Smooth-Scroll “Back to Top” (Direktlink zum Demo-Pen) eine Variante, die ohne JavaScript auskommt.

[Gunnar Bittersmann]

@@nichtleer

2020 zeigte Stephanie Eckles in ihrem Artikel Pure CSS Smooth-Scroll “Back to Top” (Direktlink zum Demo-Pen) eine Variante, die ohne JavaScript auskommt.

Was @einsiedler in diesem Thread auch schon erwähnte.

Kwakoni Yiquan

[einsiedler]

Hallo,

ich brauchte ein wenig Zeit, für mich, um selbst herumzufrickeln.

Genau diesen Artikel hatte ich u.a. ergoogelt und versucht diese Lösung umzusetzen.

Ich fand es einfach prima, so ohne jegliche scripte.

Erst wollte es nicht funktionieren, bis ich mal den übergeordneten Kindelementen position: relative und absolute erteilte und noch anderen Höhenanpassungen (Betrifft top und margin-top und das errechnen mit calc) geändert hatte und nun scheint es zu funktionieren:

Testseite-V10d.html

Getestet: Win10 FF 124.0.2 (64bit) / Opera One(Version: 108.0.5067.40) (64bit) / Edge 123.0.2420.81 (64-Bit) / Chrome 123.0.6312.123 (64-Bit)

zusätzlich: Win7 FF 115.9.1esr (64bit) / Edge 109.0.1580.140 (64bit)

Ich bitte euch die ihr vielleicht andere Browser-(Versionen) habt es auch zu testen.

Dennoch bleibt ein (kleines) Problemchen: Bei einem sehr schmalen Bildschirmfenster ist es zu sehen.

Meiner Meinung nach kann es nur am querie min-width: 33.75em liegen, da alles was darunter ist, halt nicht mehr grid ist und schlicht untereinander dargestellt wird. Aber der skip-to-top-Link und auch der footer stehen unatürlich weiter oben, und überlagert den main-Inhalt.

Das muss ich noch ändern eventuell max-width: 120em ausprobieren. Das aber erst morgen.

Ich habe mir aber auch die "OnePager mit skip-to-top-Link" - Lösung von Matthias genauer angeschaut.

Im Grunde gefällt mir auch diese Herangehensweise. Nur ist es nicht ganz meine natürliche Art herunterzusrollen, da beim leichten scrollen gleich die nächste Überschrift oben am Bildschirmrand klebt. Und ich frage mich wie das Verhalten wäre wenn die sections einen längeren Text oder gar Fotos oder Videos beinhalten.

Ich muss aber sagen das ein Vorteil dieser Lösung wäre, das jeweils unter den sections sich der skip-to-top-Link befindet, auch bei einem ganz schmalen Bildschirmfenster.

Wie auch immer, morgen gehts weiter.

Gruß der einsiedelnde

[einsiedler]

Hallo Matthias,

ich habe mir Deine "OnePager mit skip-to-top-Link" - Lösung genauer angeschaut.

Im Grunde gefällt mir auch diese Herangehensweise. Nur ist es nicht ganz meine natürliche Art herunterzusrollen, da beim leichten scrollen gleich die nächste Überschrift oben am Bildschirmrand klebt.

Und ich frage mich wie das Verhalten wäre wenn die sections einen längeren Text oder gar Fotos oder Videos beinhalten.

Ich muss aber sagen das ein Vorteil dieser Lösung wäre, das jeweils unter den sections sich der skip-to-top-Link befindet, auch bei einem ganz schmalen Bildschirmfenster.

Ja, so könnte man es definitiv auch machen, villeicht gewöhne ich mich mit der Zeit an diese Art des "scrolling".

Gruß der einsiedelnde