Self-Theme-Challenge

Nach der letzten Beyond Tellerrand Konferenz war und bin ich motiviert für neue Dinge.

Was ja auch das Ziel einer solches Konferenz ist: Durch neue Eindrücke und der Präsentation von genialen Ideen und von mutmachenden Umsetzungen erhält man  selbst auch neue Inspirationen.
Für mich war dies im Wesentlichen der Antrieb etwas umzusetzen, was ich schon länger an der einen und der anderen Stelle vermisse:

Wenn man sich als Webentwickler im Web umschaut, kommt man nicht umhin zu sehen, daß viele CMS-basierte Websites in ihrem ausgelieferten Code sehr überfrachtet sind. Gerade wenn ein CMS benutzt wird, welches die Erweiterung mittels Plugins erlaubt, ist dies fast immer der Fall. Bei WordPress zum Beispiel sieht man extrem häufig Plugins, welche den Code anreichern um eigene JavaScripten und CSS – und zwar auf allen Seiten und nicht nur auf den Seiten, wo das Plugin konkret Inhalte erzeugt.

Auch ist es bei einigen Entwicklern üblich geworden, Schriften von Google Fonts, JavaScripten von einem CDN-Server und CSS zu Frameworks (wie beispielsweise Bootstrap) von den jeweiligen Framework.Servern zu laden. So verursacht eine einfache Webseite, die selbst ein minimalistisches Design verwendet, trotzdem mehrere Requests zu fremden Servern und bläht dabei nicht nur das Ladevolumen unnötig auf, sondern setzten den Besuchern auch ungewollten Tracking durch Dritte aus.

Eine weitere Sache, die mir nicht gefällt, ist die unnötige Aufblähung des Codes durch <div> und <span>-Elemente, aber auch durch CSS-Klassen wo der Kontext des Inhalte dieses unnötig machen würde. So beispielsweise die CSS-ID #colophon im <footer> oder aber eine Wrapper-<div class=“wrapper“> um die drei Elementbereiche <header>, <main> und <footer>.

Die Challenge

Es soll ein WordPress-Theme entwickelt werden. Dieses muss folgende Eigenschaften haben:

1. CSS:
   1. Das Theme darf nur eine einzige CSS Datei laden.
   2. CSS-Dateien von Plugins werden nicht mit gezählt, die Seite bzw. das Theme soll aber ohne Plugins präsentabel aussehen. Dies soll das Theme selbst liefern.
   3. Entsprechende Proxy-und PostCache-Skripten, die den ganzen Code minimalisieren, sind nicht zu nutzen.
   4. Das CSS braucht keinerlei Vendor-Prefixe enthalten. Diese können optional gesondert mit einem Autoprefixer ergänzt werden. Dies ist aber außerhalb der Challenge.
   5. Browserversionen, die 3 Jahre oder älter sind, können ignoriert werden. Als Referenz gilt CanIuse.com .
   6. An keiner Stelle des CSS darf die Anweisung !important verwendet werden.
2. JavaScript:
   Wenn das Theme JavaScripten benötigt, darf hierzu im Frontend nur eine einzige JavaScript-Datei geladen werden.
   1. Sollte eine Seite kein JavaScript benötigen, darf auch keine JavaScript-Datei eingebunden sein.
   2. Dies schließt JavaScript von WordPress mit ein. Hierzu können ggf. Plugins genutzt werden, die das Laden ungebrauchter JavaScripten (z.B. die JavaScripten für Embeddings oder vom Blocks Editor)  unterbindet.
   3. Es sollte kein Modernizr geladen werden. Alle Browserversionen, die 3 Jahre oder älter sind, können ignoriert werden.
3. Wird eine eigene Schriftfont verwendet, soll auch hier das Ladevolumen möglichst kein gehalten werden. Die Schriftfont sollte aber den gebräuchlichen Zeichensatz für Sonderzeichen und Buchstaben im Europäischen Raum beinhalten.
4. Sofern ein Iconfont oder ein SVG-Font verwendet wird, darf dieses nur die Icons beinhalten, die tatsächlich benötigt werden und es soll nur eine einzige Datei für die Icons verwendet werden.  Ob ein SVG-Font oder ein Iconfont verwendet wird, ist offen gelassen.
5.  Keine im Theme verwendete Datei, die im Fontend oder im Backend verwendet wird, darf von einem fremden Server (CDN, JavaScript- und Font-Bibliotheken, etc.) geladen werden.
6. Der HTML-Code muss selbst weitgehend minimalistisch sein.
   1. Das bedeutet, daß <div> und <span> einzig dort verwendet werden soll, wo es keine Alternative in HTML gibt. CSS-Klassen sollen nur da gesetzt werden, wo sie tatsächlich benötigt werden.
   2. Wenn der hierarchische Kontext des HTML klar definiert, wozu der Inhalte gehört, sind keinerlei Klassen zu setzen.
   3. Es dürfen keinerlei Inline-Styles verwendet werden. Auch die Erzeugung von Inline-Styles durch WordPress selbst ist zu unterbinden.
7. Alle nicht genutzten HTML-Codes und CSS-Anweisungen, die durch WordPress automatisch erzeugt werden, sollen entfernt werden. So zum Beispiel die DNS- oder Rel-Angaben im <Head> (zum Beispiel <link rel="profile" href="http://gmpg.org/xfn/11">) oder auch die umfangreichen CSS-Klassen bei der Erstellung von Menüs. Ausnahme ist hierbei nur die Angabe des Generators.
8. Trotz der vorherigen Bedingungen soll das Theme auch folgendes leisten:
   1. Semantische Daten werden mit Hilfe von Schema.org-Markup deklariert
   2. Open Graph Anweisungen sollen die Unterstützung von Social Media und Suchmaschinen gewährleisten
9. Dies ist eine Selbstverständlichkeit, aber sie muss leider heutzutage noch erwähnt werden: Die (durch den Code technisch bedingte) Barrierefreiheit soll gewährleistet werden. Als Standard gilt die WCAG 2.1 in der Mindeststufe A, wobei die Stufe AA angestrebt werden soll.
10. Folgende Funktionalitäten muss das Theme enthalten:
    1. Optisch schönere Darstellung einer Bildergalerie durch Umdefinition des WordPress-Shortcodes [[galery]]
    2. Page Breaks für Seiten und Artikel
    3. Artikelbilder sollen innerhalb der Metaangaben referenziert werden, so daß Social Media Plattformen dieses erkennen und nutzen können.
    4. Alle üblichen Seitenformate und Typen, die durch die WordPress-Theme-Test Definition vorgegeben sind.
    5. Der Inhaltsbereich soll optional in mindestens 4 Spalten formatierbar sein, wenn die Bildschirmauflösung größer ist als 1200 Pixel.  Bei kleineren Auflösungen müssen diese Spalten entsprechend responsive regieren.
    6. Es müssen mindestens 3 Breakpoints durch das responsible Design unterstützt werden:
       1. Auflösungen von 480 Pixel und kleiner
       2. Auflösungen ab 1024 Pixel
       3. Auflösungen ab 1500 Pixel
    7. Das Theme muss im vollen Umfang funktionell sein, ohne dass hierzu weitere Plugins geladen werden müssen.
11. Der Code ist unter einer freien Lizenz auf einem Open Source-Provider, wie beispielsweise Github, zu veröffentlichen. Eine Veröffentlichung in der WordPress Theme Directory ist hingegen nicht notwendig. Der Code darf Teile beinhalten (beispielsweise zur Umdefinition der Galerie), die laut dem WordPress Theme Codex eigentlich „Plugin Domain“ wären.

(Anmerkung zur Frage Iconfont vs SVG-Font: Zwar setzen sich derzeit viele kluge Menschen aus guten Gründen dafür ein, von Iconfonts auf SVG-Fonts zu wechseln, jedoch ist die Einbindung von langen SVG-Codeblöcken in den HTML-Codebereich meines Erachtens nicht der Weg, der richtig sein kann, wenn man am Ende minimalistischen und vorallem längerfristig wartbaren Code  haben will. Dies ist meine Meinung und mein Bauchgefühl. Dazu haben andere andere Meinungen. Und ich selbst bin auch noch nicht sicher, ob ich nicht einen der Workarounds nehmen werde, die hierzu angeboten werden.  Daher bleib ich an dieser Stelle der Challenge offen.)

Ich hab mir dieses als eigene Challenge gegeben. Und ich lade auch andere dazu ein, dem zu folgen.

Es gibt kein Preis, kein Wettbewerb. Aber ich würde mich darüber freuen, wenn noch andere folgen würden und mir eine E-Mail senden mit einem Link zum Ergebnis. Sobald oder wenn ich tatsächlich auch etwas geschafft hab, werde ich hierüber berichten.

It’s just for the web.