UX & Webdesign

Klares Süppchen kochen. (X)HTML sollte schon schön sauber sein.

Eins vorweg: Sauberer Quellcode ist sehr wichtig und sollte immer das Ziel sein. Nicht nur der Standardkonformität wegen.

Würde sich alles so schnell entwickeln, wie vielleicht erträumt, dann hätte man bei Fehlern im (X)HTML-Quellcode sogar mit größeren negativen Auswirkungen zu rechnen. Diskutieren müsste man dann eher nicht mehr. Wie in Programmiersprachen auch, wäre es dann so, dass bei Fehlern in den meisten Fällen das Programm schlicht und ergreifend nicht läuft.

(X)HTML ist eine Auszeichnungssprache und lässt eben mehr Spielräume. Die Mühlen bei 3 mal W mahlen bekanntlich etwas langsamer. Und so ist es derzeit so, dass auch Websites, deren Quellcode mit 100 oder mehr Fehlern gespickt ist, im Prinzip meist einwandfrei funktionieren. Die Verstöße gegen die allgemein gültigen Regeln sind meist (noch) rein formaler Natur …

Diese Erkenntnis soll aber bitte kein Freifahrtschein dafür sein, sich nicht mehr um die Qualität seines Quell- und CSS-Codes zu kümmern.

So schwingt das nämlich derzeit bei der ein oder anderen Diskussion durch. Z.B. hier: Valid (X)HTML – Is it important?. Zumindest etwas kontrovers diskutiert. An sich ein guter Artikel mit guten Denk- und Diskussionsansätzen.

Angetrieben sind die neuerlichen Diskussionen wahrscheinlich auch durch die Ergebnisse der MAMA-Studie (Operas Studie zum Thema Standardkonformität von Websites). Der Artikel Operas MAMA-Studie: Die durchschnittliche Webseite validiert nicht beschreibt und kommentiert das Ganze ausführlich. Auch die anschließende Dikussion dazu ist einen Besuch wert.

Schlechter Code hat Konsequenzen

Die Auswirkungen sind bisher dann eher größer, wenn der Code nicht sauber und effizient im Sinne von Organisation ist. Dann nämlich wird man das früher oder später bei Wartungskosten merken. Dann, wenn man im Team möglichst schnell und effizient entwickeln muss. Dann, wenn es darum geht, dass Code schnell nachvollziehbar und wartbar sein soll. Dabei hilft es ungemein, sauberen und fehlerfreien Code zu schreiben. Es diszipliniert auf gewisse Weise. Etwas Disziplin und Konzentration haben noch nie geschadet.

Jens Meiert schreibt zu diesem und verwandten Themen immer wieder gelungene Artikel. Allgemein ist das ein Thema, dem er sich verschrieben hat und zu dem er vieles richtige zu sagen hat. Wer seine Artikel bisher noch nicht kennt, sollte sich das bei ihm mal ansehen: meiert.com

Bleib sauber – soweit’s geht (?)

Ganz deutlich bleibt festzustellen: Sauberen, d.h. validen und effizienten Quellcode zu schreiben, bedeutet in der Regel keinen Mehraufwand. Nur wenn man an die Grenzen der Machbarkeit stößt, sollte überhaupt über einen aktiven „Verstoß“ nachgedacht werden.

Diese Grenzen sind wiederum dehnbar. Muss man bei einer Warnung des Validators immer auf fehlerhaften oder gar korrupten Code schließen? Ein Beispiel:

line 90 column 616 – Warning: trimming empty <span>Warnmeldung nach HTML-Tidy

Bei welcher Gelegenheit hat man damit zu kämpfen? Genau, bei „runden Ecken“ z.B. Das wiederum ist ein anderes Thema. In diesem Sinne, schönen Feierabend.