# 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? {#sec-3d359517ce38}
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 Oberkante des Viewports) ausgerichtet ist.
Eine Sticky-Nav wird jedoch über dem Viewport gerendert, sodass das Ziel‑Element hinter der Nav verborgen bleibt.
---
## Die einfachste Lösung: `scroll-margin-top` (ein wenig Abstand zum Element) {#sec-1be8dffe3841}
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) {#sec-a6247ae187d6}
Auf der problematischen Seite kann man in den `` oder in die Template‑Datei folgenden Code einfügen:
```html
```
* `--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.
### Geltungsbereich einschränken für mehr Sicherheit {#sec-a361296aa6ac}
Beispiel: Nur im Artikel‑Bereich anwenden
```html
```
Beispiel: Wenn das TOC hauptsächlich zu `h2/h3` springt
```html
```
---
## Ergänzende Option: `scroll-padding-top` (Standard‑Padding für den Container) {#sec-649a0cca0b38}
`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.
```html
```
* 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 {#sec-70f2c4a21286}
Eine alte, aber bewährte Methode ist, vor dem Ziel‑Element ein unsichtbares Block‑Element einzufügen, das den Abstand zur Nav erzeugt.
```html
```
Verwendung:
```html
Installation
```
* 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 {#sec-7bd39bacd041}
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 Maintainer 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 {#sec-34f0cdc2dc59}
* **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 {#sec-0efd101c9692}
Für die meisten Seiten reicht es, den folgende Inline‑CSS‑Block einzufügen:
```html
```
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 `![]()
` width und height angeben sollte](/ko/whitedec/2025/12/24/why-specified-width-height-in-img-tag/)
- [Backend‑Ingenieure sollten mindestens diese Front‑End‑JS‑Methoden kennen](/ko/whitedec/2025/11/23/backend-engineer-minimum-frontend-js-methods-modules-best-5/)