#LR16: Die Ausgangslage

Gebt’s ruhig zu: Ihr habt Euch ein wenig erschrocken, wie „nackt“ mein Blog auf einmal aussieht. (An dieser Stelle sollten RSS-Leser bitte wenigstens mal kurz einen Blick auf das Blog in einem Browser werfen.) Das ging mir, ehrlich gesagt, auch so – aber diesen ersten Schritt wollte ich immer so machen. So sieht das Blog also aus, bevor man anfängt, zu gestalten. Ich nenne es „CSS Naked Day plus X“, denn ganz nackt ist es eben doch nicht.

Wer gerne von Anfang an mitverfolgen möchte, was unter der Haube in den Dateien passiert – ich habe ein GitHub-Repository angelegt und den aktuellen Stand mit einem Tag markiert. Gehen wir mal der Reihe nach durch, was ich da in v0.1.0 auf den Server geschoben habe.

Markup

Ich habe eine Vorlage für s9y-Themes, die ziemlich „blank“ ist, also auf das absolut Notwendigste im Markup reduziert. Sie enthält auch nur die .tpl-Dateien (Smarty-Templates), die ich üblicherweise in Themes benötige, eine sehr spartanische config.inc.php, die im Wesentlichen die sogenannte Kernnavigation (eine im s9y-Kern konfigurierbare Navigation, die von Theme zu Theme übernommen wird) einbindet und Pflichtfelder in Kommentarformularen ermöglicht, sowie die grundlegenden Sprachdateien für Deutsch und Englisch.

In den Templates habe ich das Markup für #LR16 nochmals weiter reduziert, indem ich alle Klassen entfernt habe, von denen ich noch nicht weiß, dass ich sie definitiv benötigen werde, und alles Markup so angepasst habe, dass (hoffe ich zumindest) kein „überflüssiges“ HTML ausgegeben wird – soweit das in s9y-Templates möglich ist. (s9y ist nach wie vor nicht vollständig smartifiziert, insofern habe ich eben auf bestimmte Teile des generierten HTML keinen Zugriff über die Templates.)

Neben den üblichen Templates für das „Gerüst“ (index.tpl), Einträge, Kommentare nebst Formular und Archivseiten enthält blog-theme, wie das Theme (vorerst zumindest) heißen wird, auch Templates für statische Seiten und das (nicht dynamische) Kontaktformular. Weitere könnten folgen, aber vermutlich erst viel später – die Auswahl entspricht derzeit dem, was ich hier im Blog verwende.

Stylesheets

„Ganz nackt“ ist es nicht, was auch damit zusammen hängt, wie Serendipity Stylesheets erzeugt. Das dynamisch erzeugte serendipity.css setzt sich zusammen aus:

Styles, die von Plugins ausgegeben werden
Fallback-Styles, die jedes Serendipity-Theme haben sollte (und daher auch bekommt)
dem Stylesheet des Themes, style.css
(optional) einem updatesicheren Benutzer-Stylesheet user.css

Ich verwende hier keine user.css, aber die ersten drei Komponenten haben wir eben in jedem Fall dabei (sofern man die Einbindung des Stylesheets nicht komplett aus der index.tpl entfernt). Das Stylesheet des Themes schreibe ich nicht in CSS, sondern erzeuge CSS aus Sass. Das ist weiß Gott keine Notwendigkeit für Serendipity-Themes, aber ich bin es seit Jahren so gewöhnt und mag es nicht mehr missen. Das Sass bzw. SCSS für dieses Theme stammt aus meiner Projektvorlage, die so angelegt ist, dass man als Autor sehr gut steuern kann, welches und wieviel CSS erzeugt wird.

Vereinfacht gesagt enthält das Theme-Stylesheet derzeit:

normalize.css, eine Art Reset-Stylesheet
Basis-Styles, vor allem für Formularelemente und andere Elemente, die normalize.css nicht abdeckt, die ich aber für sinnvoll halte
Styles für Klassen, von denen ich schon weiß, dass ich sie verwenden werde – z.B. für die Navigation auf kleinen Bildschirmen und für die Meldungen, die s9y ausgibt
ein paar nützliche Helferklasse, die man eigentlich immer braucht, z.B. .clearfix, um Floats zu clearen
body { padding: 1rem; }, weil es sonst in Browsern unlesbar wäre

Bereits dieses bisschen CSS, mit dem das Blog mehr oder weniger ungestaltet aussieht, wiegt übrigens schon 11 KB.

Javascript

Javascript enthält das Theme bisher kaum – lediglich ein JS-Plugin für die Navigation auf kleinen Bildschirmen, bei dem ich mir noch nicht ganz sicher bin, dass wir dabei bleiben. Es erzeugt ein typisches Smallscreen-Menü, welches auf Klick auf einen Link eben ein- oder ausklappt. Zudem habe ich eine Script namens svg4everybody eingebunden, dass es möglich macht, auch in älteren IE-Versionen „echte“ SVG-Sprites zu verwenden, die ich vermutlich für Icons brauchen werde.

Zudem wird das sehr hilfreiche Modernizr für Feature-Test eingebunden sowie das mit dem s9y-Kern gebundlete jQuery und eventuelle Plugin-Javascripte.

Plugins

Ich habe mich entschlossen, für drei Funktionalitäten s9y-Plugins (neu) zu installieren, da ich diese Dinge nicht fest ins Theme einbinden kann oder will, um das Theme auch für andere Blogs nutzbar zu halten. Das sind im Einzelnen:

Google-Site-Verification und JS-Snippet für Adaptive Images im <head>
Piwik-Snippet am Ende der Seite, damit die Besucherstatistiken erfasst werden
das Lightbox-Plugin, damit die Darstellung großer Bilder unabhängig vom Theme ist

Die beiden ersten Punkte übernimmt je eine Instanz des Page-Nugget-Plugins.

Build-Script

Last not least findet sich im GitHub-Repository ein auf Grunt basierendes Build-Script. Dieses erzeugt eine deploybare Version des Themes und tut dabei – vereinfacht gesagt – Folgendes:

Javascript kombinieren und minifizieren
Theme-Stylesheet aus Sass erzeugen, mit Vendor-Präfixen und Fallbacks versehen und minifizieren
Bitmap- und Vektor-Grafiken optimieren
einen angepassten Modernizr-Build erzeugen
alle Theme-Dateien in einem Verzeichnis sammeln

Im Übrigen werden auch die Javascript-Assets ebenso wie die Komponenten des Build-Scripts über npm verwaltet.

Und nun?

Fertig! Ich lass das jetzt einfach so. (Nein, natürlich nicht.)

Ich möchte den status quo schon ein paar Tage stehen lassen, damit alle Leser mal einen Eindruck so eines „halbnackten“ Blogs bekommen – gleichzeitig kann ich in der Liveumgebung ein paar Dinge testen. Ich wette, es gibt Aspekte, die ich bei der Theme-Entwicklung bedenken muss, die ich jetzt noch nicht auf dem Schirm habe.

Tja, und dann brauche ich wohl mal eine grobe Vorstellung, wie das Seitenlayout aussehen soll. Die habe ich nämlich wirklich noch nicht; es gibt keine geheimen Entwürfe. Ich neige weiterhin zu einem Zweispalter – Inhalt links, eine Seitenleiste rechts. Eventuell fällt das alles sehr typografisch aus, weil ich irgendwie mal Lust auf eine Serifenschrift hätte … mal sehen.

Habt Ihr Vorschläge oder Fragen? Kommt Ihr überhaupt noch mit dem Kommentarformular klar?

Nachtrag: Ich habe für später einen Snapshot der Startseite und dieses Artikels mit der Wayback Machine angelegt.