Feste Seitenkopfzeile und In-Page-Anker im Vergleich zu Tripit Slate

Question

Diese Frage bezieht sich darauf, gehashte URLs (wie mydomain.com/somepage#SomeAnchor) aus einem festen Seitenkopf heraus zu scrollen, wenn diese URLs Sprungziele sind. Es ist ein Ableger von this answered question - aber ich frage mich, ob jemand seine Antworten bekommen hat, um vollständig am Tripit Slate Dokument-Publishing Framework zu arbeiten?

This Slate-based site nicht unsere ist, aber es zeigt unsere Lage:

• Wenn Sie einen Link von der linken Navigations klicken, wird die Mitte Textspalte scrollt zu Ihrem gewählten Position. Alles ist gut.

• Versuchen Sie jedoch, auf einen Link im Fließtext zu klicken. Z. B. von http://buddycloud.com/api#accounts, klicken Sie auf die push notification Verbindung. Sie scrollen zu einer völlig anderen Unterüberschrift. Das von dir gewünschte Ziel hat eigentlich den Fokus, aber es ist unter der oberen Navigationsleiste versteckt. (Scrollen Sie nach oben und Sie es sehen werden.)

Unsere linken Navigations Links sauber arbeiten, wie die Buddycloud-Website. Dank Sidnicious' 4086107 answer haben wir ein unsichtbares Pseudo-Element über all unseren Überschriften platziert, wie von Nicolas Gallagher entwickelt. Hier ist die CSS-Klasse:

.jumptarget::before { 
    content:""; 
    display:block; 
    height:85px; /* fixed header height*/ 
    margin:-85px 0 0; /* negative fixed header height */ 
} 

Und hier ist, wie wir es in unseren Positionen gehören:

## <span class="jumptarget" id="SomeAnchorName"> SomeHeading </span> 

das ist, was für das linke nav gut funktioniert. Von CSS-Tricks haben wir gelernt, warum dennoch versagt es für „in-Seite“ gehasht Links:

Wenn eine Verbindung einen Hash enthält, wie folgt aus: <a href="#section-two">Section Two</a> ... wird das Browserfenster scrollen .. .to die minimale mögliche Position, um dieses Element vollständig sichtbar zu machen. ... bündig mit dem oberen Rand des Browserfensters. Dies kann ... sein, im Falle eines Fixed-Position, bleiben-oben-Header, sehr problematisch.

In der Tat sieht unser Fixed Top Nav wie Buddycloud (unsere ist 82 px hoch). Und unsere In-Page-Hash-Links verstecken sich darunter, genauso wie ihre.

Mit zwei wichtigen Ausnahmen: Erstens, in Fällen, in denen das Ziel „gehasht“ URL im gleichen Abschlags-Datei als Outbound-Link befindet, lugt das Ziel sauber aus unter dem festen Header, wie links-nav Links machen. (. Auf der Quellenseite, Schiefer speichert alle Inhalte als .md Dateien) Diese lokalisiert das Problem: Link Ziele verbergen nur wo Slate zu einem separaten Ziel .md Datei zu durchlaufen hat, und dann #<SomeAnchorName> verketten die URL zu vervollständigen.

Zweitens haben wir haben einen Hack gefunden, der alle "In-Page" hashed Links erhält, um unseren oberen Header zu löschen. Dazu werden unsere Überschriften in zwei Bereichen mit zwei Tags versehen. Der erste ist ein leerer Dummy-Bereich, der über dem eigentlichen Überschriftstext liegt, um das Scroll-Verhalten zu tricksen. (Es ist markiert mit unserer oben genannten jumptarget Klasse.) In der Überschrift selbst wenden wir einen separaten Bereich mit einer Klasse an, der einen linken Einzug vom ersten Hack korrigiert. Die Dual-Tagging sieht wie folgt aus:

<h2> 
    <span class="jumptarget" id="bogusN"> &nbsp; </span> 
    <span class="jumpleft"> Bogus Heading 2 </span> 
</h2> 

Aber obwohl dies unsere „in-Seite“ gehasht Links zeigt, ist es unsere linken Navigations vollständig bricht. Aufgrund einiger Interaktionen mit dem tocify linken Navigationsgenerator von Slate verhalten sich die auf diese Weise gekennzeichneten Überschriften wie folgt: (1) Verstecken Sie ihre Kinder im linken Navigationsbereich. (2) Wenn Sie darauf klicken, verhindern Sie, dass die Klasse jumptarget diese unter der oberen Kopfzeile abrollt. (3) Wenn Sie darauf klicken, reduzieren Sie deren Eltern im linken Navigationsbereich.

Also unser Dilemma ist das: Unser Update für Links von unserem linken Nav verlässt unsere In-Text-Links gebrochen. Wohingegen, unsere Reparatur für die in-Text-Links bricht unseren Link-Nav-Fix.

Wenn jemand dies global auf Tripit Slate oder tocify oder einem anderen Framework gelöst hat, wären wir sehr dankbar für Hinweise. Saubere CSS, hacky HTML oder jivey JavaScript - wir sind agnostisch. Vielen Dank!

[Update 7/13/16:] Hier ist das Skript, das unser Entwickler zu layout.erb hinzugefügt hat, um zu verhindern, dass Linkziele von einem persistenten Header versteckt werden. Wir testen, ob es für alle Links funktioniert. Kommentare sehr viel eingeladen:

<script> 
    var container = $('.page-wrapper .content'); 
    var body = $('body'); 
    var headerHeightPixels = 85; 

    container.on('click', function(event) { 
     var target = $(event.target); 

     if (target.is('a') && target.attr('href').charAt(0) === '#') { 
      setTimeout(function() { 
       $('body').scrollTop($('body').scrollTop() - headerHeightPixels) 
      }, 0); 
     } 
    }); 
</script> 

Answer 1

Tocify hat Parameter, die eingestellt werden kann, dass der Abstand an der Spitze des Scroll-Bereich steuern, wenn Sie auf einen Link auf der linken Panel klicken (das ToC-Panel, das erzeugt wird durch tocify.js) Dies ist dokumentiert here und es wird durch die ScrollTo-Taste im Toksi json gesteuert. Dies steuert jedoch nur die Positionierung des Scrollbereichs für die linke Spalte.

Obwohl Sie die gleiche Logik wie in "tocify" hinzufügen können, um den Bildlauf für Links im mittleren Bereich auf die gleiche Weise anzupassen wie "tocify". Für unseren Einsatz haben wir einen anderen Ansatz gewählt: Wir scrollen den oberen Kopfbereich von der Seite ab, wenn sich der Benutzer durch das Slate-Dokument bewegt. Unser Grund dafür ist, dass wenn ein Benutzer anfängt, ein langes Slate-Dokument herunterzuscrollen, es wütend verwendet und wir ihm so viel Grundbesitz wie möglich geben wollen, um so viele relevante Informationen wie möglich zu erhalten. Als wir uns die Kopfzeile ansahen, bot sie viele Seitenkontexte und hatte wenig mit dem Dokument zu tun, das gerade gelesen wurde. So, aber den oberen Header schwebend, bekommt der Leser mehr Grundbesitz und kann immer zu ihm zurückkehren, indem er nach oben scrollt.