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.
@webzeugkoffer sagt:
So. Passend zur kalten Jahreszeit was über Süppchen. #xhtml #validation und so http://tinyurl.com/5vhnjo
4. Dezember 2008 — 22:14
ReneS sagt:
Bin voll auf Deiner Seite. Es muss validieren, ansonsten verstecken sich Fehler, die unerkannt bleiben oder es geht, man hat aber Dinge übersehen… die sich irgendwann mal melden.
4. Dezember 2008 — 23:06
GE sagt:
Hallo, leider wird es sich kein Browserhersteller leisten können, einen Browser herauszubringen, der invaliden Code nicht anzeigt, die Arbeit einstellt oder eine Fehlermeldung bringt, wie z. B. bei Programmiersprachen wie php. Diesen Browser würde nämlich niemand benutzen, weil er dann nur 4% aller Internetseiten zu sehen bekäme (MAMA-Studie).
Man kann wohl auch nicht die Webdesigner verpflichten, einen Validierungslink auf jeder Seite zu platzieren.
Die Browserhersteller könnten aber etwas tun, z. B. an prominenter Stelle einen Button platzieren, der die aktuelle Seite mit dem W3C-Validator validiert. Somit könnte jeder Besucher, den das interessiert, die technische Qualität einer Seite prüfen, auch der Auftraggeber und Betreiber der Seite. Das würde die Webdesigner und -agenturen gehörig unter Druck setzen.
12. Dezember 2008 — 11:27