‹‹‹ Übersicht Kolumne

Abenteuer HTML5: Bau moderner Webseiten
Erkenntnisse eines Veteranen des 'ersten Browserkrieges'

Ein Kommentar.

  • CSS
  • HTML
  • Python
  • Responsive Webdesign
  • Software

Chaos

Es hat sich viel geändert. Verflucht viel. So viel war mir klar, als ich anfing, diese Webseite mitsamt ihrer Kolumne zu bauen. Ich wollte es von Grund auf neu lernen, einfache Webseiten zu erstellen, so wie ich es einst vor langer langer Zeit tat, in einer Ära, die inzwischen unter der Bezeichnung "erster Browserkrieg" ihren Weg in zumindest einige bessere Geschichtsbücher gefunden hat. Damals galt es, Webseiten in sage und schreibe genau zwei Browsern mit ihren jeweils sehr eingeschränkten Möglichkeiten halbwegs gleich aussehen zu lassen und ihnen dabei einen Hauch von Interaktivität zu verleihen. Was sich heute vielleicht lächerlich anhört oder liest, stellte damals sehr viele Menschen vor ziemlich große Hindernisse. So auch mich. Dies ist nun sehr lange her und ich hatte in der Zwischenzeit, die letzten etwa zehn Jahre, keine Webseite mehr gebaut, wenn man gelegentliches Schreiben von sehr einfachem HTML oder Änderungen in einem CMS einmal außen vor lässt. Als ich anfing, mich wieder mit dieser Materie zu beschäftigen, musste ich feststellen, dass es gar nicht mehr so einfach war, einen konkreten Ansatz zu finden. Nicht nur die zu Grunde liegenden Sprachen, sondern auch die Art und Weise, wie man Webseiten entwickelt, hatte sich grundlegend weiter entwickelt. Es hab eine riesige Menge an neuen Entwicklerwerkzeugen, Bibliotheken, Philosophien und Technologien, die es für mich zu ergründen galt. Verstärkt wurde dieser Eindruck auch durch meine Erfahrung als "einfacher Nutzer" des Internets beziehungsweise von Browsern. Die vielseitigen Fähigkeiten und Gestaltungsmöglichkeiten für Webseiten wirkten nicht mehr überschaubar.

Ein kleiner Schritt nach vorn: Der Editor

Immerhin am ersten einfachen Schritt sollte sich nichts ändern. Ich brauchte einen Texteditor. Anders als vor einem Jahrzehnt fiel meine Wahl nicht mehr auf Notepad++ unter Windows sondern auf KWrite unter Linux, was ich ohnehin schon des öfteren zum Entwickeln genutzt hatte. KWrite, ein KDE-Programm, beruht auf der gleichen Editorkomponente, auf der auch Kate aufbaut und stellt damit einen der besten und gleichzeitig einfachsten Editoren bereit, die es meiner Meinung nach unter Linux gibt. Die Syntax-Hervorhebung ist ausgezeichnet. Darüber hinaus lassen sich wichtige Zeilen markieren und Blöcke zusammenfalten.

Ein leeres Fenster: Von null anfangen

Wie zu alten Zeiten erstellte ich mir damit eine Datei: "index.htm". Und steckte fest. Was sollte ich da nun reinschreiben? Wie sollte ich die Seite am besten testen? Sollte ich wirklich allen Quelltext da drin von Hand schreiben oder nicht doch irgendein "Framework" (Rahmenstruktur oder Programmiergerüst) oder eine fertige Vorlage verwenden? Wie sollte ich den Inhalt strukturieren? Sollte ich die Seite einfach halten oder sollte es eine Server-seitige Komponente geben? Wäre ein fertiges CMS ("Content-Management-System" - Inhaltsverwaltungssystem) nicht vielleicht auch eine gute (und vor allem einfachere) Idee?

Anders als vor zehn Jahren gibt es heute etablierte Systeme zum Verwalten von Webseiten, die weder instabil noch besonders schwer zu verstehen sind. Programme wie Wordpress, Joomla! oder Drupal sind inzwischen so alltäglich wie normale Bürosoftware, so dass sie keine besonderen Kenntnisse mehr verlangen und von nahezu jedem genutzt werden können. Selbst ihre Installation gestaltet sich mittlerweile überraschend einfach, was jedoch auch einige Gefahren und Probleme mit sich bringt. Wordpress-Seiten sind beispielsweise inzwischen so weit verbreitet, dass sie ein beliebtes Angriffsziel geworden sind. Eine einfache Lücke in Wordpress reicht, um gleich Millionen von Webseiten angreifbar zu machen. Jeder, der gelegentlich die Protokolldateien seiner Webseite liest, wird die mehrfach täglich erfolgenden automatischen Versuche kennen, nach gängigen Programmen und ihren Sicherheitslücken zu suchen. In diese graue und einfach angreifbare Masse wollte ich schon einmal nicht fallen. Dazu kommt, dass die Verbreitung von Systemen wie Wordpress ebenfalls zu einer Monokultur an Layouts geführt hat. Heute kann man mit einiger Sicherheit das verwendete CMS am Aussehen der jeweiligen Webseite erraten. Diese Entwicklung hat zu einigen bizarren Effekten geführt, wie zum Beispiel zu einem regen Handel mit den wenigen guten, seltenen und etwas aus der Reihe schlagenden Layouts für eben jene Systeme. Auch an dieser Stelle wollte ich nicht in der Masse untergehen und mich doch etwas (positiv) hervorheben.

Wenn man einmal an diesem Punkt angekommen ist und anfängt, etwas tiefer zu graben, stößt man recht schnell auf professionellere Ansätze wie "Flask". Sie stellen einen einfachen Rahmen sowie die dazu passenden Werkzeuge bereit, um damit schnell und effizient Webseiten von Grund auf zu bauen, ohne dabei ein vollständiges CMS zu sein oder den eigentlichen Quelltext zu verbergen. Dies sagte mir schon mehr zu, jedoch fehlten mir auch hier ganz wesentlich die Kenntnisse, um etwas sinnvolles damit anzufangen. Alle bis hier beschriebenen Ansätze haben gemeinsam, dass man die darunterliegenden Technologien verstehen und doch etwas kennen sollte, um sie effizient, richtig und vor allem sicher einzusetzen. Ein CMS oder sonstiges "Frameworks" ohne eben diese Kenntnisse zu benutzen kam damit für mich erst recht nicht in Frage. Meine letzte Hoffnung, nicht ganz von vorne ansetzen zu müssen, bestand in einer fertigen Vorlage, von denen es heute unzählige frei verfügbar zumeist unter CC-Lizenzen gibt. Ich lud mir also eine ganze Reihe solcher Vorlagen aus dem Netz und schaute sie mir von allen Seiten genau an. Obwohl mich einige von ihnen faszinierten, verstand ich ihre Funktionsweise und ihren Aufbau nur teilweise, was für mich eine halbwegs intelligente Weiterentwicklung nicht durchführbar erscheinen ließ. Ich beschloss also, wohl oder übel von null anzufangen.

Literatur für den Anfang

Wer sich vielleicht noch an die Jahrtausendwende und die damalige Kultur des Internets (im deutschsprachigen Raum) erinnert, dem wird "SelfHTML" bestimmt noch etwas sagen. Vermutlich wurden unzählige Menschen durch dieses genial wie einfach geschriebene Kompendium genau wie ich dazu verführt, Webseiten zu erstellen. In SelfHTML erklärte Stefan Münz zusammen mit seinen Mitstreitern detailliert Schritt für Schritt, wie man das Skelett einer Webseite konstruierte, wie man es mit Inhalt füllte, worin die Unterschiede zwischen den damals verbreiteten Browsern bestanden, wie man die damals verfügbaren Technologien wie "Frames" richtig ausreizen konnte und wie man "DHTML", also "dynamisches HTML", schrieb, wozu er sogar eine einfache JavaScript-Bibliothek bereit stellte, die man als einen der vielen Vorläufer von jQuery bezeichnen könnte - aber dazu später mehr. Genau nach so etwas suchte ich jetzt wieder. Und fand es nicht (so einfach).

Meine erste wesentliche Erkenntnis bestand darin, dass es keinen einfachen zentralen Anlaufpunkt mehr gab. Ich musste mehrere Bücher wälzen, den Quelltext verschiedener Bibliotheken studieren und mich durch zahlreiche Webseiten wühlen, bis sich für mich (wieder) ein Bild ergab. Daraus folgte gleich meine zweite Erkenntnis: Alles, was ich bis dahin über den Bau von Webseiten wusste, ließ sich bestenfalls als interessante Erfahrung verbuchen, war aber inhaltlich zu weiten Teilen überholt. Ich war wieder ein blutiger Anfänger und musste als solcher wieder mit entsprechenden einfachen Übungen anfangen.

Für alle, die sich mit dem gleichen Problem konfrontiert sehen, möchte ich an dieser Stelle die folgende absichtlich minimal gehaltene Liste an Bücher und Quellen empfehlen, die mich in dieser Phase erfolgreich begleitet haben:

"Schrödinger lernt [...]" ist eine unkonventionelle aber ausgezeichnete Einführung, bei der es sich lohnt, sie von Anfang bis Ende durchzuarbeiten. Obwohl sie durchaus Anregungen zu eigenen Experimenten bietet, ist sie jedoch kein Buch über den Aufbau von Webseiten, sondern widmet sich vielmehr der wichtigsten Technologien, die man dazu beherrschen sollte. "jQuery" ist heute wohl die verbreitetste JavaScript-Bibliothek überhaupt, wodurch es aus meiner Sicht sehr viel Sinn gemacht hat, sich mit ihr direkt am Anfang etwas näher auseinander zu setzen. Dies erleichtert das erlernen weiterer moderner Technologien ungemein oder hat es zumindest in meinem Fall getan. "jQuery von Kopf bis Fuß" bietet hierfür eine hervorragende Einführung, die man jedoch nicht unbedingt komplett durcharbeiten muss. Für mich diente dieses Buch hauptsächlich dazu, mich durch seine vielen gut betexteten Beispiele mit den Möglichkeiten von modernem JavaScript vertraut zu machen. Die Webseiten "w3schools", "Can I use" und "Stack Overflow" bilden zusammen ein gutes Nachschlagewerk beziehungsweise eine vollständige Referenz. Während man bei "w3schools" die einzelnen Elemente von HTML5, CSS3 und JavaScript standardkonform mit einfachen Beispielen erklärt bekommt, bietet "Can I use" einen detaillierten Überblick über die Unterstützung der einzelnen Elemente durch Browser. Für fortgeschrittene Beispiele oder bei Fragen, die sich durch diese zwei Webseiten nicht beantworten lassen, wird man zuletzt bei "Stack Overflow" so gut wie immer fündig.

Zeit, die man für Grundlagen braucht

Für das Durcharbeiten der genannten Bücher sollte man etwa ein bis zwei Wochen einplanen. Falls man schon etwas Erfahrung mit der Entwicklung von Webseiten mitbringt, sollte dies reichen, um zumindest weitgehend auf einen modernen Wissensstand zu kommen, ohne diesen jedoch routiniert anwenden zu können. Aus diesem Grund bleibt auf dem weiteren Weg das ständige Nachschlagen auf den genannten Webseiten für lange Zeit unerlässlich.

Fortgeschrittene Probleme: Ein Bau-System

Spätestens nach den ersten Beispielen, die man selbst implementiert, wird man feststellen, dass man doch etwas mehr als einen Editor und einen Browser braucht, um vernünftig entwickeln und testen zu können. Für mich stellten sich nacheinander verschiedene Fragen, wie ich zum Beispiel mein selbst geschriebenes HTML validieren, besser mit Vorlagen umgehen oder mein "CSS" lesbar strukturieren konnte. An dieser Stelle begann ich, mir Stück für Stück ein eigenes anfangs einfaches Bau-System zu programmieren, was über eine Reihe an Skripten verschiedene Aufgaben übernehmen konnte. Ich kann es jedem, der sich wie ich mit dieser Materie von Grund auf neu auseinander setzen möchte, nur empfehlen, das gleiche zu tun. Durch den Aufbau eines solchen Systems, was so zu sagen eine Reihe an Quelltext-Dateien regelrecht übersetzt, zusammenbaut und prüft, lernt man einerseits, was es dabei alles zu beachten gibt, was wiederum zu einem fundamentalen Verständnis für Systeme für "Flask" führt. Andererseits ermöglicht es, dem eigenen jeweiligen Kenntnisstand und Geschmack entsprechend verschiedene Werkzeuge in den Bauprozess zu integrieren. Da ich für alltägliche Zwecke Python als Programmier- und Skriptsprache eindeutig bevorzuge, habe ich mein Bau-System entsprechend in dieser Sprache implementiert. Dazu kamen eine Reihe an Werkzeugen, die ich schon in der Anfangsphase beim Lernen von HTML5 zusammengetragen und in mein System integriert habe. Dabei war mir wichtig, jedes dieser Werkzeuge wie auch jede selbst implementierte Funktion meines Systems jederzeit nach Bedarf über eine zentrale Konfigurationsdatei abschalten zu können.

Die folgenden Werkzeuge finden in meinem Bau-System Verwendung:

Das erste Werkzeug, "htmlmin", ist eine kleine, direkt in Python geschriebene Bibliothek, die dazu dient, HTML-Quelltext zu minimieren, also aufzuräumen. Da ich sehr gern mit Kommentaren im Quelltext arbeite, die alles Mögliche enthalten können, wie zum Beispiel Notizen über Dinge, die ich noch umsetzen möchte, habe ich kein Interesse daran, dass diese ihren Weg ins Internet finden. Neben der Entfernung von überflüssigen Leerzeichen und Tabulatoren übernimmt "htmlmin" somit auch die Säuberung meines Quelltextes und stellt quasi eine erste Schicht zur Validierung bereit, die aber leider schnell an ihre Grenzen stößt. An dieser Stelle wird "v.Nu" relevant, bei dem es sich um ein mächtiges in Java geschriebenes Kommandozeilenwerkzeug handelt, welches HTML-Dateien nach dem jeweils aktuellsten Stand der HTML5-Spezifikation exakt prüfen kann und detaillierte Fehlermeldungen ausgibt. Dies hilft unter anderen, korrekt mit der semantischen Syntax von HTML5 umzugehen. Nachdem ich mich Stück für Stück mit den doch recht beeindruckenden Fähigkeiten von CSS3 angefreundet hatte, bekam ich bald Probleme, in meinen viel zu schnell wachsenden CSS-Dateien noch den Überblick zu bewahren. "Responsive Webdesign" erfordert eine Unmenge an CSS-Selektoren, die man irgendwie alle gleichzeitig im Auge behalten muss. Dies führte zu den Erkenntnissen, dass man beim Schreiben sehr auf die Struktur des Quelltextes achten muss, wobei entsprechende Kommentare unerlässlich sind, diese Form der Disziplin jedoch auch irgendwann an ihre schmerzhaften Grenzen stößt. Obwohl vielleicht nicht viele diese Meinung teilen werden, empfehle ich, sich aus diesem Grund bei Zeiten mit "SCSS" beziehungsweise "SASS" auseinander zu setzen. Die wesentliche Idee hinter "SCSS" besteht darin, eine vollständig zu CSS kompatible Syntax bereitzustellen (jede Form von CSS kann ebenso SCSS sein, nicht umgekehrt), die jedoch CSS um wesentliche Funktionalitäten erweitert. Dazu zählen verschachtelte Klassen, Variablen, Funktionen und Makros, die das entwickeln von aufwendigen CSS deutlich erleichtern. Um am Ende CSS-Quelltext zu erhalten, der von Browsern interpretiert werden kann, ist die Übersetzung von "SCSS" beziehungsweise "SASS" zu CSS notwendig, was eine zusätzliche und nicht einfach zu handhabende Fehlerquelle ins Spiel bringt. Aus meiner Sicht machen die für mich unersetzlichen Fähigkeiten von "SCSS" diesen Nachteil aber mehr als wett. Auf Grund der Tatsache, dass ich trotz allem gelegentlich noch einfaches CSS schreibe und die Ausgabe des SCSS-Präprozessors nicht perfekt ist, wird der entstandene CSS-Code bei mir in einem weiteren Schritt durch die Bibliothek "csscompressor" nochmals aufräumt und komprimiert. JavaScript stellt beim Prüfen und Optimieren eine Disziplin für sich dar, die zu Recht ganze Fachbücher füllt. Ich verwende für eine erste grobe Fehleranalyse (noch bevor ich mir die Webseite im Browser anschaue) und zum Aufräumen meines Codes das Werkzeug "uglifyjs", welches selbst in JavaScript geschrieben ist und unter anderem auf Node.js läuft. "uglifyjs" ist in diesem Bereich ein vielseitiger und geschätzter Klassiker, der nicht nur eine einfache Kompression des Codes vornimmt, sondern auch eine Prüfung und anschließende Optimierung des eigentlichen Syntaxbaumes durchführt. Obwohl dieser Schritt einer Übersetzung fast gleich kommt und damit wieder eine zusätzliche Fehlerquelle ins System bringt, ist es aus meiner Sicht die Analysefunktionalität von "uglifyjs" samt ihrer ausführlichen Ausgabe wert. Zuletzt in dieser Sammlung sei "PIL" erwähnt, was durch meinen Wunsch, "Favicons" im ico-Format automatisch zu erstellen, seinen Weg in meine Werkzeugsammlung fand. Darüber hinaus verwende ich "PIL" inzwischen für die Verarbeitung von jedem einzelnen Bild. So könnte ich beispielsweise die Breite dieser Webseite zentral verändern, wodurch "PIL" beim nächsten Durchlauf des Bau-Systems alle Bilder passend aus ihren jeweiligen Originalen neu generieren würde. "SVGO" dient der Optimierung beziehungsweise Bereinigung von skalierbaren Vektorgraphiken (SVG-Dateien), bevor ich diese direkt in HTML einbette. Zur Darstellung von Formeln verwende ich "MathJax". Anders als bei vielen Webseiten, welche Formeln mit diesem System darstellen, werden diese bei mir nicht erst im Browser des Benutzers von ihrer "Tex"-Repräsentation in eine lesbare Formel umgewandelt, sondern schon beim Bau der Webseite in Vektorgraphiken übersetzt. Hierzu dient "MathJax-node", was die Nutzung von "MathJax" mit "Node.js" erlaubt. Dieses Vorgehen entlastet den Prozessor der Besucher meiner Seite drastisch und führt somit zu einer sehr flüssigen Darstellung auch äußerst komplizierter Formeln.

Ein lokaler Server - und eine Domain

Obwohl ich für meine Webseite bewusst keinen Server-seitigen Code schreiben oder überhaupt haben wollte, dass heißt beispielsweise keine PHP-Skripte oder ähnliches, ließ sich es sich wirklich nicht mehr vermeiden, einen einfachen lokalen Server zum Testen zu betreiben. Spätestens wenn es um AJAX geht, sind Tests ohne Server nicht mehr sinnvoll durchführbar, obwohl es zum Beispiel der Browser Firefox durchaus noch erlaubt, AJAX-Zugriffe über das "file"-Protokoll durchzuführen. Anders als früher stellt die Installation eines Servers aber auch kein besonderes Problem mehr dar, da sich ein rudimentärer HTTP-Server schon allein mit den Bordmitteln von Python oder Node.js mit wenigen Zeilen Code starten und stoppen lässt. Etwas mehr überrascht haben mich die Einschränkungen, die sich beispielsweise im Browser Chrome durch die Umsetzung der "Same-Origin-Policy" ergeben. Die "Domain" localhost wird hier nicht als vertrauenswürdige Quelle angesehen, so dass sich Webseiten nicht so verhalten, wie sie es würden, wenn sie über eine "richtige" Domain aufgerufen werden würden. Aus diesem Grund lässt es sich ab einem bestimmten Punkt nicht mehr vermeiden, seine Webseite gelegentlich auch auf einem richtigen Server beziehungsweise dem eigenen "Webspace" zu testen. Mein Bau-System besitzt für diesen Fall einen Schalter, der die jeweils zuletzt gebaute Version automatisch per FTP auf eine zu meiner Webseite gehörenden Subdomain schiebt, die ausschließlich für solche Tests dient.

Testen im Browser

Eine deutliche Verbesserung zum Stand von vor zehn Jahren stellen die Entwicklerwerkzeuge dar, die heutzutage jeder Browser besitzt. Wo man früher tatsächlich keine Wahl hatte, einen Fehler in JavaScript mit der Hilfe so primitiver Mittel wie Fehlermeldungen zu suchen, stehen heute vielseitige Analysewerkzeuge und richtige Debugger zur Verfügung. Ich nutze im Moment die Werkzeuge der Browser Firefox und Chrome gleichzeitig, um meinen Code zu analysieren, was mir die meiner Meinung nach besten Ergebnisse gibt.

‹‹‹ Übersicht Kolumne