W3C und ihre Validatoren Technikwürze 44

Technikwürze vierundvierzig. Hier ist euer Design- und Webstandards-Podcast von Montag, den 30.10.2006. In der Technikwürze Folge eins und Folge drei hatte ich mich mit Sirk Bornemann unterhalten. Er war der Erste, der mir geholfen hat, den Technikwürze-Podcast überhaupt ins Leben zu rufen. Und, Sirk Bornemann ist hier, sitzt noch bei mir. Ich hab 'n ganz langes Interview mit ihm gemacht, was wir in zwei Teilen aufteilen.

Das heißt jetzt in Technikwürze vierundvierzig gibt es Teil eins und nächste Woche Montag Technikwürze fünfundvierzig dann den zweiten Teil. Wir haben uns unterhalten, haben 'n bisschen Rückblick gemacht in Technikwürze, haben uns über die Validatoren vom W3C unterhalten, darunter den Unicorn, den normalen und auch, mit Rückblick dann auf den Validom. Und des Weiteren haben wir uns unterhalten über den Internet Explorer 7, und den Mindtype von JavaScript.

Interview.

Die aufmerksamen Hörer von euch werden sicherlich festgestellt haben, dass ich am Anfang die Sendung aufgenommen hatte, zumindest Folge eins und Folge drei mit dem Sirk Bornemann. Und seitdem hat sich der Schlingel nicht mehr blicken lassen. Heute ist Sirk wieder dabei. Hallo Sirk.

Hallo.

Sirk hat's endlich mal wieder in die Sendung geschafft und wir reden heute mal 'n bisschen über Technikwürze. Wie war's damals? Was haben wir uns da für Gedanken gemacht? Dann reden wir 'n bisschen vom Validator des W3C. Da gab's mal Unstimmigkeiten und, 'n bisschen was über Mindtype von JavaScript. Aber erst mal so Technikwürze. Ich weiß gar nicht mehr. Bin ich auf dich zuge..., hab gesagt: „Komm, ich will mal 'n Podcast machen, mach mal mit." Wie war 'n das? Hast du das noch in Erinnerung?

Ich glaub, das war damals 'n Geben und Nehmen. Ich bin auf dich zugekommen und da hast du gesagt, du hilfst mir nur, wenn du mir auch bei Technikwürze 'n bisschen mithilfst. Und die Idee fand ich aber so gut, dass ich, spontan Ja gesagt habe. Leider, musste ich mich dann relativ schnell zurückziehen, weil ich, doch, anderweitig in andere Projekte eingebunden war und, die Zeit wirklich nicht aufbringen konnte. Das tut mir auch sehr leid. Ich versuch das jetzt 'n bisschen wieder gutzumachen.

Ja, ich musste, ich musste über vierzig Folgen ohne dich machen. Ich hab's ja kaum ausgehalten. Nein, aber trotzdem. Aber ich kann mich dran erinnern, Folge eins, wie viel Stunden wir wirklich... Ich glaub, die Folge schlussendlich hat, für die User zum Download, ich glaub, waren's vielleicht zwanzig Minuten oder waren's sieben Minuten vielleicht sogar und wir haben wirklich stundenlang dafür gebraucht.

Wir haben uns totgequasselt ohne Ende und also ich für mein Teil, ich war wirklich hypernervös und ich hatte Lampenfieber und dachte: „Oh, was, was, was ist das für 'n Millionenpublikum, was jetzt lauscht?" Aber schlussendlich war's eigentlich Pillepalle. Aber wir haben uns echt viel Stress gemacht, ne.

Ja, das ist richtig, David. Das ging mir aber ganz genauso. Das erste Mal ist immer das schwerste und die folgenden Male,, flutscht das schon leichter. Ja, aller Anfang ist schwer und ich denke, also zumindest du bist jetzt, ziemlich routiniert da drin.

Na ja, noch nicht. Also ich denke, ich hatte ja, wie vorhin schon erwähnt, dass ich manchmal 'n Sonntag hatte, wo ich gesagt hab, also sonntags kann ich generell kein Technikwürze aufnehmen, weil da krieg ich nix gerallt. Jetzt die letzte Ausgabe hab ich mal Sonntag gemacht, also scheint's wohl nur daran zu liegen, wie ich gerade gut drauf bin. Also ich denke, das kann gut, gut klappen. Also ich denke, heute kriegen wir's auch ganz gut hin, ne.

Ja, das hoff ich doch.

Wir hatten in der vorletzten Ausgabe hatten wir 'n bisschen was vom, Unicorn, dem Validator des W3C, veröffentlicht. Damit warst du nicht ganz einverstanden. Was kannst du uns über Unicorn erzählen?

Eigentlich nicht so viel mehr als das, was ihr auch gesagt habt. Nur mir ist eben aufgefallen, dass ihr so 'n bisschen was an Informationen unterschlagen habt. Mir ist ganz wichtig, darauf hinzuweisen, dass Unicorn, bisher nicht expressis verbis der neue Validator des W3C ist. Es ist ein eigentlich ein Testobjekt, das W3C, um für die Entwickler, die daran arbeiten, auch eine öffentliche Oberfläche,, zu bieten, um, um Feedback einzusammeln.

Es ist bisher nicht gesagt, dass dieser Unicorn Validator, den bisherigen Validator oder die bisherigen Validatoren ablösen wird. Wie gesagt, es ist ein Test, Ballon, an dem auch noch heftigst gearbeitet wird. Und, deshalb mein Hinweis:, verlasst euch lieber auf die bisherigen Validatoren als auf Unicorn. Unicorn hat garantiert noch einige Fehler und, es wäre nicht gut, wenn man das jetzt schon als, den, stabilen und, fertigen Ablösevalidator hinstellen würde.

Also bisher sollten die User echt wirklich auf den W3C Validator hoffen und ihre Webseiten, auf Validität prüfen. In welche Richtung soll denn der Unicorn gehen? Weißt du da Genaueres?

Eigentlich auch nur so viel, wie ihr berichtet habt. Es ist tatsächlich so, um's dem, Nutzer einfacher zu machen, alle Validationsmöglichkeiten in einer Oberfläche mit einem Klick, abzuarbeiten. Bisher ist es ja so, dass es, für die Markup-Sprache HTML, oder XHTML einen Validator gibt. Dann gibt es einen CSS Validator und es gibt einen, Validator, der auf Barrierefreiheit prüft. Und, das ist-

Das waren bisher tausend Schritte auf einmal irgendwie, ne. Und viel Zeit.

Richtig. Und das ist ein bisschen, umständlich, zumindest für den, Feld-, Wald- und Wiesennutzer. Und man versucht eben jetzt mit Unicorn im Grunde alle Schritte mit einem Klick unter einer Oberfläche zu vereinen.

Also ich hab mir nur noch nicht angeschaut, muss ich sträflicherweise sagen. Also wie ich mir das vorstelle unter einem Klick heißt, ich geb meine Webseitenadresse ein und, er validiert einerseits HTML, d-das DOM validiert er, dann validiert er CSS gleichzeitig, holt sich also aus dem Quelltext die CSS-Dateien. Validiert die und wenn er 'n Feed findet, validiert er 'n Feed oder wie kann ich mir das vorstellen?

Das weiß ich jetzt gar nicht genau, ob er gleichzeitig den Feed validiert, aber er guckt zumindest, ob die Seite, bestimmten, Ansprüchen für Barrierefreiheit genügt. Das ist bisher eben auch nur in 'nem Extraschritt, möglich gewesen. Und, ja, wie gesagt, der Unicorn, der soll das eben alles unter einer Oberfläche vereinen.

Ist aber ganz wichtig: noch Alphaphase. Das ist eigentlich, du hast anfangs erwähnt, war sich das W3C-Team nicht sicher, ob sie das überhaupt öffentlich machen, aber für die, Validatoren oder für das Team selbst ist es natürlich einfacher, wenn sie's unter einer Weboberfläche selbst haben und müssen sich nirgendswo einloggen.

Aber das Ganze ist wie gesagt Alphastatus und man kann mal reinschauen, sollte aber doch besser lieber erst mal den bekannten umständlichen Weg über die normalen Validatoren wählen, ne.

Richtig. Also es steht auch ganz,, dick im Grunde auf der, Unicorn-Seite drauf. Unicorn ist sogar Alphatest. Also da kann sich noch so viel ändern und es sind garantiert noch so viele Fehler drin. Ich würde es nicht als verlässliches Instrument, jetzt oder in näherer,, Zeit, betrachten. Wie gesagt, es ist 'n, es ist 'n Testobjekt, an dem im Moment ganz schwer gearbeitet wird.

Ihr müsst so 'n bisschen entschuldigen, wenn ich 'n bisschen schmatze. Wir essen nebenbei 'n bisschen, Kaffee und trinken Kuchen, hätte ich mal gesagt. Wir haben 'n paar Kekse hier. Stört euch nicht dran. Wenn wir zu schlimm sind, dann spult einfach 'n bisschen was vor. Unicorn. Was ich noch auf der Agenda stehen habe, ist Validome. Validome hat mit dem W3C jetzt überhaupt nix zu tun, aber stehen die 'n bisschen in Verbindung irgendwie?

Die stehen neuerdings in Verbindung. Da kann ich eben im Grunde jetzt wirklich brühwarm, neue Sachen erzählen,, weil ich das direkt von der Mailingliste habe. Ich arbeite selber in bestimmten Grenzen an dem, W3C Validator mit und,, les eben die entsprechenden Mailinglisten, die Entwickler-Mailinglisten auch.

Und, in dieser Woche, hat man sich verabredet,, zwischen, W3C, Validator-Team und Validome-Team, dass man,, zusammenarbeitet und da, mal guckt, was hat der eine gemacht, was, macht der andere. Und da eventuell auch,, gegenseitig Verbesserungen einpflegt.

Ja, ja.

Zur Erklärung sei gesagt, für die, die's eben nicht wissen: Validome, was ist das? Validome ist im Grunde, kann man sagen, 'n privates Projekt, Validator-Projekt,, ins Feld geführt vom, SelfHTML-Team in Deutschland, die ja die berühmte, -

SelfHTML.

SelfHTML, die, die, die mittlerweile ja, kann man auch sagen, On-Online-Community, drum rum, gestrickt haben. Und, ja, die haben eben Validome auf die Beine gestellt, ein, ein Validator, der in Teilen sogar etwas ausführlicher in seiner Fehlerberichterstattung ist als der Original W3C Validator.

Das W3C weiß, um, um diesen Lapsus, da wird auch dran gearbeitet und wahrscheinlich nicht zuletzt deswegen, geht man da aufeinander zu- -einfach um, die Ressourcen,, besser, zu teilen, weil das W3C eben auch nur begrenzt,, personelle Ressourcen hat, um so 'n Projekt, weiterzuführen.

Da könnte ja eigentlich 'n Szenario sein, dass die beiden Validatoren dann irgendwann verschmelzen und, sich die beiden Entwicklerteams so zusammentun, dass sie dann für einen Validator was machen. Oder ist das für dich unrealistisch?

Das weiß ich nicht, aber ganz unrealistisch ist es nicht. Es läuft schon zum Beispiel hinaus bei dem Tidy-Projekt. Einigen wird ja das Programm Tidy vielleicht in Erinnerung sein, womit man, Webseiten säubern kann, wie's der englische Name auch sagt, um im Grunde eine Webseite fertigzumachen für den Validator, damit sie eben dem Validator nicht allzu viel Kopfzerbrechen bereitet, sondern im Grunde nur ein Okay, ist valide, ihm ab, nötigt.

Mit Tidy kann man eben prima, unordentlichen HTML-Code, der nicht valide ist, automatisch aufräumen lassen.

Stichwort Tidy ist vielleicht ganz gut, weil eigentlich bist du ja der mehr oder weniger der Tidy-Experte hier.

Na ja.

Also was ich zum Beispiel ganz gerne nutze, haut jetzt vielleicht nicht ganz in dein Metier, ist zum Beispiel HTML Tidy. Das ist 'n Firefox-Plugin, was live direkt überprüft, ob die Webseite valide ist. Ist in den Resultaten nicht genauso wie der W3C Validator, wenn ich manuell jetzt die Webseite überprüfen lasse. Zeigt mir aber, ganz schnell mal eben beim Programmieren oder beim Schreiben von HTML, ob das Ding okay ist, ob das Ding valide ist oder nicht.

Was hast du denn mit Tidy zu tun generell?

Auch da häng ich so'n bisschen, drin in dem Projekt. Ich habe von Tidy mal ein anderes Projekt übernommen, Mod Tidy. Das ist 'n Apache-Modul, was die Pa-- Tidy-Bibliothek nutzt und im Grunde, genau das Gleiche macht, nur automatisch vom Webserver,, die ganze Geschichte parsen lässt. Und, dieses Projekt hab ich übernommen, sonst wär's in der Versenkung verschwunden und,, seitdem führ ich das als Open-Source-, Projekt weiter.

Und seitdem weiß ich eben auch so'n bisschen, wie's um Tidy steht und bin mit den Entwicklern in Kontakt. Kenne den einen auch, den einen der Haupt-, entwickler persönlich, das der Björn Hörmann. Und der Björn, der steckt eben auch maßgeblich, oder was heißt maßgeblich? Das ist jetzt falsch, gesagt. Björn hat auch, seine Finger im Validator-Team drin und ab und zu korrespondieren wir eben.

Und, von Björn weiß ich zum Beispiel, da komm ich jetzt wieder zum, zum Faden zurück, vom Björn weiß ich, dass, das Tidy-Projekt und das Validator-Projekt sehr eng miteinander zusammenarbeiten. Und es in naher Zukunft oder in ferner Zukunft auch so sein wird, dass das eine Projekt das andere übernimmt. Das heißt, der Validator wird Funktionen anbieten, die Tidy anbietet und, beziehungsweise Tidy wird, Validatorfunktionen anbieten, wobei die erstere Möglichkeit die wahrscheinlichere ist.

Und, auch vom Björn weiß ich, dass Tidy in einigen Belangen sogar penibler ist als der Original W3C Validator.

Ah ja.

Das heißt, wo Tidy manchmal Fehler anmeckert- -die, der Validator durchgehen lässt, das ist ganz bewusst so. Und, da hat Björn auch die Finger drauf und steht teilweise in harter Diskussion mit dem Validator-Team, weil er die Spezifi-Spezifikation, so wie sie gefasst ist, sehr genau nimmt. Und sagt, alles das, was in der Spezifikation so nicht drinsteht oder anders drinsteht, das setz ich in Tidy nicht um.

Das heißt, dann muss sich vorher das HTML-, Team zusammensetzen und die Spezifikation entsprechend klarer fassen und erst dann schreib ich Tidy so, dass es die Spezifikation entsprechend umsetzt. Ansonsten bin, sagt er, bin ich des Teufels Advokat und setze die Spezifikation knallhart im Wortlaut um. Und das bedeutet in der Praxis manchmal, dass Tidy ganz harsch und knallhart, sagt: „Nein, ist 'n Fehler“, oder „Nein, das ist 'ne Warnung“, wo der Validator noch relativ lax drüber geht.

Was im Prinzip ja eigentlich auch in Ordnung ist. Also wenn ich mich an die Regeln halte, sagst-- sei es jetzt Webstandards oder Barrierefreiheit oder eben auch die, denn, stütz ich mich aufs Regelwerk und versuch dann da meine Sachen entsprechend... Also ich find das schon okay von der Vorgehensweise generell. Deinen Namen seh ich aber auch auf der W3C-Seite. Also wenn ich jetzt 'n bisschen gucke und ich lad mir die Quellen runter, dann find ich auch teilweise 'n paar Sachen von dir, ne?

Ja, da muss ich, ich bin neuerdings auch dort verlinkt. Allerdings, hört es sich dann mehr an, als ich dann tatsächlich noch tue. Ich, arbeite den schon zu, dem Team. Bisher mach ich, ganz offiziell die, RPM-Pakete für SUSE Linux. Da hab ich jetzt auch 'n, Fuß im Brett, bei Novell SUSE, dass ich offiziell auf dem, in dem Build Service, Service meine Pakete einspielen kann und auch pflege. Ich bin also offizieller Maintainer dafür.

Und außerdem bin ich nach Absprache auch, mit dem Olivier Thereau, der, hauptsächlich das, Validator-Projekt leitet, bin ich auch involviert in die Fehlerbehandlung. Nur da hatt ich in der letzten Zeit, leider zu wenig Zeit, tatsächlich Arbeit reinzustecken. Da werd ich mich aber im Moment, wieder mehr reinknien, um, tatsächlich auch Programmierarbeit da, reinzustecken.

Was heißt jetzt tatsächlich, Fehlerbehandlung? Die Ausgabe von Fehlern oder, oder selbst Fehler innerhalb des Quelltexts?

Nein, es geht um, die Fehlerausgabe. So wie ich das eben angedeutet habe, dass Tidy in einigen Belangen, penibler ist und auch manchen Fehler, bemängelt und in mancher Hinsicht auch etwas, präziser in der Formulierung dieser Fehler ist. Das heißt, der Anwender, der, einen, einen Fehlerbericht von Tidy oder vom Validator, bekommt, der soll natürlich möglichst genau wissen, wo der Fehler ist, was er falsch gemacht hat.

Und, in manchen Belangen ist dem W3C selber dieser, dieser Fehlerbericht des Validators, noch verbesserungswürdig. Der ist zwar schon gut, aber in, Sachen, manchen Sachen noch verbesserungswürdig. Und, da helf ich auch mit, das zu verbessern beziehungsweise die Formulierung, präziser, hinzubekommen. Das ist schwerer, als man, denkt, weil das wirklich 'n rel-relativ kompliziertes Framework ist, was dahinter steht. Und, ist nicht ganz einfach.

Zumal, eben auch sehr viele Testsuiten dann herhalten müssen, die das Ganze dann testen sollen.

Wie kann ich als Webentwickler denn Tidy einsetzen für meine Belange? Oder wann sollte ich's zum Beispiel nicht einsetzen?

Wann solltest du's nicht einsetzen? Das ist jetzt 'ne schwere Frage. Ich kann so-

Wie, wie kann ich als Webentwickler am schnellsten Tidy einsetzen? Oder, oder wie mach ich das? Hau ich das-- Ist das 'n Modul, was ich auf meinen Server haue? Oder wie funktioniert das ganze Ding?

Es gibt verschiedene Möglichkeiten. Eine Möglichkeit hast du eben selber aufgezeigt. Das ist dieses,, Firefox Plugin. Das heißt, glaub ich, sogar HTML Validator. Validator heißt es fälschlicherweise, obwohl kein Validator da drin ist, sondern nur Tidy. Und Tidy ist, explizit, das sagt, d, sagen die Projektleiter selber, kein Validator. Tidy ist kein Validator, erfüllt keine Da-Validatorqualitäten.

Richtig. Ich hab's grade mal aufgerufen bei mir in Firefox. Zwei HTML Validator heißt das Ding. Ist zwar mit Tidy betitelt, heißt aber HTML Validator. Und das ist falsch.

Die Bezeichnung ist im Grunde falsch, weil es eben kein Validator ist. Ja. Tidy ist ein Werkzeug, um, Ja, kaputte Webseiten sauberer hinzukriegen und im Grunde validierungsfähig, zu machen. Aber es validiert nicht. Das ist ein ganz großer Unterschied.

Zeigt eben nur an, ob irgendwelche Fehler eventuell da sind oder nicht. Aber es macht nicht sauber, was, was Tidy als Modul ja eigentlich macht.

Richtig, genau. Und, dahin wird wahrscheinlich der Validator, aber tatsächlich der W3C-Validator eines Tages kommen. Zumindest ist das von dem Validator-Team angedacht, dass der Validator auch tatsächlich Tidy-Fähigkeiten hat und, tatsächlich beim Validierungsvorgang auch, zumindest nach, Rücksprache mit dem Benutzer, die Fehler, ändern kann, raushauen kann.

Was gibt's für andere Anwendungsmöglichkeiten neben diesem Firefox-Plugin? Wie, wie kann ich Tidy nutzen?

Ganz klassisch gibt es Tidy als Kommandozeilenwerkzeug, was man als E-- unter Windows als EXE-Datei oder-

Du brauchst noch Kaffee, ne?

Ja, hab ich. Als, unter Windows als EXE-Datei benutzen kann oder, unter Linux oder Mac auch als ausführbare Datei. Das ist wie ’n ganz normales Kommandozeilenprogramm, wo man dann eben auf der Kommandozeile sagt, Tidy, und dann irgendwelche Optionen. Eingabedatei, Ausgabedatei. Das ist die profanste Anwendung. Da-damit ist im Grunde Tidy auch, groß geworden, bekannt geworden.

Irgendwann gab's mal, dann von dem Tidy-Team, den Wunsch, Tidy aufzusplitten in, diese Tidy-Frontend-Geschichte und, zu splitten von der Tidy Lib, der eigentlichen Bibliothek- -die die Arbeit macht. Das ist die Tidy Lib. Weil man nämlich dann so die Möglichkeit hat, die Tidy-Funktionalitäten in andere Wenden, Anwendungen viel leichter auszulagern, wie zum Beispiel eben dieses,, Firefox-Plugin. Das Firefox, Firefox-Plugin wäre ohne diese Tidy-Bibliothek gar nicht möglich. Ne?

Und, des Weiteren ist Tidy integriert als,, Modul in, PHP. Bei, unter PHP4 musste man sich’s, glaub ich, noch extra runterladen. In PHP5 ist es standardmäßig integriert.

Ah.

Und man muss es im Grunde nur mit einer Konfigurationsop, Option ein- oder ausschalten.

Ja. Das heißt, wenn ich’s eingeschaltet habe, werden aus meinen MOOCs CSS-Dateien dann eben, HTML-Dateien eventuell dann sauberer.

Eventuell, wenn du auch das eingeschaltet hast.

Ja. Obwohl das natürlich nicht heißen soll, liebe Leute, dass ihr jetzt, Schmu baut und dann wieder zurückkehrt zu euren tabellenbasierten Layouts. Macht die dann eben schrecklich und, achtet nicht drauf und lasst den Tidy den Rest machen. Macht es bitte sauber. Aber für den, für die restliche Sicherheit ist es dann doch ganz gut, wenn man sich auf Tidy stützen kann, ne?

Also es gibt, viele HTML-Sachen, die so schlimm sind, dass selbst Tidy dann die Flügel streckt. Da sagt es dann eben auch: „Also tut mir leid, mach’s erst mal so, dass ich’s einigermaßen verstehe.“ Aber, man ist bei einigen Sachen doch immer wieder erstaunt, bei, nach einem Durchlauf durch Tidy, was da, für toller, sauberer Code rauskommt. Und, Ty, Tidy ist hoch konfigurierbar.

Man hat so viele Konfigurationsoptionen, das würde jetzt den Rahmen sprengen, wenn ich das alles mündlich aufzählen würde, was man damit alles machen kann.

Ja. Ich glaub, vor einem Jahr, als wir Technikpur zu gestartet haben und, haben uns mal ein bisschen über Tidy unterhalten, sagtest du, man kann es zum Beispiel auch lokal in der Entwicklung einsetzen, dass man das jetzt so konfiguriert in PHP, dass der die Ausgaben dann eben über ’n Tidy haut und das sauber macht. Jetzt wär’s natürlich auch denkbar, wenn ich das auf ’nem Live-Webserver mache. Davon ratest du oder rietest du damals ab, ne?

Dadurch, dass der, Säuberungsvorgang durch Tidy ja auch immer ein bisschen Zeit, braucht, beziehungsweise das Ergebnis nicht unbedingt, vorhersehbar ist. Also ich würd mich immer auf mein Fachgespür verlassen, als blind so einem, Tool zu vertrauen.

Ich würde es immer mit der Option betreiben, dass er mir die Fehler eben anzeigt und ich manuell diese Fehler, beseitige, weil ich dann im Zweifelsfall selber entscheiden kann, ist der Fehler vielleicht, von mir sogar gewollt, aus ganz bestimmten Gründen? Soll ich ihn so drinlassen oder muss der jetzt rausgehauen werden? Solche Szenarien gibt es in der Praxis tatsächlich, dass bestimmte Sachen so stehen bleiben sollen. Ja. Und, deswegen würd ich abraten, das automatisch machen zu lassen.

Zumal das ja auch immer ’n bisschen Performance-Einbußen bedeutet. Grade im, im Live-System, wo’s manchmal dann wirklich bei vielen Zugriffen auf die Millisekunde ankommt. Deswegen würd ich solche Sachen immer, im, im Hintergrund machen, im, im, im Vorfeld.

Was ich aber jetzt machen kann, wenn ich jetzt ’n Server habe und da läuft PHP5 beispielsweise drauf oder ich hol mir eben die Bibliothek über PHP4 manuell und ich richte das dementsprechend ein, dass ich ’ne Webseite jetzt entwickel und der spuckt mir dann, sind es denn wahrscheinlich Laufzeitfehler oder, oder was passiert da mit dem Tidy? Wie verhält sich das denn in der Umgebung?

Also schau ich mir mein Ergebnis in HTML im Browser an und der zeigt mir ’n paar Sachen oder ruf ich da ’ne extra Adresse auf, ’n Validator-Tool? Oder wie funktioniert das dann?

Er sollte eigentlich, wenn die Konfigurationsoption standardmäßig so eingeschaltet ist, sollte er ’n Fehlerreport liefern. So und, -

Direkt auf der Webseite.

Direkt auf der Webseite, richtig. Das kann ich aber, glaub ich, auch ausschalten und dann zeigt er halt die Webseite an und dann, zeigt er mir das in ’nem anderen Fenster oder in ’ner Datei an. Das kann ich individuell konfigurieren.

Also es ist grade für Anfänger interessant, die sich, die vielleicht noch nie solche Profis in XHTML oder CSS sind, dass die das Ding erst mal standardmäßig vielleicht einschalten und wirklich auch so ’n Lernprozess durchmachen, dass der gleich direkt ausspuckt: „Hier hast du ’n Fehler, guck dir das bitte noch mal an“, ne?

Also, Tidy, egal in welcher Anwendung, ist sowieso jedem empfohlen, egal ob Anwender oder Profi. Der Profi wird’s halt, vielleicht weniger, benötigen, weil er sich bestimmte Sachen schon angeeignet hat und, bestimmte Fehler nicht mehr macht. Aber es gehört für mich zum unersetzlichsten Tool überhaupt, in der, in der, Verarbeitung von, von HTML-Webseiten.

Einfach, um nicht, also wenn ich, wenn ich mir auf die Fahnen geschrieben habe oder, schon wünsche, dass ich valide, saubere Seiten, abliefere ins Netz, dann ist für mich so ’n, Tool unersetzlich, ja.

Was ja teilweise auch Grundvoraussetzung für die BITV ist zur Anwendung, barrierefreier oder zugänglicher Webseiten, dass BITV in einer Richtlinie auch sagt: „Du musst jetzt, valide Seiten abliefern.“ Das ist der Grundstock und eigentlich auch das Selbstverständnis von uns Webdesignern. Also

Also gut, man kann sich jetzt an die BTV festhalten und sagen, da ist so was gefordert. Das ist für mich einfach ein Selbstverständnis fürs Arbeiten. Genauso wie wenn ich ein Buch schreibe oder eine andere Publikation öffentlich mache, dann bemühe ich mich auch um korrekte Rechtschreibung und liefere die da nicht irgendwas ab, sondern liefere da eben die Sache sauber ab, sodass es möglichst jeder lesen kann und keine Lese- oder Verständnisprobleme bekommt.

Und genau das gleiche Thema haben wir hier im Fall von HTML-Seiten oder Webstandards.

Finde ich vielleicht die beste Umschreibung für das, worum es eigentlich geht. Warum eigentlich? Ich nenne es mal gutes Handwerk abliefern. Genau deswegen. In Deutschland ein Buch schreiben, finde ich super, denn du schreibst auch keinen Schmu rein mit deinen Rechtschreibfehlern, sondern lässt einen Lektor noch mal rüberschauen. Und bei Webseiten soll das genauso ausschauen.

Ja, genau so. Das ist eigentlich der einfachste Grund. Ich brauche nicht irgendwelche Vorschriften, die mir das einfach vorschreiben und dann halte ich mich dran, sondern das ist einfach gesunder Menschenverstand. So und der hat halt anscheinend ein bisschen manchmal gefehlt, weil die Kultur im Web einfach nicht so war, dass man so was eingefordert hat.

Aber das Web hat sich eben in eine bestimmte Richtung, die vorhersehbar, sage ich jetzt mal in Klammern, weiterentwickelt und es ist einfach notwendig, saubere Seiten, saubere Webinhalte ins Web zu legen, weil es auch immer unvorhersehbarer wird, mit was für einem Endgerät ich überhaupt diese Webseiten abrufe. Wir haben jetzt Mobiltelefone, die Webinhalte abrufen können. In ein paar Jahren sind es ganz andere Geräte. Das Web wird immer mobiler.

Es wird immer unkalkulierbarer, mit welchen Geräten der Endanwender auf diesen Inhalt zugreift. Und dann möchte ich doch das Wenigste dafür getan haben, indem ich eine saubere Syntax abliefere. Und das ist eben durch so ein Tool fast, kann man sagen, garantiert. Zumindest ist man auf einem sehr guten Weg da dazu mit Tidy. Und wenn man dann noch im Endschritt das dem Validator vorgibt, dann sollte man auf der sicheren Seite sein.

Also ich habe es eigentlich lange jetzt nicht erlebt, dass ich irgendwas, was ich durch Tidy habe durchlaufen lassen, was in dem Validator einen Fehler produziert hat. Also von daher ist das für mich nur noch eine schöne Übung irgendwie, das dem Validator zu geben, um dann zu sehen, ja, ist okay.

Das war der erste Teil vom Interview mit Sirk Bornemann. Ihr hört in der nächsten Sendung von Technikwürze, nämlich der 45 nächste Woche Montag, den zweiten Teil. Unbedingt reinhören. Es gibt sehr viel Information und sehr viel Linktipps für euch, gerade für die Webentwickler unter euch. Musik präsentiert von Podsave Music Network. Ganz ohne Musik möchte ich euch allerdings noch nicht in die Woche entlassen. Für euch gibt es jetzt noch Marcus Sures mit Eucatastrophe.

Ich wünsche viel Spaß und nächste Woche wisst ihr, geht es wieder weiter mit Technikwürze Nummer 45. Dort das zweite, der zweite Teil mit dem Interview mit Sirk Bornemann. Unbedingt reinhören. Gibt sehr viel Infos. Ich sage bis dahin.

Falling from the wings of an iron bird Closing time stands still in an awkward way No one knows what it is But they can feel it before it hits It's calling out their names that they never heard before Here it comes Crashing through the clouds The hope of despair Dropping like a bomb Heaven stretched the net Can I have its magnitude?

This unexpected savior It's a moment of death Our eyes touch the sky And we can see the shape it takes It uses dark against itself In the shattering of fate Here it comes Crashing through the clouds The hope of despair Dropping like a bomb Nothing will be the same What was dead is now coming up He's pulling it all together In a eucatastrophe Nothing will be the same What was dead is now coming up He's pulling it all together In a eucatastrophe Nothing will be the same What was dead is now coming up He's pulling it all together In a eucatastrophe Nothing will be the same What was dead is now coming up He's pulling it all together In a eucatastrophe A eucatastrophe In a eucatastrophe A eucatastrophe In a eucatastrophe