Logo, Farben, Schrift: So bekommt dein EmDash-Blog ein eigenes Gesicht

Am Ende von Kevins Einstiegsartikel läuft dein Blog. Oben links steht „My Blog“, die Links sind blau, die Schrift ist Inter, und so sieht jede frische Site mit der Blog-Vorlage aus. Wie wird daraus dein Blog, und wie viel davon geht ohne eine Zeile Code?

Mehr, als du vielleicht denkst. Titel, Slogan, Logo und Favicon stellst du im Adminbereich ein. Für Farben und Schriften änderst du ein paar Zeilen in drei Dateien. Ich bin den Weg mit EmDash 1.1.0 auf einer frischen Blog-Vorlage gegangen, am Ende siehst du Vorher und Nachher. Die Dateien sind in der Node- und der Cloudflare-Fassung der Vorlage gleich.

Was ohne Code geht

Fang im Adminbereich unter Einstellungen an und öffne dort Allgemein. Ganz oben findest du den Abschnitt Website-Identität mit Website-Titel, Slogan, Website-URL, Logo und Favicon.

Den Titel und den Slogan hast du eigentlich schon im Einrichtungsassistenten eingegeben. Kevin hat aber bemerkt, dass beides in 1.1.0 nicht ankommt, und ich konnte das nachstellen. Ich habe im Assistenten „Mein Blog“ eingetragen, die Site hieß danach trotzdem „My Blog“. Der Fehler ist inzwischen behoben, der Fix kommt mit der nächsten Version nach 1.1.0. Bis dahin trägst du beides hier noch einmal ein. Der Titel landet im Seitentitel im Browser-Tab und in der Kopfzeile, der Slogan steht in der Fußzeile.

Für das Logo klickst du auf Logo auswählen. Es öffnet sich die Medienbibliothek, und über Dateien hochladen holst du deine Datei dazu. Nach dem Hochladen ist das Bild schon markiert, du bestätigst nur noch mit dem blauen Knopf. Der heißt in 1.1.0 „Einfachauswahl“, was eine verunglückte Übersetzung von „Auswählen“ ist. Beim Favicon läuft es genauso. Zum Schluss klickst du oben rechts auf Speichern.

Lädst du danach die Website neu, ist alles schon da, ganz ohne Deployment. EmDash speichert diese Einstellungen in der Datenbank, und die Vorlage liest sie bei jedem Seitenaufruf. Das Logo ersetzt in der Kopfzeile den Titel, dort ist es 48 Pixel hoch, in der Fußzeile 24. Als Alternativtext nimmt die Vorlage den Alt-Text aus der Medienbibliothek, und fehlt der, den Website-Titel. Das Favicon setzt EmDash selbst in den <head> jeder Seite, und auch der Tab des Adminbereichs zeigt es.

Bei den Bildern selbst gibt es drei Dinge zu beachten.

• Es gibt nur ein Logo. Eine eigene Fassung für den Dark Mode sehen die Einstellungen nicht vor. Ein transparentes PNG mit dunkler Schrift verschwindet also auf dunklem Hintergrund. Ich habe deshalb ein Logo mit eigener Farbfläche genommen, das auf beiden Hintergründen funktioniert.
• SVG geht nicht. Die Medienbibliothek nimmt in 1.1.0 PNG, JPEG, WebP, GIF, AVIF und JPEG XL an. Eine SVG-Datei lehnt sie ab, im Dialog steht dann nur „Upload fehlgeschlagen“ ohne Grund. Eine .ico-Datei steht ebenfalls nicht auf der Liste.
• Das Favicon ist ein quadratisches PNG. Meins hat 256 × 256 Pixel. EmDash erzeugt daraus nur den Eintrag <link rel="icon">, ein eigenes Symbol für den Homescreen von iPhones gibt es in 1.1.0 noch nicht.

Mit Titel, Logo und Favicon erkennt man deine Site schon. Sie ist aber immer noch blau und weiß, und das ändert kein Schalter im Adminbereich. Ab hier geht es in den Code.

Farben: tokens.css lesen, theme.css schreiben

Kevin hat es im Einstiegsartikel schon gesagt: Das Theme ist Code in deinem Projekt. Für die Farben sind zwei Dateien in src/styles/ zuständig.

In tokens.css stehen alle Gestaltungswerte der Vorlage mit ihren Standardwerten, also Farben, Schriftgrößen, Abstände, Spaltenbreiten und Schatten. Jeder Wert ist eine CSS-Variable, ein sogenanntes Design Token, etwa --color-brand für die Akzentfarbe. Diese Datei liest du, aber du änderst sie nicht. Deine Änderungen gehören in theme.css, die in der Vorlage bis auf einen langen Kommentar fast leer ist.

Dass das ohne Tricks funktioniert, liegt an CSS Cascade Layers. tokens.css legt alle Werte in die Ebene @layer base, theme.css schreibt ohne Ebene, und Angaben ohne Ebene gewinnen immer gegen Angaben in einer Ebene. Du musst dir also keine Gedanken über Reihenfolge oder Spezifität machen. Beide Dateien bindet src/layouts/Base.astro ein, das Grundgerüst jeder Seite mit <head>, Kopfzeile und Fußzeile.

Die Farben in tokens.css sind mit light-dark() geschrieben. Der erste Wert gilt im hellen Modus, der zweite im dunklen. Welcher Modus gerade gilt, entscheidet der Umschalter unten rechts in der Fußzeile mit den drei Stellungen hell, dunkel und System. Ohne Auswahl folgt die Site der Einstellung des Betriebssystems.

Meine theme.css sieht nach dem Umbau so aus:

:root {
	--color-brand: light-dark(#b4441c, #f0875a);
	--color-brand-hover: light-dark(#8f3514, #f6a47f);
	--color-on-brand: light-dark(#ffffff, #1c1410);
	--color-bg: light-dark(#fffdf8, #16120f);
	--font-heading: var(--font-fraunces);
}

Die letzte Zeile kommt gleich bei den Schriften dran. --color-brand färbt Links, den Fokusrahmen der Suche, die Textmarkierung und den Knopf unter dem Kommentarformular. --color-brand-hover ist die Farbe, wenn die Maus darüber steht. --color-on-brand ist die Schrift auf Flächen in der Akzentfarbe. Die Vorlage setzt dafür Weiß, und auf meinem hellen Orange im Dark Mode wäre das kaum lesbar, deshalb nehme ich dort ein fast schwarzes Braun. --color-bg ist der Seitenhintergrund, bei mir ein warmes Weiß statt reinem Weiß. Den Fokusring um das Suchfeld musst du nicht anpassen, tokens.css mischt ihn mit color-mix() aus --color-brand.

Schreibst du statt light-dark() nur einen einzelnen Farbwert, gilt er für beide Modi. Welche Token es sonst noch gibt, etwa --color-text, --color-border oder --radius, siehst du in tokens.css.

Safari vor 17.5, Chrome vor 123 und Firefox vor 120 kennen light-dark() nicht. Für sie hat tokens.css einen Block mit @supports not und den hellen Standardfarben. Deine Angaben in theme.css überstimmen diesen Block aber, und mit light-dark() kann ein solcher Browser nichts anfangen. Er lässt deine Farben deshalb einfach weg. Links stehen dann in der Textfarbe da, der Hintergrund wird weiß, und der Knopf unter dem Kommentarformular verliert seine Farbfläche. Lesbar bleibt die Site, nur ohne deine Akzentfarbe. Sind dir diese Browser wichtig, schreibst du deine hellen Farben unter dem :root-Block in theme.css noch einmal als einfache Werte:

@supports not (color: light-dark(#000, #fff)) {
	:root {
		--color-brand: #b4441c;
		--color-brand-hover: #8f3514;
		--color-on-brand: #ffffff;
		--color-bg: #fffdf8;
	}
}

Schriften: astro.config.mjs, Base.astro und theme.css

Die Webfonts lädt die Vorlage über die Fonts API von Astro, und die steckt in astro.config.mjs im Hauptordner des Projekts. Dort steht ein Abschnitt fonts: mit zwei Einträgen, Inter für den Fließtext unter dem Namen --font-body und JetBrains Mono für Code unter --font-mono. Beide kommen über fontProviders.google() aus dem Katalog von Google Fonts.

Für eine andere Textschrift änderst du nur den Namen. Ich habe aus "Inter" die "Source Sans 3" gemacht. Läuft gerade npm run dev, startet Astro den Dev-Server dabei selbst neu. Achte nur darauf, dass die Schrift die Stärken aus weights auch anbietet.

Für die Überschriften gibt es das Token --font-heading, das in tokens.css auf --font-body zeigt. Am einfachsten nimmst du dafür eine Systemschrift, die schon auf dem Rechner deiner Leser liegt, so wie im Kommentar von theme.css:

--font-heading: "Iowan Old Style", Georgia, serif;

Soll es eine Webfont sein, fasst du drei Stellen an. Ich habe für die Überschriften Fraunces genommen. Zuerst kommt in astro.config.mjs ein Eintrag dazu:

fonts: [
	{
		provider: fontProviders.google(),
		name: "Source Sans 3",
		cssVariable: "--font-body",
		weights: [400, 500, 600, 700],
		fallbacks: ["sans-serif"],
	},
	{
		provider: fontProviders.google(),
		name: "Fraunces",
		cssVariable: "--font-fraunces",
		weights: [600, 700],
		fallbacks: ["serif"],
	},
	// JetBrains Mono bleibt, wie es ist
],

Die Stärken 600 und 700 passen zur Vorlage, die Zwischenüberschriften in 600 und die große Titelzeile in 700 setzt. Als Zweites ergänzt du in src/layouts/Base.astro im <head> neben den beiden vorhandenen <Font>-Zeilen eine dritte:

<Font cssVariable="--font-body" preload />
<Font cssVariable="--font-mono" />
<Font cssVariable="--font-fraunces" />

Erst diese Zeile schreibt die Variable --font-fraunces in die Seite. Ich hatte sie zuerst vergessen. Eine Fehlermeldung gab es nicht, die Überschriften blieben einfach in der Textschrift. Als Drittes zeigst du in theme.css mit --font-heading: var(--font-fraunces); auf die neue Schrift, so wie in meinem Beispiel oben. Das gilt dann für alle Überschriften von h1 bis h6, also auch für die kleinen Titel in der Seitenleiste wie „Categories“ oder „Recent Posts“.

Und was ist mit Google und dem Datenschutz?

fontProviders.google() klingt so, als würde der Browser jedes Besuchers die Schriften bei Google abholen. Kommen Schriften von Googles Servern, geht dabei die IP-Adresse jedes Besuchers an Google, und genau das vermeidest du, wenn deine Site sie selbst ausliefert.

Die Fonts API funktioniert aber anders. Astro lädt die Schriftdateien beim Entwickeln und beim Build einmal herunter und liefert sie dann selbst von deiner Domain unter /_astro/fonts/ aus. Ich habe das im Build nachgeprüft. Astro meldet dort „Copying fonts (22 files)“, die Seiten verweisen nur auf Dateien unter /_astro/fonts/, und im fertigen Build kommt weder fonts.googleapis.com noch fonts.gstatic.com vor. Mit Google spricht also nur der Rechner, auf dem du baust, und nicht der Browser deiner Leser. Umlaute, ß und das Eurozeichen stecken übrigens schon im Subset „latin“, das Astro standardmäßig lädt.

Lokal prüfen, dann online stellen

Prüfen kannst du alles lokal mit npm run dev unter http://localhost:4321. Schalte dabei in der Fußzeile einmal zwischen hell und dunkel um, denn eine Farbe, die auf Weiß gut aussieht, kann auf Schwarz untergehen.

So sah meine Testseite vorher aus, mit dem Standardlook der Vorlage:

Und so nach den Änderungen aus diesem Artikel, mit Logo, Fraunces in den Überschriften, Source Sans 3 im Text und Terrakotta als Akzentfarbe:

Die Änderungen am Code bringst du so online, wie Kevin es beschrieben hat. Mit der Cloudflare-Vorlage reicht npm run deploy, das baut die Site und lädt sie hoch. Mit der Node-Vorlage baust du mit npm run build und startest den Server mit npm run start.

Logo, Favicon, Titel und Slogan reisen dabei aber nicht mit. Sie stehen in der Datenbank, und die lokale Datenbank wandert nicht auf den Server. Auf der Live-Site lädst du Logo und Favicon deshalb im Adminbereich noch einmal hoch und trägst Titel und Slogan ein, denn mit 1.1.0 trifft dich der Fehler im Einrichtungsassistenten dort genauso.

Fazit

Zurück zur Frage vom Anfang. Ohne Code geht alles, was deine Site benennt, also Titel, Slogan, Logo und Favicon. Das stellst du unter Einstellungen → Allgemein ein, es wirkt sofort und liegt in der Datenbank, deshalb wiederholst du es auf der Live-Site. Wie die Site aussieht, ist Code in drei Dateien. In theme.css überschreibst du die Token aus tokens.css, in astro.config.mjs wählst du die Schriften, und für eine eigene Überschriftenschrift kommt eine Zeile in Base.astro dazu. Das alles geht mit dem nächsten Deployment online, und die Schriften kommen dann von deiner eigenen Domain.