Verarbeitung von HTML: Strenge oder Fehlertoleranz?
Mathias Schäfer (molily)
0 0 0 0 0 0 0 0 Mathias Schäfer (molily)
0 0 0
Verarbeitung von HTML: Strenge oder Fehlertoleranz?
Mathias Schäfer (molily)
Der Trend geht weg von strengen XML-Formaten. Gleichzeitig enthalten HTML-Dokumente immer mehr strukturierte Informationen. Was bedeutet das für Webentwickler?
Eine leicht technisch angehauchte Antwort und Ergänzung zu Tims Essay Bewegung im W3C.
Die Aufregung ist perfekt: Tim Berners-Lee gibt zu, dass die XML-Revolution gescheitert ist, und Kommentatoren erklären XHTML damit für mausetot, andere verteidigen das Konzept von XHTML und betonen dessen Segnungen.
Als jemand, der die Vorteile von XHTML und »the fruits of well-formed systems« für Webentwickler zu schätzen gelernt hat, kann ich – wenn auch mit vielen Einschränkungen – eher an die letztgenannte Argumentation anknüpfen und möchte inbesondere den Aspekt der maschinellen Verarbeitung weiter ausführen. XHTML ist eine Tür zur »Plattform« XML – ein etabliertes Framework mit breit unterstützten Schnittstellen und zahlreichen Tools. Dass diese Sphäre für die normalsterblichen Webautoren und -entwickler bisher unzugänglich blieb, stimmt absolut. Doch es ist noch zu früh, die Gegenbewegung auszurufen: Anfänger sollten meines Erachtens auch weiterhin XHTML lernen und möglichst wohlgeformten und validen Code schreiben.
Eine Entwicklung der letzten Jahre ist klar – Semantisches HTML gewinnt. Nachdem die Präsentation ausgelagert wurde, wendete sich der Fokus auf die sinnvolle und aussagekräftige Textauszeichnung. Es werden durch die Struktur immer mehr Informationen im Code untergebracht. Mit Metadaten, Mikroformaten und RDFa geht HTML den nächsten logischen Schritt in Richtung bedeutungsvolles Datenformat.
Es ist derzeit nicht trivial, diese Fülle an Daten maschinell auszuwerten und zugänglich zu machen, denn die wenigsten Dokumente halten sich an grundlegende syntaktische Regeln der Sprache. Jegliche Software, die HTML-Code verarbeitet, muss daher ultraliberal und infolgedessen ultrakomplex sein. Dieses besonders fehlertolerante Einlesen eines HTML-Dokuments zu einer DOM-Baumstruktur nennt sich »Tag-Soup-Parsing«. Ein solcher Parser sieht ein HTML-Dokument nicht als logische und geordnete Abfolge von zusammengehörigen Tags, Zeichendaten usw., sondern als möglicherweise wirre »Suppe« dieser Einheiten. Fast alle Web-Browser arbeiten standardmäßig so.
XHTML sollte als XML-Anwendung diese technischen Probleme ein für alle Mal lösen. Ein XML-Parser erwartet Wohlgeformtheit von einem Dokument, ansonsten bricht er das Parsen sofort und ohne Versuch einer Rettung ab. Wer XHTML also für gescheitert ansieht, weil dessen Entwickler den Faktor Mensch ignoriert haben, übersieht, dass XHTML als Lösung für ein technisches Problem gedacht war, das nach wie vor akut bleibt.
Mikroformate sind ein gutes Beispiel: Auch wenn sie ständig als Aufsatz auf XHTML und XML dargestellt werden, sind sie faktisch ein Aufsatz auf HTML, das als Tag-Soup geparst wird. Das ist gut so, denn Mikroformate sind momentan deshalb so erfolgreich, weil die tatsächlichen Anwendungen vollkommen auf die ungemein populärere Tag-Soup ausgerichtet sind. Mikroformate stehen also ganz im Trend von HTML 5 (Pragmatismus, Abwärtskompatibilität, Fehlertoleranz, Integration statt Auslagerung) und setzen sich vom XML-Trend der strengen Verarbeitung ab. Mit HTML 5 wird »Tag-Soup« plötzlich von einem Schreckensszenario zu einem eher positiven Begriff.
Wenn XHTML also nicht die Basis von Mikroformaten ist, ergibt sich die Herausforderung, auf einfache Weise Mikroformate aus potenziell fehlerhaften HTML-Dokumenten zu extrahieren. Ich sehe das (gegenwärtig) als praktischen Nachteil von Mikroformaten – leider stieß diese Äußerung auf wenig Verständnis. Dabei hatte ich mir nur Gedanken darüber gemacht, wie ich konkret die Auszeichnungen in meinen Dokumenten wieder extrahieren und weiterverwenden kann. Da scheint mir noch eine Lücke zu klaffen, für die Praxislösungen entwickelt werden müssen.
Auch wenn die traditionellen Techniken des »Semantic Webs«, z.B. RDF mit Vokabularen wie Dublin Core und FOAF, mittlerweile zu Gunsten von Mikroformaten als »uncool« und wirklichkeitsfremd abgetan werden, haben sie einen Vorteil: Ihre automatisierte Erzeugung und Verarbeitung ist recht einfach, da es sich um von HTML klar getrennte, zwangsweise wohlgeformte XML-Formate handelt – selbst wenn das sicher ein Grund ist, warum sie sich nicht durchsetzen konnten. Es gibt Standardbibliotheken, mit denen sich die gewünschten Informationen leicht abfragen lassen.
Mikroformate und sonstige bedeutungsvolle Strukturen in HTML-Dokumenten können nur sinnvoll über die DOM-Schnittstelle extrahiert werden. Gegenwärtig gibt es aber keine Standardlösungen, Tag-Soup einfach zu parsen. Auch wenn HTML 5 momentan die Syntax von HTML jenseits von XML neu definiert und auch die Parser-Logik spezifiziert, stehen solche Parser noch nicht in der Webentwicklung zur Verfügung. Es gibt zwar diverse spezielle Tag-Soup-Parser, aber ihre Einsatzfähigkeit steht in keinem Vergleich zu den üblichen XML-Bibliotheken. Auch wenn z.B. libxml2 über einen Tag-Soup-Parsingmodus verfügt, arbeitet dieser momentan noch genauso willkürlich wie jeder andere fehlertolerante Parser z.B. im Browser.
Was heißt das nun? Ian Hickson hat mit seinen Untersuchungen zum Tag-Soup-Parsing der verbreiteten Browser gezeigt, wie absurd die jetzige, nicht regulierte Praxis ist. Ob XHTML (Strenge) oder HTML 5 (Toleranz), ohne genaue Parsing-Regeln geht es nicht. Gerade die wild gewachsene Fehlertoleranz der verbreiteten Parser bedarf einer Spezifizierung und Vereinheitlichung. Erst wenn diese gerade entstehende Theorie wieder in der Praxis angekommen ist, lassen sich schmerzfrei Anwendungen entwickeln.
Tomas Caspers kommentiert:
Das Web ist aber gerade erst durch diese Fehlertoleranz zu dem Massenmedium geworden, in dem jeder mit minimalen Vorkenntnissen seine Meinung kundtun kann. … Um für die Zukunft gerüstet zu sein brauchen wir also keine noch strikteren Regeln, sondern eindeutige Regeln zur Fehlertoleranz, an die sich die maßgeblichen Browserhersteller halten können.
Die Forderung von Websurfern und Webautoren nach einem fehlertoleranten System, das jeden teilhaben lässt, spiegelt nur einen Teil des Webs wieder. Aus der Sicht von Programmierern sind angereicherte HTML-Dokumente momentan noch der Horror. Im Web-2.0-Kontext haben Web Services, Mashups und Syndication schon längst gezeigt, dass es nicht ohne definierte, teilweise sehr strenge Formate geht. Auch die Mikroformate-Community, die sich derzeit vornehmlich auf die Auszeichnung mit Mikroformaten stürzt, wird sich mit dieser Frage beschäftigen müssen, sobald kleine und große Web-Dienste und schließlich jeder Entwickler von diesem Mehrwert Gebrauch machen wollen. Die Nützlichkeit des neuen Semantischen Webs wird von der Klärung dieser Grundfrage abhängen.
-
Gerade die wild gewachsene Fehlertoleranz der verbreiteten Parser bedarf einer Spezifizierung und Vereinheitlichung.<p />
Schon damals, vor einigen Monaten, als Ian sich über
standardisierung der Fehlerberichtigung
Gedanken machte habe ich nicht verstanden wie das in der Praxis funktionieren sollte.Eine Spezifikation engt die Auswahl an Fällen meiner Erfahrung nach ein, die man beachten und abarbeiten muss. Warum sollte ein Browserhersteller Fälle, in denen er früher erfolgreich die Fehler der Webautoren ausmärzen konnte, weglassen und somit genau diese Seiten unbrauchbar machen, nur um sich der Spezifikation der Fehlertoleranz zu unterwerfen?
Machte in der Vergangenheit nicht gerade die hoche Fehlertoleranz den IE so beliebt? Wenn man jetzt die Anzahl der Fälle beschneidet, dann kann man doch gleich wohlgeformtes XML verlangen, warum auf halber Stecke aufhören und trotzdem viele Seiten kaputt machen?
-
Anfänger sollten meines Erachtens auch weiterhin XHTML lernen und möglichst wohlgeformten und validen Code schreiben.
Und trotzdem werden die Browser immer mit fehlerhaftem Markup zu kämpfen haben. Die Theorien hinterstandardisierung der Fehlerberichtigung
kenne ich (noch) nicht - aber ich denke das ist nichts weiter als eine Symptombekämpfung. Das Problem ist, dass es kein Problem ist, fehlerhaftes Markup zu schreiben. Vor allem, wenn man nicht die Kapazitäten hat, eine Seite in verschiedenen Browsern zu testen, gibt man sich schnell zufrieden, wenn die Seite im wichtigsten Browser so angezeigt wird, wie erwartet. Warum integrieren die Browserhersteller nicht einen Validator à la iCab oder Tidy an prominenter Stelle im Browser? Ich glaube das würde das Ego jedes Autoren - vom Anfänger bis zum Profi - fordern, valides Markup zu schreiben. -
Die grundlegende Idee hinter XML, durch drakonische Fehlerbehandlung Parser klein und einfach zu halten, ist verdammt gut. Allerdings ist die Idee, diese Fehlerbehandlung auf eine riesige Menge von Dokumenten und Anwendern, die sich bisher nicht darum gekümmert haben und darum dazu inkompatibel sind, schlecht.
Der Gedanke hinter HTML5, Tag-Soup-Parsing genau zu spezifizieren, ist wohl der beste Weg für dieses Problem (nicht für neue Formate, da ist XML voll und ganz richtig). Es hält den Parser auf einer vertretbaren Größe und macht ihn zuverlässig, bleibt aber trotzdem halbwegs kompatibel zu dem, was in der echten Welt geschieht.
-
Die Forderung nach einem fehlertoleranten System, das jeden teilhaben lässt, spiegelt nur einen Teil des Webs wieder.
Brauchen wir eine solche Definition von Fehlertoleranz eigentlich noch? Das heutige Web schließt doch niemanden mehr aus, nur weil er kein HTML kann oder es auch gar nicht erlernen möchte - an jeder Ecke stehen Tools zur Verfügung, um eigene Inhalte, seien das Blogeinträge, Videos/Musik, Bilder etc. im www zur Verfügung zu stellen, ohne sich mit der Technik dahinter weiter beschäftigen zu müssen, als wie der Klick auf den Submit-Button eines (Upload-)Formulars funktioniert.
Aus der Sicht von Programmierern sind angereicherte HTML-Dokumente momentan noch der Horror.
Gerade die automatisierte (Weiter-)Verarbeitung von Inhalten gewinnt immer mehr an Bedeutung, du hast Mash-Ups und Syndication ja bereits erwähnt. Austauschbarkeit von Inhalten mit anderen Anbietern wird immer wichtiger - und die erfordert klar definierte und eingehaltene Schnittstellen, sonst wird aus der Fülle an "User generated Content" schnell unbrauchbarer Datenbrei.
Selbst bei so vergleichsweise simplen Dingen wie Trackback-Funktionen in Weblogs stösst man jeden Tag auf Einträge, in denen es die Sonderzeichen verbeutelt hat - und da geht's noch um einen eher trivialen Punkt des Datenaustausches, nämlich den der Kodierung; und es ist auch größtenteils plain text, der da ausgetauscht wird.
Vielleicht sollte man, wenn Browser schon nach wie vor aufwendige Tag Soup Parser enthalten sollen, diese nicht nur als Input-Handler, sondern auch als Output-Quellen definieren. Gib deine Suppe rein - und erhalte die Möglichkeit, diese als nach standardisierten Regeln von den Fehlern befreites Dokument wieder ausgegeben zu bekommen, so dass du dieses dann weiterverwenden kannst ...
-
Hallo,
ich halte einen Trend hin zu XML sinnvoller als wieder eine stärkere Besinnung auf HTML. XML ist einfacher zu verarbeiten und flexibler zu erweitern.
Intern kann man ja auch problemlos mit XML arbeiten. Nach außen hin liefert man es dann halt als HTML aus oder wenn der Browser mit dem Accept-HTTP-Header sagt, dass er application/xml, application/xhtml+xml und ähnliches unterstützt als XML.
Man kann das auch noch etwas weiter treiben, in dem man HTML, XHTML+CSS nur als Ausgabedateiformat betrachtet wie PDF oder das Dateiformat einer Textverarbeitung. Dann wird kann intern jeweils ganz was anderes, jeweils passendes verwendet werden und nach außen hin wird es als standardkonformes HTML/XHTML/... exportiert. Eine Variante mit der man z.B. heute schon problemlos intern [li href="menu.html"] schreiben kann, was dann zu einem passenden [li][a href=menu.html"]... nach außen konvertiert wird, bis sich die Browser mit einer Kennung melden, dass sie jenes unterstützen und die Konvertierung entfallen kann.
tschuess [|8:)
-
Genau darauf basiert das Web, auf dem Quirks Mode der Browser. Ohne den wird sich die Anzahl der Webseiten mindestens halbieren, weil einfach niemand die Zeit hat, sein Dokument zu validieren, damit es korrekt angezeigt wird. XHTML kostet sehr viel Zeit, denn ich muss mir merken, WELCHES Element in WELCHEM Element stehen darf und WELCHE Attribute es haben darf. Allein das kann für ein 25 KB großes Dokument Stunden dauern. Und was passiert, wenn ich Benutzergenerierten Code einfüge, der nicht XHTML passabel ist? Das XHTML-Regelwerk ist reine Bürokratie, das auf der Vormachtstellung des W3C beruht. Welchen Prozentsatz meiner User interessiert es ob ich XHTML oder HTML 3.2 benutze. Das sind vielleicht 5%, die akribisch auf solche Details schauen.
Vom anderen Aspekt aus betrachtet - was Maschinenlesbarkeit von Dokumenten angeht - sie sind doch Maschinen lesbar, jeder Browser Zeit zeigt fast jede Webseite auch mit kleinen Codefehlern korrekt an, denn dafür sind Browser da. Je größer die Verbreitung von einem Format, desto toleranter muss es gegenüber Abweichungen sein. Analog gilt das auch für die Rechtschreibung. Ich kennne kein Forum, in dem Einträge wegen eines orthografischen Fehlers gelöscht werden. XHTML wird sich nicht durchsetzen, genauso wenig wie sich Anzüge als Alltagskleidung und korrektes Deutsch als Alltagssprache durchsetzt.
XHTML schränkt also auch Kreativität ein - zumindest was die Elementverschachtelungen angeht.
-
Interessant wird es weiterhin bei Implementierungen bleiben:
- Welche Standards sollen implementiert werden. Eigentlich müssen (und werden) alle (HTML 4 und 5 und x, XHTML 1 und 2, dazu mindestens noch Unterstützung für Mikroformate in Form spezieller Widgets) "irgendwie mitgenommen" werden. - Selbst wenn das trivial wäre:
- "Fehlertoleranz" ist aufwendiger zu implementieren und wird zeitgleich zu mehr Inkonsistenzen unter den Engines führen.
-
du scheinst du meinen Punkt nicht sonderlich zu würdigen, denn du lässt dich allgemein zu XHTML aus. Okay, war hier aber nicht Thema. ;)
… sie sind doch Maschinen lesbar, jeder Browser … zeigt fast jede Webseite auch mit kleinen Codefehlern korrekt an
Es ging mir nicht darum, ob der Browser ein minimal fehlerhaftes Dokument trotzdem korrekt anzeigt. Unter dem Gesichtspunkt kann man XHTML bewerten, wie man will - das ist mir in diesem Kontext gleich.
Es geht darum, dass der Trend dazu geht, immer mehr Semantik in HTML-Dokumenten unterzubringen, und dass dieser Entwicklung keine Weiterentwicklung auf der Parserseite entgegensteht (außerhalb von Browsern). Schreibe mir mal z.B. in PHP einen Parser für hCard und hCalendar, sodass ich die Microformate in meinen Sites selbst weiterverwenden kann - das geht über das DOM recht schnell. Aber von Tag-Soup zum DOM kommt man momentan (außerhalb von Browsern) nicht so einfach. Von XML zu DOM allerdings in einem Katzensprung. Das war meine Aussage.
Im Übrigen scheint mir deine XHTML-Kritik – Verzeihung – eher uninformiert:
XHTML kostet sehr viel Zeit, denn ich muss mir merken, WELCHES Element in WELCHEM Element stehen darf und WELCHE Attribute es haben darf.
Das halte ich für Unsinn, das ist keine Eigenheit von XHTML. XHTML verlangt im Vergleich zu HTML lediglich zwingend Wohlgeformtheit. Nicht-valides XHTML kannst jedoch du genauso schreiben wie nicht-valides HTML. Das hat dieselben Auswirkungen. Egal, ob man HTML oder XHTML verwendet, muss man natürlich die Elemente und deren korrekte Verschachtelung kennen. Ansonsten kommt, z.B. durch widersinnige Verschachtelung, ein unsinniger DOM-Baum raus. Das zeigt sich dann spätestens bei CSS und JavaScript/DOM.
Und was passiert, wenn ich Benutzergenerierten Code einfüge, der nicht XHTML passabel ist?
Kommt darauf an, was man beabsichtigt. Wenn Benutzer strukturierte Daten eingeben sollen, ist Korrektheit wichtig. Ansonsten ist es eigentlich egal, was Benutzer eingeben, denn umformen und korrigieren kann und muss man es gegebenenfalls sowieso. Und (X)HTML lässt man den Anwender sowieso in den seltensten Fällen direkt eingeben.
Noch einmal, XHTML und HTML unterscheiden sich in diesen Punkten nicht, daher verstehe ich deine Angriffe auf XHTML nicht. Allgemein scheinst du eher gegen die Regeln von HTML und XHTML an sich zu polemisieren.
-
Ist schon richtig: Mangelnde Fehlertoleranz ist ein Grund dafür, dass sich wohlgeformtes XHTML bisher kaum durchgesetzt hat. Welche Fehlertoleranz in HTML zugelassen wird, lag bisher im Ermessen des Browserherstellers. Dass dafür neue Regeln aufgestellt werden müssen, halte ich nicht für nötig. Den Ansatz, in jedem Browser von vorn herein einen Validator einzubauen, sehe ich da schon eher für praktikabel. Dann aber bitte mit einer deutlich sichbaren Anzeige, dass Fehler im Dokument sind!
Und für XHTML sollte es auch weiterhin möglich sein, es als text/html-Tagsoup auszuliefern. Das text/html bei XHTML 1.1 und XHTML 2 nicht erlaubt ist, ist schlicht Unsinn. Wer jedoch in Zukunft XML-Formate wie RDF oder SVG in XHTML einbetten will, muss zur Wohlgeformtheit verdonnert werden. Die Autoren socher Dokumente erwarten auch nichts Anderes.
Eine neue HTML-Version, mit den ganzen SGML-Ausnahmeregeln, braucht kein Mensch. Wir brauchen aber ausreichend Toleranzen für Einsteiger und Wochenendautoren. Warum soll das nicht auf Basis von XHTML-Regeln möglich sein?
-
Also für mich war der Umstieg auf XHTML sofort aus, als ich lesen musste, dass MS IE6 solche Dokumente wegen vorangestelltem XML-Header in den quirks-mode schaltet, statt strict mode, weil er das nicht versteht, und weil er auch den MIME Typ für XHTML nicht versteht und das alles ein riesiges Chaos ist.
So einfach war das, und allein darin liegt wohl ein sehr wichtiger Grund für das Scheitern, nicht, weil Leute XHTML an sich nicht nutzen wollen.
Siehe auch
http://www.w3.org/People/mimasa/test/xhtml/media-types/MSIE6.0SP2
und
http://en.wikipedia.org/wiki/Criticisms_of_Internet_Explorer#XHTML
(Sub-Überschrift "2.2 XHTML") -
Hallo Mathias,
richtig, ich habe zum The XHTML im selfhtml blog etwas polemisch meine meinung gesagt und die Vorteile der Strenge vernachlässigt. Richtig ist, dass klare Wegwesungen wichtig sind, um das Format nicht zu verwässern. Meine Ambition war es auch ganz bewusst mal die NACHteile (wenn sie wirklich überwiegen) ganz klar zu zeigen, denn bislang musste sich niemand großartig um Konformheit kümmern. Ich hab mir die ganze Diskussion nochmal durch den Kopf gehen lassen und mittlerweile auch einige XHTML konforme Seiten "produziert" und bin zum Ergebnis gekommen: Bei komplexen Webseiten, die es sich zum Ziel setzen, einem hohen Standrd zu genügen, kommt man um XHTML nicht rum, denn man macht sich automatisch mehr Gedanken um eine klare Strukturierung, denn der Browser hilft zeigt fehler im Dokument sofort an, was ich beim normalen HTML ab und an vermisst habe. Danke für deine Antwort,
Grüße aus Ulm,
Andi