Nützliche Button und Bilder

– mitunter aber zeigt sich das Problem des gegenseitigen Überlagerns von Elementen: Zum Beispiel „Scroll Back To Top“-Button und Bilder – insbesondere bei Handys und ebenda im Querformat, das offenbar genutzt wird, um Fotos ohne Zoom rasch etwas größer zu sehen.

Ein Script oder pure CSS + HTML bieten sich als Lösungen für solche Button „zum Seitenanfang“ an …

Script oder kein Script ist hier die Frage …

Obgleich in der Struktur einfach und ohne nennenswertes Datenvolumen mag ich weiterhin keine Scripte auf meinen Seiten. Wer da gelassener ist, findet Lösungen mit jQuery / JavaScript, welche in der Regel den Vorteil haben, erst dann den Button zu zeigen, wenn der Nutzer schon ein Stück weit scrollte, also dann, wenn ein „zurück zum Seitenanfang“ Sinn macht.

Mein Button ist diesbezüglich plump: Seite auf, „Back To Top“ bietet sich schon an; es sei denn, er wird von Fotos überlagert.

Ich nutze eine schlichte Lösung via HyperText Markup Language und Cascading-Style-Sheets (CSS).

Die Un-Logik, dass der „nach-oben“ Button schon da ist, wenn der Mensch noch am Anfang der Seite ist, dies ist nicht wirklich mein Problem – sag ich mir, da sieht der Nutzer gleich, bevor er scrollt, er kann auch rasch wieder nach oben …

Ich nutze diese Top-Button auf anderen Websites gern – insoweit ich nicht mit der Tastatur unterwegs bin. Via Tastatur geht alles rascher und (theoretisch) unabhängiger vom Design einer Website. Will ich aber die Hände frei haben, so ist die viel gelassenere Maus toll! Ich mag dieses Maus-Ding, zumal unter Openbox …

Der „Back To Top“-Button und der „Scroll Back To Top“-Button

Die Schreibweise dieser Button via HTML und die Anweisungen für das Design sind denkbar einfach.

Der Link

<a href="#seitenanfang">zum Seitenanfang</a>

Ich mag es, wenn die Dinge einen Namen bekommen, der leicht zu verstehen ist: „zum Seitenanfang“.

Varianten: href="#" (hier braucht man den nächsten Schritt nicht: einen Anker für den Link), href="#top" …

… der Anker des Links
<body id="seitenanfang">

Link + Anker: Der „Back To Top“-Button ist fertig.

Nachteil dieser „Back To Top“-Button: Browser speichern dies als Link; anders als das Öffnen eines Details-Tag.

CSS – „Back To Top“-Button – statisch oder dynamisch?

… also die Frage: Wo platziere ich den „Nach oben“-Button zweckdienlich?

„Back To Top“-Button können auch statisch unterhalb abgeschlossener Inhaltsbereiche (zum Beispiel eines Artikels) positioniert werden – bei einem vorhandenen Inhaltsverzeichnis macht es natürlich mehr Sinn, eher auf diesen Inhaltsüberblick via Link unterhalb des abgeschlossenen Artikels zu verweisen:

<a href="#inhaltsübersicht">zur Inhaltsübersicht</a>

Zusammen mit:

html {scroll-behavior: smooth;}

… ist das Ergebnis angenehm zu bedienen: Der „Scroll Back To Top“-Button ist fertig.
Wie auch der geschmeidige Sprung zum Seitenanfang.

Solche schlichten Lösungen reichen vollkommen aus!

Eine statische Lösung für einen „Back To Top“-Button am Fuß kurzer Seiten ist auch keine Schande, es bezeugt eher ein kluges, nützliches sowie sparsames Design des Seiteninhabers …

Lange und Kurze Seiten auf einer Website – und nun?

Enthält die Website indessen lange und kurze Seiten, muss man sich entscheiden: durchgängig die schlichte statische Lösung oder eine „dynamische“ Lösung mit position: fixed; für den Button oder gar eine Lösung mit Script.

Ich sehe diese drei Lösungen als gleichwertig an – nur einheitlich sollte die eigene Lösung wohl für die gesamte Website dann sein. Und Scripte sollten eingespart werden, wo immer es geht …

Auf einen solchen „Nach oben“ Button verzichten zu wollen, halte ich für nicht hilfreich; auch auf kurzen Seiten sollte ein solcher Button verfügbar sein; da mag er unten stehen und statisch sein.

Eine auf dem Desktop kurz wirkende Seite ist auf Handy dann doch rasch lang und länger – der „Top“-Button ist ein feiner, standardisierter Service.

Das Design solcher Button

(…) jeder nach seiner Façon – ein alter Fritz!

Über Geschmack lässt sich nicht disputieren, so auch der Philosoph Kant.
Die Geschmäcker von Layouts (einer Website) sind halt verschieden …

Aber „disputieren“, lieber Herr Kant, lässt sich über Geschmack vortrefflich:

Eine „goldene Regel“ für jedes Layout sei, dass der Focus auf den Inhalt stets Priorität hat – und exemplarisch solche Button via Überdesign nicht ablenken sollten …

Mein „Scroll Back To Top“-Button

Ich habe viele kurze Seiten. Aber auch viele lange Seiten. Da ich Scripte nicht mag, blieb für die langen Seiten meiner Website eher die Variante position: fixed; für den „Nach oben“-Button – und dann stringent halt für alle Seiten:


.footer-seite a[href*="#seitenanfang"] {
  position: fixed;
  bottom: 0;
  right: 15%;
  z-index: 1;
  min-width: 15em;
  padding: .75em;
  background-color: rgb(251 251 251 / .9);
  border-radius: .2em;
}

+ Innenabstände
+ Schriftfarbe, Schriftgröße
+ border, border-radius …

Meine Übersichtsseite Kreuzungen mit Naturrosen beispielsweise braucht einen solchen „Nach oben“-Button [ebenda etwas scrollen, bevor er erscheint]. Auf solchen langen Seiten ist man mitunter schon nach einem Drittel müde gesehen und will „nach Hause“ – so freut man sich über jeden „Nach oben“-Button.

Auf meinen vergleichsweise kleinen Sorten-Seiten wird dieser „fixed-Button“ bitte gnädig zur Kenntnis genommen.

Die Probleme des (dynamischen) „Back To Top“-Button

… also auf meiner Website war es ein erstes Problem: bei schmalen, kleinen Monitoren / Viewports überlagert(e) dieser Button mitunter Fotos. Auch dies geht via Script leicht aus der Welt. Aber eben auch via HTML und CSS.

Das Problem, das es zu lösen galt: Bei den (langen) Übersichtseiten (voll Bilder) soll der Button stets verfügbar sein, bei den (kleinen) Sorten-Seiten (mit großen Bildern) aber kann er regelrecht stören: er überdeckt die größeren Fotos, insbesondere bei kleinen Viewports eines Handys.

position: relativ; + z-index + background-color

CSS bietet oftmals recht einfache und gute Lösungen für derlei Design-Probleme: Die Bildergalerien (oder einzelne Bilder) werden schlicht relativ positioniert, bekommen einen Überlagerungs-Index der höher ist als der des „Nach oben“-Button.
Und damit die Überlagerung „Bilder über Button“ (oder halt umgekehrt) auf Fläche klappt, bekommen beide noch eine Hintergrundfarbe.

Die CSS der Bildergalerien bei mir, die relevanten Stellen sind hier fett gekennzeichnet:


.gal,
.grossfotos,
.gridmaxzwei {
  display: grid;
  grid-template-columns: repeat(auto-fit,minmax(330px,1fr));
  gap: 1em;
  margin: 1% auto;
  max-width: 130em;
  position: relative;
  z-index: 2;
  background-color: #fdfdfd;
}

Für einzelne Bilder (innerhalb von Texten zum Beispiel) greift de facto die gleiche Anweisung (und zum Teil für ganze Blöcke, zum Beispiel bei Details-Tag):


article img,
aside img,
main details,
header img,
.imgr,
.imgl,
section img,
.zindex-bilder {
  position: relative;
  z-index: 2;
  background-color: #fdfdfd;
}

Der „Nach oben“-Button bekommt einen kleineren Z-Index als die Bilder und wird folglich bei „Kollision“ überlagert: die Fotos haben Vorrang.

Beispiel der Überlagerung durch ein Details-Tag.
Scrollen Sie (bei schmalem Monitor) etwas hin und her, um zu sehen, dass der „Back To Top“-Button beim geschlossenen wie beim geöffneten Details-Tag verdeckt wird:

The Soul of the Rose, aka My Sweet Rose, 1908 The Soul of the Rose, aka My Sweet Rose, 1908.

Auf einem Desktop mag alles dies unbedeutend sein – nicht aber bei kleineren bis kleinen Monitoren, Handys halt.

Und zu meiner Schande: Ich bin ein hoffnungsloser Monster-Desktop-Surfer! Ich habe kein Smartphone oder derlei. Aber einen großen Monitor.
Die Handy-Problematik überlagernder Elemente gelang selbst bei Handy-Tests nicht in mein Hirn – da bin ich irgendwie blind. Desktop-verwöhnt könnte man auch schreiben …

Denke aber, meine schlichte HTML + CSS Lösung beseitigt zwar nicht alles Unfeine, jedoch sind die Fotos nun frei von Button zu sehen – und die Button doch zugleich verfügbar.

Anhang Screenshots Handyformat

Größere Fotos (auf den Sorten-Seiten) überlagern den „Nach oben“-Button – so soll es sein: Screenshot Handyquerformat mit Rosenbilder, die den „Nach oben“-Button überlagern.

Im unteren Artikelbereich aber bis Seitenende ist der Button verfügbar; er rutscht sozusagen aus der obigen Galerie heraus: Fuß-, Textbereich des oberen Bildes, „Nach oben“-Button ist sichtbar, nutzbar.

Ohne einen solchen z-index für die Galerie, es kann passieren, dass der Button über Teile eines Fotos liegt, dies ist weniger schön (hier via Firefox-Inspektor den z-index der Galerien deaktiviert): Ausschnitt des ersten Fotos mit Button, der Teile eines Fotos überlagert.

Rosen-Übersichtsseite, Test über Firefox Querformat Handy, hier erscheint mir der Button sinnvoll und er kann durchaus groß sein; er stört bei den Thumbnails nicht wirklich: Übersichtseiten der Rosen im Handy-Querformat mit kleinen Fotos und Kurzbeschreibung sowie nutzbaren Button.

Langformat, Button hilft dann schon (bei Hundert und mehr Rosen-Kurzporträts auf einer Seite) und stört nicht, im Gegenteil, er signalisiert eine Art Anker: Übersichtseiten der Rosen im Handy-Langformat mit kleinen Fotos und Kurzbeschreibung sowie nutzbaren Button.

Anmerkung

Scroll Snap ist nicht mein Ding – ähnlich wie durch Scripten, mag ich es nicht, wenn mir ein Arbeitsfluss aufgezwungen wird.
Solche möglichen Gestaltungen aber seien erwähnt und behutsam eingesetzt gewiss hier und da auch zweckdienlich..

Indessen halte ich Scroll Buttons als eine der sinnfreien Folgen eines noch sinnfreier gemachten Designs: das animierte ständige Ein- und Ausblenden von ehemals funktionstüchtigen (statischen) Scrollbalken ist bekloppt! Und nun sollen Scripte es wieder richten …

Hier muss mindestens die Lösung her, dass die Nutzer entscheiden können, wie sie es mit Scrollbalken und Co. halten wollen …

Design gehört in die Hände der Nutzer … wie das Schreiben und die Darstellung einer Website.

Weitere Link-Angebote

Top-Links bei OnePager – mit und ohne JavaScript – bei SELFHTML.

W3schools – „#top“ mit einem Script …