Sticky Nav verhindert das Anzeigen von Ankerlinks – ein paar Zeilen Inline‑CSS lösen das Problem sauber

Wenn man in einem Dokument (Blog, Wiki, Anleitung) einen Fußnoten‑Link oder ein Inhaltsverzeichnis (TOC) anklickt, springt der Browser zu #some-id und richtet das Element mit dieser ID exakt an der Oberkante des Viewports aus.

Steht jedoch oben ein position: sticky‑ oder fixed‑Navigations‑Bar, wird das Element zwar an die Oberkante gescrollt, aber der eigentliche Inhalt bleibt hinter der Nav verborgen.

Dieses Problem ist im Front‑End‑Bereich häufig, aber für Backend‑ oder Full‑Stack‑Entwickler kann es irritierend sein, wenn ein Link zwar funktioniert, der Inhalt aber nicht sichtbar ist.

Hier stelle ich die Methode vor, die ich am häufigsten verwende: ein paar Zeilen Inline‑CSS auf der problematischen Seite – die einfachste und sofort wirksame Lösung.

Warum passiert das?

Das Standardverhalten des Browsers ist wie folgt:

  • Wenn die URL zu .../page#target geändert wird,
  • sucht der Browser nach dem Element id="target,
  • und scrollt so, dass der Anfang dieses Elements an der Oberkante des Scroll‑Containers (normalerweise der Viewport‑Top) ausgerichtet ist.

Eine sticky Nav wird jedoch über dem Viewport gerendert, sodass das Ziel‑Element hinter der Nav verborgen bleibt.

Beispiel, bei dem der Anker von einer sticky Nav verdeckt wird

Die einfachste Lösung: scroll-margin-top (ein wenig Abstand zum Element)

Wenn man dem Ziel‑Element, das durch einen Anker erreicht wird, scroll-margin-top gibt, versucht der Browser, das Element nicht an die Oberkante, sondern etwas darunter zu positionieren.

Inline‑CSS minimal anwenden (empfohlen)

Auf der problematischen Seite kann man in den <head> oder in die Template‑Datei folgenden Code einfügen:

<style>
  :root { --sticky-nav-h: 64px; } /* Höhe der Nav anpassen */
  [id] { scroll-margin-top: calc(var(--sticky-nav-h) + 12px); }
</style>
  • --sticky-nav-h: Höhe der sticky Nav
  • + 12px: ein kleiner Freiraum, damit nichts zu knapp erscheint (nach Belieben anpassen)

Durch die Anwendung auf [id] werden alle Ankerziele auf der Seite automatisch korrigiert. Wenn das zu weitreichend ist, kann man die Zielgruppe einschränken.

Zielgruppe einschränken für mehr Sicherheit

Beispiel: Nur im Artikel‑Bereich anwenden

<style>
  :root { --sticky-nav-h: 64px; }
  .article [id] { scroll-margin-top: calc(var(--sticky-nav-h) + 12px); }
</style>

Beispiel: Wenn das TOC hauptsächlich zu h2/h3 springt

<style>
  :root { --sticky-nav-h: 64px; }
  .article h2[id], .article h3[id] {
    scroll-margin-top: calc(var(--sticky-nav-h) + 12px);
  }
</style>

Ergänzende Option: scroll-padding-top (Standard‑Padding für den Container)

scroll-padding-top gibt dem Scroll‑Container einen sicheren oberen Bereich für Snap‑ oder Fragment‑Navigation. In der Praxis ist scroll-margin-top intuitiver, aber die Kombination kann bei komplexen Layouts stabiler sein.

<style>
  :root { --sticky-nav-h: 64px; }
  html { scroll-padding-top: calc(var(--sticky-nav-h) + 12px); }
</style>
  • Schnell für die gesamte Seite, wenn man alle Anker korrigieren möchte.
  • Für gezielte Steuerung einzelner Elemente bleibt scroll-margin-top die bessere Wahl.

Legacy‑Trick für maximale Kompatibilität: ::before‑Pseudo‑Element nutzen

Eine alte, aber bewährte Methode ist, vor dem Ziel‑Element ein unsichtbares Block‑Element einzufügen, das den Abstand zur Nav erzeugt.

<style>
  :root { --sticky-nav-h: 64px; }

  .anchor-target::before {
    content: "";
    display: block;
    height: calc(var(--sticky-nav-h) + 12px);
    margin-top: calc(-1 * (var(--sticky-nav-h) + 12px));
    visibility: hidden;
    pointer-events: none;
  }
</style>

Verwendung:

<h2 id="install" class="anchor-target">Installation</h2>
  • Vorteil: Funktioniert zuverlässig, da es auf CSS‑Prinzipien basiert.
  • Nachteil: Erfordert eine Klasse und etwas mehr Aufwand bei der Auswahl.

Heutzutage sollte man zuerst scroll-margin-top ausprobieren und bei Bedarf den ::before‑Trick einsetzen.

JavaScript‑Lösungen existieren, aber Inline‑CSS ist oft die bessere Wahl

Man kann auch scrollIntoView() und anschließend window.scrollBy(0, -navHeight) nutzen. Doch in vielen Fällen ist CSS die sauberere Lösung.

  • Für Dokumente oder statische Seiten mit vielen Fußnoten/TOC
  • Wenn man ohne Framework‑ oder Routing‑Änderungen schnell auf einer Seite korrigieren möchte
  • Wenn der Wartende nicht unbedingt ein Front‑End‑Experte ist

Ein paar Zeilen Inline‑CSS sind unabhängig von Bibliotheken, leicht zu debuggen und lassen sich problemlos zurücknehmen – ideal für Dokumentationsseiten.

Praktische Checkliste

  • Sticky‑Nav‑Höhe exakt bestimmen
  • Bei responsivem Design kann man --sticky-nav-h pro Breakpoint anpassen.
  • Anwendungsbereich nicht zu breit wählen
  • [id] global ist bequem, aber .article [id] oder spezifischere Selektoren sind oft sinnvoller.
  • Ein wenig Freiraum (+8–16 px) einbauen
  • Nur die Nav‑Höhe kann manchmal zu „klein“ wirken.

Fazit: Meine bevorzugte One‑liner‑Lösung

Für die meisten Seiten reicht es, die folgende Inline‑CSS‑Block einzufügen:

<style>
  :root { --sticky-nav-h: 64px; }
  .article [id] { scroll-margin-top: calc(var(--sticky-nav-h) + 12px); }
</style>

Damit werden TOC, Fußnoten und Deep‑Links in der Regel sofort korrigiert. Ich hoffe, diese Anleitung hilft Entwicklern, die Nav‑Verdeckungs‑Probleme schnell zu beheben.

Weitere hilfreiche Artikel - Warum man bei <img> width und height angeben sollte - Backend‑Ingenieure sollten mindestens diese Front‑End‑JS‑Methoden kennen