„Dringend gesucht: Favicon. Abgängig seit: Jahren. Zuletzt gesehen: auf der Homepage. Besondere Merkmale: klein und schwer zu fassen.“ So (oder so ähnlich) könnte man die Lage, wie sie sich seit einer gefühlten Ewigkeit — und durchaus systemübergreifend — in diversen Hilfeforen darstellt, in einem Suchaufruf zusammenfassen.

Eigentlich ist es ein eher kleines Problem — nicht nur wegen der geringen Größe des Icons. Das große Problem scheint in diesem Fall zu sein, dass sich die Suchenden zuweilen selbst (und gegenseitig) im Weg stehen.

Aber der Reihe nach: Als „Favicon“ wird landläufig das kleine Bild bezeichnet das einerseits Browser und andererseits unterschiedliche mobile Endgeräte benutzen, um einzelne Webseiten oder „Apps“ für den Benutzer optisch leichter unterscheid– bzw. identifizierbar zu machen.

Sich in Binsenweisheiten zu ergehen bringt nichts

Im Prinzip ist es wirklich keine große Angelegenheit. Man speichert das Bild im Wurzelverzeichnis der Website ab, und referenziert die Datei im Kopf der einzelnen Seiten — so zumindest die gut verbreitete Theorie. Eine Standardübung, könnte man meinen.

Nur, von einem Standard scheinen wir auch hier noch weit entfernt zu sein. Im Netz werden gleich mehrere „Standards“ (und mehr als eine „richtige Umsetzung“, jede natürlich die einzige und beste) gehandelt — wohl je nachdem, wer von wem (und wann) die jeweilige Idee übernommen hat, und wie oft diese verbreitet wurde. Das Ergebnis lässt sich am besten mit zwei Worten zusammenfassen: Geplantes Scheitern.

Ja, manche Browser halten sich immer noch nicht an vermeintlich allgemeingültige Konventionen. Zur Kenntnis genommen und verkündet.

Ja, es kann schon darauf ankommen, welche Software im speziellen Fall verwendet wird. Zur Kenntnis genommen und verkündet.

Nein, es bringt gar nichts, sich darüber zu ärgern. Ein Ausgabegerät zu entwickeln, das alle vermeintlich allgemeingültigen Konventionen unterstützt und peinlich genau einhält, dauert länger als die Fehlersuche im speziellen Fall. Davon abgesehen, würden viele Websites in diesem Browser schlichtweg „verglühen“. (Diese Weisheit könnte unendlich oft verkündet werden, sie scheint nie zur Kenntnis genommen zu werden.)

Was bringt uns weiter?

Also, was bringt uns weiter, wenn das Favicon nur auf der Homepage dargestellt wird, nicht aber auf den Unterseiten der Website? (Ich darf davon ausgehen, dass wir alle wissen, dass wir hier von dynamisch erstellten Websites sprechen?)

  1. Nachsehen, ob das entsprechende Bild auch wirklich (also physisch) an angegebener Stelle liegt.
  2. Auf etwaige Tippfehler bei der Namensgebung des Bildes achten.
  3. Überprüfen, ob der angegebene Pfad zum Bild korrekt ist.
  4. Auf etwaige Tipp– oder Logikfehler bei der Pfadangabe achten.
  5. Überprüfen, welcher Konvention die verwendete Software bei der Auszeichnung von Verweisen (und Pfaden) folgt.

Wo befindet sich das Wurzelverzeichnis?

Es scheint sich auch nach Jahrzehnten noch nicht überall herumgesprochen zu haben: Als Wurzelverzeichnis (Engl., root; üblicherweise durch einen einzelnen Schrägstrich dargestellt) wird jene Ebene bezeichnet, in der die Index–Datei (index.html, index.php o.ä.) der Website am Server abgespeichert ist.

Beispiel: https://gwpachlatko.github.io/emwd verweist auf das Wurzelverzeichnis dieser Website und führt direkt zur Index–Datei (sofern diese vorhanden ist).

Denselben Effekt erzielt man, wenn man „root“ in der Webadresse mit angibt: https://gwpachlatko.github.io/emwd/. Der letzte Schrägstrich in dieser Adresse symbolisiert das Wurzelverzeichnis.

Wenn Sie beide Links ausprobiert (und dabei auf die Adresszeile des Browsers geachtet) haben, wissen Sie jetzt, dass der Server immer das Wurzelverzeichnis mit angibt — weshalb Sie es bei der Eingabe auch weglassen können. Server folgen im Allgemeinen nicht den Konventionen einzelner Designer — leider ist zuweilen auch die Umkehrung dieser Weisheit wahr.

Tipp– und Logikfehler

Tippfehler können immer und überall (also jedem) passieren. Das kann leicht zum „Nadel–im–Heuhaufen–Problem“ führen. Bei dynamisch erstellten Websites kann ein einzelner Tippfehler weitreichende, und auch recht verwirrende, Auswirkungen haben: Er wird nur einmal gemacht, kann aber, je nach dargestellter Situation, zu unterschiedlichen Ergebnissen führen, weil ein bestimmter Teil (der eben diesen Fehler enthält) immer wieder verwendet wird. Hier hilft nur, sich einen Überblick über den Seitenaufbau zu verschaffen, um die betroffene Datei (und damit den Fehler) zu lokalisieren.

Logikfehler sind da schon wesentlich leichter in den Griff zu bekommen. Finden Sie eine gut nachvollziehbare Konvention und halten Sie sich strikt daran. Legen Sie etwa alle Bilddateien immer im selben Verzeichnis ab; etwa so /img/bild.png oder so /images/bild.png oder auch so /assets/images/bild.png.

Die letztgenannte Variante hat gleich zwei Vorteile: Sie können Ihre Bild– und CSS–Datei(en) gleich „nebenan“ in einem gemeinsamen Unterverzeichnis lagern (also etwa so /assets/images/bild.png und /assets/css/main.css), und nicht wenige CMS folgen ebenfalls dieser Verwaltungslogik.

Alles andere führt nur zu Unordnung und erschwerter Fehlersuche. Wenn Sie einige Dateien des gleichen Typs hier, einige woanders und wieder einige ganz woanders lagern, und eine wirklich umfangreiche Seite betreiben, dann bleibt Ihnen nur, auf lange, einsame Winternächte zu hoffen.

Ja, aber manche Browser …

Nein, nicht wirklich. Wenn manche Browser auch ohne Referenzierung des Favicons „by default“ (also quasi ab Werk) im Wurzelverzeichnis danach suchen, gut. Alle folgen diesem „Standard“ offensichtlich nicht, weshalb wir hier und jetzt überhaupt darüber reden. Was aber alle können (und wohl auch machen) ist, klare Anweisungen im Quellcode befolgen.

Rufen Sie den Quellcode dieser Seite auf. Das könnte je nach verwendetem System unterschiedlich ablaufen, ich hab’s jetzt nicht im Kopf. Bei mir geht’s am schnellsten mit der Tastenkombination Strg+U.

Es müsste schon mit dem Teufel zugehen, würden die Pfade zu Bild– und CSS–Dateien nicht als Verweise dargestellt. Klicken Sie diese der Reihe nach an. Sie sollten alle zu der jeweils angegebenen Datei führen. Ist das der Fall, werden die entsprechenden Informationen (die diese Dateien enthalten) auch umgesetzt — und als Konsequenz im Browser dargestellt bzw. verarbeitet.

Die Überlegung was „manche Browser machen (und andere auch oder vielleicht doch nicht)“ kann nie zu einer stabilen Lösung führen. Der einzige (nach meinem bescheidenen Verständnis) vernünftige Ansatz ergibt sich aus der Frage: „Was machen alle Browser?“ Und die Antwort darauf ist: „Anweisungen im Quellcode ausführen.“ Und je weniger „Hacks“ dafür notwendig sind, desto besser.

Da wären dann noch die Eigenarten einzelner Systeme …

Ja, die wären da noch. Es ist mir auch schon aufgefallen, dass einzelne Content Management Systeme teilweise recht unterschiedliche Ansätze bezüglich relativer Verweise (d.h. relativ zur Gesamtstruktur der Website) verfolgen.

Die einzige generische (allgemeingültige, universelle) Lösung die mir dazu aus dem Stegreif einfiele, wäre alle Links absolut anzugeben — unabhängig davon, welcher Konvention die Entwickler des jeweiligen CMS eigentlich folgen. Das könnte sich zuweilen mühsam gestalten, sollte aber zu keinen „technischen Verwicklungen“ führen. Das würde dann hier im Falle des Favicons so aussehen:

<link rel="icon" type="image/png" sizes="16x16" href="https://gwpachlatko.github.io/emwd/assets/images/favicon-16x16.png" />

Ansonsten bleibt nur, sich dem jeweiligen System und seinen Konventionen anzupassen.

Beispiel: Um das Favicon hier in Jekyll verlässlich einzubinden und auf allen Seiten angezeigt zu bekommen, habe ich alle Bilddateien in /assets/images/ gesammelt, und verweise darauf mittels „Liquids“ nach der ansonsten in diesem CMS üblichen Konvention. Also etwa:

<link rel="icon" type="image/png" sizes="16x16" href="{{ site.baseurl }}/assets/images/favicon-16x16.png" />

Damit wirft der Server keine Fehler aus, die Seiten validieren nach W3C und das Favicon wird auf allen Seiten und in allen (getesteten) Browsern angezeigt. Fall erledigt.