Wir wollen lernen, wie man mit Hilfe eines so genannten Static-Site-Generators eine Website mit Inhaltsseiten und einem Blog erstellt. Der Workshop richtet sich an unsere @ag-pr, aber auch an alle anderen, die das einfach mal lernen wollen.
Was sind Static-Site-Generatoren?
Static-Site-Generatoren, also “Generatoren für statische Seiten”, sind Programme, die eine Website mit statischen HTML-Dateien bauen. Das Gegenteil wären dynamische Websites mit Content-Management-Systemen.
Content-Management-Systeme brauchen immer ein Prorgamm, das auf einem Server läuft, und bei jedem Aufruf der Website die HTML-Inhalte aus einer Datenbank neu generiert.
Static-Site-Generatoren bauen die Website nur einmal und speichern dann HTML-Dateien. Um diese von einem Webserver auszuliefern, braucht man dann keine spezielle Software. Außerdem sind statische Websites schneller, da sie nicht erst generiert werden müssen, und sicherer, da sie weniger Software auf dem Server benötigen.
Mit Static-Site-Generatoren kann man trotzdem alles machen: Inhaltsseiten, Blogs, Inhalte aus dynamischen Daten erzeugen, uvm.
Inhalte und Ablauf
Grundlagen-Techniken
HTML zur Beschreibung von Inhalten
CSS zum Styling der Website
Bildformate und Bildverarbeitung
Templates und HTML-Generatoren
Markdown als einfachere Beschreibungssprache
Übersetzen von Markdown in HTML
Static Site Generatoren: Frameworks für strukturierte Websites
Praxisbeispiel mit Zola
Funktionen von Zola
Themes
Erstellung einer Website
Hosting auf EduGit Pages
Voraussetzungen
Vorraussetzungen sind:
Ein Teckids- oder EduGit-Account
Ein Rechner mit einer aktuellen Linux-Distribution (idealerweise Debian)
Grundfähigkeiten im Umgang mit einem Texteditor und mit git
Termine
Der Workshop gleidert sich in 3 Termine zu je 1½ Stunden und findet ab dem 13. April 2023 donnerstags von 17:30 bis 19:00 statt.
Eine Antwort postet, in der ihr schreibt, welche der Inhalte von der Liste oben ihr vielleicht schon könnt oder was ihr in der Vergangenheit schon zum Thema ausprobiert habt.
Ich bin mir noch nicht sicher, ob ich Interesse hätte. Wäre es auch in Ordnung, wenn ich beim ersten Mal mal “reinschnuppern” würde und dann schauen würde, ob es mich interessiert?
Den Baum nennt man auch DOM (Document Object Model)
Es gibt Block-Elemente und Inline-Elemente. Block-Elemente brauchen die gesamte Breite und es geht darunter weiter; Inline-Elemente verhalten sich wie ein Wort in einer Textzeile.
In HTML gehören nur Struktur und Inhalt, aber kein Styling (Aussehen)
Das hat den Grund, dass z.B. Menschen die ein text-to-speech-Programm benutzen die Seite aufrufen können ohne Dinge wie Zwei // zu hören, wenn diese nur dem Styling dienen.
Alles zum Aussehen gehört in CSS
CSS besteht aus Blöcken miteinem Selektor (auf was bezieht der Block sich?) und Regeln
Es gewinnt bei CSS immer der Block mit dem spezifischsten Selektor
Von Hand geschriebene Webseiten ansehen könnte u.U. auch spannend sein. Die MirBSD-Webseite und deren Derivat, die alte Teckids-Webseite, sind z.B. erzeugt, indem HTML-Schnipsel (genauer XHTML (also HTML, das so geschrieben wird, daß es gleichzeitig gültiges XML ist, also z.B. <br /> statt <br/> (nur XML) oder <br> (nur Alt-HTML))) durch einen Static-Site-Generator mit Header/Footer zusammengebracht und u.U. noch verändert wurden (z.B. wird auf der MirBSD-Webseite aus ls(1) ein Link auf die Manpage von ls). Bei beiden haben wir durch ein XML-Prüftool auch darauf Wert gelegt, daß es genau der (X)HTML-Dokumentenspezifikation entspricht, also keine Fehler drin sind wie <b><i>falsche Verschachtelung</b></i>, und daß es sauber als XML lesbar ist (denn nur dann kann man es mit XML-Tools auch bearbeiten, was total cool sein kann).
CSS und, wo vorhanden, JS sind natürlich separat und optional, wie bei ROCA. (Wobei bei aktivem JS von nutzbarem CSS ausgegangen werden darf.)
Bei der MirBSD-Webseite habe ich auch besonders Wert auf Kompatibilität mit Textbrowsern wie lynx Wert gelegt, z.B. ist ein Teil des Headers (Titelbild/ASCII-Art) im HTML ganz unten und wird durch CSS in Buntbrowsern visuell nach ganz oben gehoben, aber bleibt in lynx unten, weil man es ja sonst auf jeder Seite langwierig überspringen müßte, was insbesondere Blinde nerven würde. (lynx wird gerne von Blinden verwendet, und zwar nicht nur per Text-to-Speech, sondern auch und insbesondere mit einer Braille-Zeile als Ausgabegerät.)