Rechnungsscript

[molily]

Hallo,

Naja, es geht ja nicht um _den_ Menschen (der mal eben was im Web publizieren will), sondern um die paar, damit ihre Brötchen verdienen, ebendies _den_ anderen zu ermöglichen, ohne HTML lernen zu müssen.

HTML hat sich von Herkunft und Zielsetzung explizit an den nicht-berufstätigen Coder gewandt. Und es ist IMHO gut, daß man auch heute noch als normalsterblicher Freizeitcoder (einigermaßen) damit klarkommen kann.

»HTML wird von Laien geschrieben, deshalb ist Fehlertoleranz die Zukunft« - so einfach würde ich das nicht formulieren und die oppositionelle Gegenüberstellung zur XML geht auch nicht auf. Dazu zwei Gedanken:

Nachdem man nicht mehr so einfach mit font und Tabellenlayout herumschmieren kann, schreibt man möglichst effizienten CSS-Code. Das heißt: Wenig CSS-Regeln, Vererbung/Kaskade nutzen, passende Selektoren und soviele »Anker« im HTML, wie gerade nötig. Dazu braucht man, will man sich nicht soviel Arbeit machen wie in font-Zeiten, notwendigerweise »einigermaßen aufgeräumtes« HTML, das einen absehbaren DOM-Baum erzeugt. Also auch nicht willkürlich Fehler enthalten kann, weil nicht alle Browser die gleiche Fehlertoleranz mitbringen.

Wenn man nur ein wenig mit JavaScript/DOM operiert, gilt das noch vielmehr. Wenn DOM-Abfragen ins Leere laufen oder Objekteigenschaften/-Methoden nicht das gewünschte zurückliefern, ist das Script nicht funktionsfähig und kann höchstens geordnet abbrechen.

Deshalb ist es immer sinnvoll, brauchbares Markup zu schreiben - das ist auch für Anfänger und Freizeitcoder die Grundvoraussetzung. Als wäre das eine bloße Methodik für Profis - nein, insbesondere für Amateure ist eine einfache und klare Vorgehensweise hilfreich, um Problemen auf die Spur zu kommen. Will ich zu einer funktionierenden Site kommen, kann ich mir viele grobe Fehler einfach nicht leisten. Wie tolerant das Parsing ist, ist in dieser Hinsicht weniger wichtig, eher dass es *ein* definiertes Parsing gibt - was derzeit noch nicht der Fall ist, insofern kann man nur ungefähr wissen, welche Abweichungen praktisch harmlos sind - es sind nicht viele.

Doch die von Gunnar angesprochene Dimension ist nicht auszublenden, sondern die andere Seite der Medaille. Auch wenn es hier SELFHTML heißt, muss man einsehen, dass »der« Mensch nicht HTML kennen muss und HTML deshalb nicht diese klare Ausrichtung hat. Einerseits werden die Tools besser, HTML zu produzieren - ohnehin bestand schon immer die Möglichkeit, dass Tools tiptop-validen Code ausspucken, weil Validität erst einmal wenig bedeutet. Andererseits wird HTML, für den Anwender verborgen, durch unzählige Desktop- und Web-Anwendungen erzeugt, die das Veröffentlichen von Inhalten ohne technische Kenntnisse ermöglichen. Das ist heute sogar viel wichtiger als das Modell »Homepage« mit HTML.

Der HTML5-Impuls - insbesondere die Standardisierung des Parsing des existierenden Web-Contents, der eben nicht XML ist -, ist vor diesem Hintergrund keineswegs bloß ein »demokratischer« (»Coding for the masses«). Sondern vor allem aus Sicht derjenigen gedacht, die den entstehenden HTML-Code verarbeiten müssen. Die HTML5-Autoren sind keine Hypertext-Visionäre, sondern Angestellte von Browserherstellern und Techniker, die das Web als Plattform ernst nehmen und interoperable Rich Internet Applications bauen wollen. Dazu brauchen sie präzise technische Standards. Die HTML5-Spezifikation ist tausendmal schwerer lesbar als HTML4, weil es unzählige kleinliche Definitionen enthält, die für die normalen Anwender uninteressant sind, aber für die User-Agent-Programmierer essentiell. Was für die HTML-Amateure dabei wirklich auf der Nutzenseite übrig bleibt, muss man m.M.n. erst einmal sehen, das liegt für mich nicht so offen.

Mathias