Ziel der Sprungmarke unter Sticky Menu

[marctrix]

Hej alle,

noch kann ich die Seite nicht zeigen, aber ich denke man versteht das Problem auch so: Auf einer Seite (one pager) mit einem Menü, das oben an der Seite fest steht, möchte ich an bestimmte Stellen springen können. Wenn ich ein Ziel mit #foo springe, landet das Ziel am oberen Rand des Viewport und die Überschrift "foo" ist nicht zu sehen, weil vom Menü überdeckt.

Hat jemand eine Idee, wie ich das vielleicht mit CSS hinbekomme? Irgendwie bin ich im Feiertags-Dauer-Suppen-Koma und meine Gehirnwindungen sind vollkommen verzuckert.

Vielleicht geht es auch nur mit JS?

Da es eine WP-Seite ist, wäre ein PageBuilder die einfachste Lösung, aber bisher habe ich alle Kundenwünsche mit ein paar Zeilen eigenem CSS umgesetzt und möchte weiter drauf verzichten.

Marc

[marctrix]

Hej marctrix,

Da es eine WP-Seite ist, wäre ein PageBuilder die einfachste Lösung, aber bisher habe ich alle Kundenwünsche mit ein paar Zeilen eigenem CSS umgesetzt und möchte weiter drauf verzichten.

Hat sich erledigt, wird vermutlich doch ein pagebuilder. Sonst muss man zu viel händisch machen. Auch der richtige Menü-Eintrag muss ja hervorgehoben usw…

Werde die fertige Lösung dafür nutzen…

Marc

[Raketenwissenschaftsversteher]

Hat jemand eine Idee, wie ich das vielleicht mit CSS hinbekomme?

So?

.abschnitt:target {
    top: 5rem;
    bottom: 3rem;

[marctrix]

Hej Raketenwissenschaftsversteher,

Hat jemand eine Idee, wie ich das vielleicht mit CSS hinbekomme?

So?

.abschnitt:target {
    top: 5rem;
    bottom: 3rem;

Funktioniert nicht…

Ist doch aktuell. Das Problem tritt auch (noch) mit Pagebuilder auf - ich dachte, der kümmert sich drum… - offenbar weiß der nichts von dem Menü und dessen Höhe.

Marc

[JürgenB]

Hallo Marc,

hast du mal versucht, dem Sprungziel ein margin-top zu geben?

Gruß
Jürgen

[Gunnar Bittersmann]

@@JürgenB

hast du mal versucht, dem Sprungziel ein margin-top zu geben?

Und wieviel soll’s denn sein? Da die Höhe des feststehenden Bereichs unbekannt ist, kann der Versuch nur scheitern.

LLAP 🖖

[JürgenB]

Hallo Gunnar,

also bei mir ist die Höhe der Navigationsleiste bekannt. Ich bin davon ausgegangen, das es bei Marc auch so ist.

Gruß
Jürgen

[Gunnar Bittersmann]

@@JürgenB

also bei mir ist die Höhe der Navigationsleiste bekannt.

Das kann zwei Ursachen haben:

1. Bei dir liegt ein besonderer Spezialfall vor, der sich aber nicht verallgemeinern lässt.

2. Du hast nicht beachtet, dass wie es bei dir aussieht wenig darüber sagt, wie es bei anderen aussieht. (Du kannst weder die verwendete Schriftart noch die verwendete Schriftgröße kennen.)

Ich bin davon ausgegangen, das es bei Marc auch so ist.

Das lässt mich Fall 2 vermuten.

LLAP 🖖

[marctrix]

Hej JürgenB,

hast du mal versucht, dem Sprungziel ein margin-top zu geben?

Ja, das geht auch (wie der Vorschlag von Raketenversteher).

Ist zwar nicht schön mit der Lücke darüber, aber es gibt noch ein größeres Problem: beim Sprung zur nächsten sprungmarke springt er an die richtige Stelle, aber weil dann der Abstand von dem Element fehlt, dass vorher die pseudoklasse target hatte (und jetzt nicht mehr) liegt die sprungmarke dann wieder hinter dem Menü.

Man müsste also jedesmal den margin verdoppeln - mal abgesehen davon, dass das unerwünschte magic numbers sind (im Menü könnte ja was umbrechen und zweizeilig werden…)

Liegt wohl doch nicht an meinem Suppenkoma - ist nicht so trivial wie anfangs gedacht.

Ich nehme auch Lösungen mit JS…

Marc

[Gunnar Bittersmann]

@@marctrix

Auf einer Seite (one pager) mit einem Menü, das oben an der Seite fest steht, möchte ich an bestimmte Stellen springen können. Wenn ich ein Ziel mit #foo springe, landet das Ziel am oberen Rand des Viewport und die Überschrift "foo" ist nicht zu sehen, weil vom Menü überdeckt.

Hat jemand eine Idee, wie ich das vielleicht mit CSS hinbekomme?

body { height: 100vh } und das main-Element scrollbar machen (aber nur, wenn genügend Höhe vorhanden ist).

☞ Beispiel

Die Scrollbar geht dann nicht über die gesamte Viewporthöhe, was ja auch korrekt ist.

Ansonsten, ja, mit JavaScript.

LLAP 🖖

[marctrix]

Hej Gunnar,

@@marctrix

Auf einer Seite (one pager) mit einem Menü, das oben an der Seite fest steht, möchte ich an bestimmte Stellen springen können. Wenn ich ein Ziel mit #foo springe, landet das Ziel am oberen Rand des Viewport und die Überschrift "foo" ist nicht zu sehen, weil vom Menü überdeckt.

Hat jemand eine Idee, wie ich das vielleicht mit CSS hinbekomme?

body { height: 100vh } und das main-Element scrollbar machen (aber nur, wenn genügend Höhe vorhanden ist).

☞ Beispiel

Die Scrollbar geht dann nicht über die gesamte Viewporthöhe, was ja auch korrekt ist.

Sehr schöne Idee! - Vielen Dank. Muss bei mir noch ein bisschen tüfteln, weil das HTML nicht so schön ist (immerhin gibt es einen header und ein div als einzige Kinder eines Containers). Es klappt zwar, aber beim Scrollen markiert man alles im div nach dem header (das Menü ist nicht mehr sticky – ich kann fremden Code nicht leiden. Keiner arbeitet so sauber, dass es Spaß macht damit zu arbeiten)…

Aber nicht dein Problem, die Idee war erst einmal entscheidend!

Marc

[marctrix]

Hej Gunnar,

läuft. Noch mal vielen Dank! Keine Ahnung, ob und wann ich auf die Idee gekommen wäre. Wenn man die Lösung kennt, scheint es ja naheliegend, aber ich bin mir sicher, da hätte ich noch Stunden dran getüftelt…

Marc

[Gunnar Bittersmann]

@@marctrix

Wenn man die Lösung kennt, scheint es ja naheliegend, aber …

Das ist die Krux an so manchen Problemen. 😆

Ich hab im Pen noch

@media (prefers-reduced-motion: no-preference)
{
	main { scroll-behavior: smooth }
}

ergänzt. So bekommt man animiertes Scrollen ohne JavaScript (aber nicht für Nutzer, die das nicht wollen).

LLAP 🖖

[Der Martin]

Moin,

So bekommt man animiertes Scrollen ohne JavaScript (aber nicht für Nutzer, die das nicht wollen).

und das ist gut so.[tm]

Ich vermute, dass dieses Feature vorwiegend auf Mobilgeräte abzielt. Aber solche Effekte wie "smooth scrolling" (im deutschen Windows heißt es euphemistisch "Optimierter Bildlauf") stelle ich auch bei Desktop-Systemen sofort ab, wenn es möglich ist.

Ich weiß nicht, was manche so toll daran finden; mir gehen derartige Effekte auf die Nerven. Ich möchte sofort ans Ziel kommen, nicht langsam hingleiten. Dabei geht es mir nicht einmal um die paar Zehntelsekunden, die es länger dauert - ich finde einfach die Tatsache an sich absurd, dass man ein Ereignis bewusst hinauszögert und dafür sogar noch Rechenleistung verbrät.

Schönen Sonntag noch,
 Martin

[Gunnar Bittersmann]

@@Der Martin

Ich weiß nicht, was manche so toll daran finden; mir gehen derartige Effekte auf die Nerven. Ich möchte sofort ans Ziel kommen, nicht langsam hingleiten. Dabei geht es mir nicht einmal um die paar Zehntelsekunden, die es länger dauert - ich finde einfach die Tatsache an sich absurd, dass man ein Ereignis bewusst hinauszögert

Der Grund dürfte Orientierungshilfe sein – eine visuelle Darstellung von „du bleibst auf der Seite, gelangst auf dieser zu einer anderen Stelle“.

Ich will dir das Feature gar nicht schmackhaft machen. Es ist gut, dass der Nutzer die Wahl hat.

und dafür sogar noch Rechenleistung verbrät.

Es sollte mich nicht wundern, wenn ein Mobilgerät (und da zähle ich hier Laptops hinzu) im Batteriesparmodus kein smooth scrolling macht.

LLAP 🖖

[Der Martin]

Hallo,

ich finde einfach die Tatsache an sich absurd, dass man ein Ereignis bewusst hinauszögert

Der Grund dürfte Orientierungshilfe sein – eine visuelle Darstellung von „du bleibst auf der Seite, gelangst auf dieser zu einer anderen Stelle“.

das ist eine akzeptable Erklärung für den Einzelfall "einem Link auf einer Webseite folgen". Aber ... ist nicht gerade das verzögerungsfreie Springen zum Ziel ein Indiz dafür, dass man auf derselben Seite bleibt und die Zielseite nicht erst geladen werden muss?

Abgesehen davon - ich erwähnte es schon - ist dieses Feature auch für manche Desktop-Betriebssysteme und deren native Anwendungen oft voreingestellt (z.B. Windows). Wenn ich in einem Word-Dokument mehrmals die PageDown-Taste drücke (oder mit der Maus auf den Scrollbalken klicke), dann möchte ich doch schnell an die gewünschte Stelle ein paar Absätze weiter unten kommen, und nicht langsam dorthin eiern. Auch wenn im Deutschen von Bildschirmrollen gesprochen wird.

Marco, der Window-Manager von meinem Linux Mint, hatte das in der Basiseinstellung auch. Noch unangenehmer fand ich aber das Bouncing beim Verschieben von Fenstern mit der Maus: Ein Bewegungsverhalten, als würde man das Fenster an einem Gummiband ziehen. Träge, leicht verzögert und mit Überschwinger. Das braucht IMHO wirklich niemand.

Ich will dir das Feature gar nicht schmackhaft machen.

Das würde dir auch nicht gelingen. :-)

Es ist gut, dass der Nutzer die Wahl hat.

Sag ich doch.

und dafür sogar noch Rechenleistung verbrät.

Es sollte mich nicht wundern, wenn ein Mobilgerät (und da zähle ich hier Laptops hinzu) im Batteriesparmodus kein smooth scrolling macht.

Zumindest ein unter Linux Mint oder Windows 10 laufender Laptop macht da keinen Unterschied. Das kann ich aus eigener Erfahrung sagen.

Ciao,
 Martin