Esprit & Schmackes

Aber sowas von in Stein gemeißelt

Eine Gegenrede zu David Beckers Artikel HTML-Validierung: Reine Zeitverschwendung, oder? so um die 2132 Wörter

David Becker hat auf phpgangsta.de einen Gast-Artikel mit der Headline "HTML-Validierung: Reine Zeitverschwendung, oder?" verfasst. Als ich diesen Artikel in meinem Feedreader sah, war ich ruhigen Gewissens davon ausgegangen, dass die Überschrift einfach nur Interesse wecken sollte und der Autor im Beitrag natürlich konsequent mit nein antworten würde.


Leider lag ich da falsch. Die Frage hat er nämlich wirklich ernst gemeint.

In der Einleitung stellt er direkt die Behauptung auf

Ob eine klare Antwort in dieser Thematik überhaupt möglich ist, sei vorerst offengelassen. 

wobei man das vorerst streichen könnte, da er sich bis zum Ende nicht auf eine Antwort festlegt. Stattdessen sammelt er einige halbgare Argumente pro und contra Validierung zusammen, bei denen sich einen die Fußnägel aufrollen, und kommt am Schluss dann auf den Trichter, die Wahrheit wäre nicht in Stein gemeißelt. Im Endeffekt hätte hätte er den ganzen Artikel auf diesen Satz beschränken können.

Das Meißeln würd' ich jetzt gerne nachholen. 

 

Re: Welche Vorteile ergeben sich durch validen Code?

 

Hier negiert er, dass Google Websites mit invaliden Code bestraft, und verlinkt dazu irgendeine Aussage irgendeines Google-Heinis. Untermauert wird das Ganze noch durch den Hinweis, dass in den Top-SERPs fast immer invalide Websites zu finden seien.

Das einzige Argument für Validierung sieht er in möglichen Anzeigeproblemen bei kommenden Browsergenerationen.

Zwei, drei Fehler auf einer Seite bleiben vielleicht ohne Konsequenzen, bei noch mehr invalidem Code wird die Seite dann aber vielleicht doch nicht mehr korrekt angezeigt.

Da kann man ja fast schon froh sein, dass er immerhin diese mögliche Konsequenz erfasst hat.

Warum denn nun wirklich validieren? Validität ist deswegen so wichtig, weil sie

  1. sich so gehört
  2. die Basis für weitere Must- oder Nice-To-Haves bildet, wie
    1. Browser-/Clientkompatibilität
    2. Suchmaschinenoptimierung
    3. Barrierefreiheit
  3. die Anzeige des gewünschten Layouts sicherstellt

Und zwar in dieser Reihenfolge. Und ich hab' da bestimmt noch einiges vergessen.

Man kommt ja heutzutage jobmäßig als Frontendentwickler oder Webworker oder weiß-der-Geier-Webmensch nicht mehr sehr weit, wenn man nur HTML und CSS beherrscht. Mindestens gute Kenntnisse in einer serverseitigen Scriptsprache und Javascript plus grundlegendes Wissen hinsichtlich Performance, Crossbrowserkompatibilität und SEO müssen's dann schon sein. Dass am Ende aber ohne Frage ordentliches, meint: mindestens valides HTML, herauskommen möchte, hat sich meiner Ansicht nach nicht geändert. Und das muss auch nicht explizit erwähnt werden. Sich an die Syntaxregeln zu halten, hat für mich nicht nur mit seiner persönlichen Meinung zu tun – weswegen ich die Leitfrage des Artikels an sich schon für peinlich bis bescheuert halte – sondern vorallem damit, die Grundkomponenten seines Jobs drauf zu haben.
Zudem gibt es mittlerweile so viele Helferlein, die einem bei der Generierung von validem HTML helfen. Es ist ja nun beiweitem nicht mehr so, dass man sein Markup noch händisch in einen Editor kloppen muss (obwohl man das trotz allem können sollte). IDEs, Frameworks, Templatesprachen können einen großen Teil der HTML-Generierung übernehmen. Das bisschen, was man noch selbst machen muss, das sollte dann doch bitteschön auch stimmen. Ohne, dass ich drum bitten muss.
Die Validierung einer Website ist außerdem der erste Schritt für die Optimierung in andere Richtungen, wie auch SEO – ja, auch wenn Google nicht pauschal invalide Sites abstraft, und ja, auch wenn Google selbst ordentlich invalide ist. Der traurige Fakt ist nunmal, dass eine plötzliche Abstrafung sich einfach einmal folgenlos im Kreis drehen würde, da so viele Sites Validierungsfehler aufweisen, dass sie sich im Suchranking gegenseitig einmal anti-überholen würden. Oder – und da würde ich wirklich gern mal in eine Paralleldimension reinschnuppern – der ganze Schwung an invaliden Web2.0-Sites suppt ans Ende der SERPs und auf den ersten Seiten landen noch die guten alten, selbstgehobelten Visitenkarten von damals™, als man sich noch ohne Diskussion an die Standards hielt oder einfach so wenig davon umsetzen musste, dass es kein Akt war.
 
Das Grundproblem ist einfach das: man möchte Inhalte in einem bestimmten Format liefern. Diese Inhalte werden von unterschiedlichsten Programmen eingelesen und dargestellt. Das beinhaltet Browser, Suchmaschinen- und andere Crawler, Screenreader und weiß Horst was noch. Auch wenn man seine Website nicht für alle möglichen Interpreter bewusst optimiert, möchte man doch allgemeinhin davon ausgehen, dass alle die Site zumindest fehlerfrei verarbeiten und anzeigen können. Und zwar auch in Zukunft mit der nächsten Version des Clients. Der kleinste gemeinsame Nenner ist hierbei einfach, sich an den Standard zu halten. Wenn man vom Standard abweicht, wie kann man dann davon ausgehen, dass jeder Client einem diese Fehler verzeiht? Auch die "zwei, drei" doch eigentlich konsequenzlosen Fehler? Zumal Fehler in der Technik nie wirklich ohne Konsequenzen sind – man hat vielleicht das Glück, dass ein Programm extra so fehlertolerant programmiert ist, dass es einem viel Scheiße verzeiht. Gerade die Browser haben da ja sehr hübsch vorgelegt (sonst springen ja die Nutzer ab, wenn im Browser eine Seite kacke aussieht – böser Browser!), weswegen es überhaupt zu so vielen invaliden Sites kommen konnte. Die können echt eine ganze Menge Quelltext-Mus schlucken, bis sie kotzen müssen. Hier muss man aber auch wieder den Begriff Browser auf die üblichen Verdächtigen eingrenzen: viele textbasierte Browser sind überhaupt nicht tolerant, und im von W3C entwickelten Teil Amaya sehen nach Stichprobentests nur die Seiten vom W3 noch so aus, wie sie sollen. Der Rest ist ziemlich viel Kotze.
Sich also auf die Fehlertoleranz der Clients zu verlassen, heißt, die Verantwortung abzugeben. Wenn ich die Verantwortung für meine Arbeit abgebe, kann ich schlecht die Hand dafür aufhalten.

Wer noch weitere Gründe für Validierung braucht (mein Beileid), kann sich dann gerne noch beim W3C belesen.


Diese Argumentation von Herrn Becker klingt so nach einem Freifahrtschein dafür, irgendeinen verkackten HTML-Brei hinzuschlonzen und so lange per Crossbrowsertests dran herumzupfriemeln, bis das Ganze überall einigermaßen passend aussieht, was so ungefähr dem entspricht, was ein Scriptkiddie mit Metasploit im Koffer kompetenzmäßig im Vergleich zum IT-Sicherheitsexperten darstellt. Einen Idioten mit Erfolgen.

 

Noch schöner, dass er sogar "klare Argumente" für invaliden Code findet. Halt-mich-fest, was hab ich gelacht.

 

Re: Kleiner Code oder Multibrowserfähigkeit?

 

Da wäre zum einen der Aspekt der Geschwindigkeit. Fehlerhaftes HTML kann z.B. kürzer sein als das valide Pendant. Kürzeres HTML nimmt weniger Platz in Anspruch. Gerade bei größeren Websites kann sich also invalider Code positiv sowohl auf Kosten als auch Geschwindigkeit der jeweiligen Website auswirken.

Ich muss das nochmal betonen: der Mann meint das wirklich ernst, und ich glaube, er darf auch frei draußen herumlaufen. Wir schreiben Schrottcode pro Performance, yeah! Damit unsere Inhalte möglichst noch schneller falsch ausgeliefert werden können! Man kann einen Haufen Scheiße auch mit Fähnchen schmücken, er stinkt trotzdem.
Ich mein – kürzer! Argh!

Außerdem hätte mich da mal ein Beispiel interessiert. Schreibt er dann statt dem div einfach ein d und freut sich der paar Zeichen weniger, während jede (Desktopbrowser-)Engine das große Heulen kriegt und sich fragt, warum sie kein XML-Parser geworden ist und die Annahme schlicht verweigern kann?

Ich bin ja nun absolut eine Verfechterin des Bandbreiteneinsparens. Es gibt aber gerade hier so dermaßen viele Ansätze, die man verfolgen kann, die allesamt mehr bringen als absichtlich Murks zu schreiben, um an der Dateigröße des HTML zu sparen. Wenn es hier schon Verbesserungspotenzial gibt, dann das, indem man eventuell vorhandene Containerverschachtelungen aufdröselt beziehungsweise allgemein die Menge an DOM-Elemente möglichst gering hält. Zusätzlich dazu könnte man entsprechend kurze Bezeichner für Klassen oder IDs verwenden, sowie Attribute wie title oder href immer in der selben Reihenfolge im Tag platzieren, was wohl auch das Parsing beschleunigen soll. Dafür muss man nicht explizit Scheiße schreiben - Scheiße muss ja, wie gesagt, auch erstmal im Parsing toleriert werden. Ich kann mir nicht vorstellen, dass das keine zusätzliche Zeit braucht.
Performance ist aber mehr, als am HTML herumzudrehen. Deutlich mehr, weswegen ich da, egal wie ich's drehe und wende, nichtmal im Ansatz zu einer ammortisierenden Kosten-Nutzen-Rechnung beim Einsatz invaliden HTMLs käme.

Shortlist dafür:

  • Zusammenfassen mehrerer JS- und CSS-Dateien zu jeweils einer Datei bzw. allgemein Verringern der HTTP-Requests
  • Minimierung der JS- und CSS-Dateien
  • Verwendung von CSS-Sprites
  • Verwendung optimierter Grafiken/sonstiger Multimediainhalte
  • Komprimierung aller Dateien, z. B. per gzip, außer Webfonts und andere vorkomprimierte Dateien
  • Einsatz eines CDNs
  • sinnvolle Verwendung von Expires-Headern
  • was Plugins wie Yslow oder PageSpeed Insights noch so vorschlagen

 

Weiteres Argument für den Schrottcode meint, dass es bei großen Sites sehr zeitaufwändig sein kann, "stundenlang jeden noch so kleinen Fehler in den Code-Massen auszumerzen". Ich würde ja mal sagen, wenn man seinen Job richtig macht, braucht man nicht so unheimlich viel Zeit zum Validieren. Und auch "Code-Massen" können sinnvoll und wartungsfreundlich erstellt werden. Auch das gehört zum Job. Man kann doch seinem Kunden schlecht sagen "Ich hab Ihnen hier so eine Website hingerotzt, die gerade so in den derzeitgen Browsern läuft und eigentlich totaler Scheiß ist, aber Ihr Geld wollte ich lieber in zweifelhafte Performanceverbesserung stecken". Wobei, vielleicht würde das der Autor sogar bringen. Die eigene Seite http://www.netzsieger.de ist ja selbstredend nicht valide, wofür ich mich bei dem minimalistschen Aufbau schon ein bisschen schämen würde. Es braucht andererseits natürlich auch ein starkes Selbstbewusstsein, sich öffentlich einzugestehen, dass man schlicht und ergreifend keinen Bock hat, seinen Code zu pflegen. Glückwunsch dazu.

Einen "möglichen Ausweg" beschreibt Becker unter

 

Re: HTML5 als Kompromiss

 

was ich auch nach dreimaligem Lesen schlichtweg nicht kapiert habe.

Einen möglichen Ausweg bietet eventuell der Umstieg auf HTML5. Das role-Attribut ist z.B. hilfreich, sinnvolle Markierungen auf einer Seite zu setzen, die sich wiederum günstig auf die Barrierefreiheit auswirken. So nützlich diese Funktion auch ist, hat dies für gewöhnlich invaliden Code als Konsequenz. HTML5 erkennt jedoch dieses Attribut, würde also gleichzeitig Barrierefreiheit und Validierung zugutekommen.


Also, HTML5 finde ich ja auch ganz kuhl, und das role-Attribut hat tatsächlich was mit Accessibility zu tun. Geschenkt.
Aber was sagt uns das jetzt zur Validierung? Weiß das jemand? Wovon spricht der Mann da? Dass HTML5 allgemein mit vielen sinnvollen Tags, Attributen und Zeugs daherkommt, sehe ich auch. Warum das Ganze als Kompromiss für (?) oder gegen (?) Validierung gelten soll, weiß ich aber nicht. Diese neuen Möglichkeiten mögen einem vielleicht diverse Situationen ersparen, in denen man notgedrungen invalides HTML geschrieben hat, aber wo bleibt denn dann die Performance des kürzeren HTMLs? HTML5 ist auch wieder nur ein Standard, gegen den man validieren sollte. Die Vorteile dieser Version sagen nichts zur Frage Validierung ja oder nein aus.
Auch hier muss der Autor nochmal darauf hindeuten, dass HTML5 + Crossbrowserkompatibilität derzeit noch Mehrarbeit erfordern – da scheint er ja echt gegen allergisch zu sein. Igitt, ein Elch.

Der gnädigerweise letzte Absatz schwadroniert dann von der angesprochenen Unmöglichkeit, die Leitfrage zu beantworten.

 

Re: Die Wahrheit ist nicht in Stein gemeißelt

 

Ist sie wohl! Man meißle bitte zweihunderachtundsiebzig mal "Validiert euren scheiß Code, ihr Penner!" in den härtesten zu findenden Stein.
Um das klarzustellen und auch mal was Konstruktives zu sagen: Es ist freilich immer möglich, in Situationen zu landen, in denen man Kompromisse eingehen muss. Wir hatten als Beispiel bestimmte Javascript-Bibliotheken mit HTML4 eingesetzt, die die DOM-Elemente mit custom Attributen belegt haben, um beispielsweise für die Sortierung darauf zugreifen zu können. Die Applikation war damit natürlich nicht valide, aber das Risiko sind wir nach Abwägung bewusst eingegangen. Das bedeutet auch, damit zu rechnen, dass der Quelltext jederzeit nicht mehr korrekt eingelesen werden kann. Das bedeutet auch, sich dafür nicht auch noch auf die Schulter zu klopfen ("Die Site performt jetzt bestimmt super!"). Das bedeutet nicht, sich zu fragen, ob die Validierung Zeitverschwendung sei. Man validiert so gut wie möglich und verbleibt mit einem nagenden Gefühl des Unbehagens.

 

Unter dem Artikel ist noch eine Umfrage eingefügt "Validierst du deinen HTML-Code?" (ich hätte da noch ein "und wie sehr schämst du dich dafür?" angehängt), die derzeit von "Gelegentlich, wenn ich Zeit habe" angeführt wird, dicht gefolgt von "Ja, immer". Immerhin hat bislang niemand die Option "Nein, war mir der Möglichkeit gar nicht bewusst" gewählt, das lässt etwas hoffen...

 


Um auf die Frage des Herrn zu antworten, der bestimmt ein ganz netter und liebenswerter Mensch ist: HTML-Validierung: Reine Zeitverschwendung, oder? Ja. Für dich schon.

 

Kommentare

bislang eingetrudelt: 1 Kommentare

[ 1 / 1 ]

Ich versteh zwar inhaltlich nicht alles....

... aber der mit dem Elch ist nicht schlecht (insider).

[ am 13.08.2016 um 11:48 Uhr ]

was zu melden?