Hallo Cybaer,
Was du, lieber Browser, nicht kennst, ignorierst du halt. Aber die Welt geht nicht unter, wenn eigene oder neue Attribute oder Elemente hinzukommen, und man dann nicht mehr "valide zu W3C-DTD XYZ" ist.
Tatsächlich stellt das dann einen parse error dar. Die derzeitige Spec definiert für viele Fälle eine Möglichkeit, wie bei einem parse error weiter ein vernünftiges DOM erstellt werden kann, sagt aber auch:
The error handling for parse errors is well-defined: user agents must either
act as described below when encountering such problems, or must abort
processing at the first error that they encounter for which they do not wish to
apply the rules described below. [Parsing HTML documents]
Sprich: Man kann sich nicht zwangsläufig darauf verlassen.
Ein weiteres Problem beim tree construction Algorithmus scheint zu sein, dass in HTML 5 Serialisierung eingebettetes XML (außer MathML und demnächst vielleicht SVG) im HTML Namensraum ins DOM eingefügt wird und nicht im vom XMLNS-Attribut angegebenen Namensraum. Dies ist zum einen eine Inkonsistenz zwischen der eigentlich angestrebten Gleichheit der Möglichkeiten in beiden Serialisierungen, zum anderen ist dies eine Inkonsistenz zu den anderen Syntax-Erleichtungen (z.B. "/>") im HTML-5-Parsing-Algorithmus, wie aus mit falschem MIME-Typ versendeten XHTML-1-Dokument dennoch ein konsistentes DOM entstehen kann. Das ganze wird hin und wieder unter dem Stichwort „distributed extensibility“ heiß diskutiert.
Es kann auch sein, dass ich das Monster von Algorithmus da falsch verstehe. Es wäre schön, wenn Du das selber mal nachgucken und mich bei Gelegenheit verbessern könntest. Ich würde Dir das detaillierte Lesen des Working Drafts und der Mailing-Listen durchaus aus anderen Gründen mal ans Herz legen.
Es geht bei HTML 5 "nur" darum, die Sprache praxistauglicher zu machen (sowohl aus Sicht des Coders, als auch aus Sichht des Anwenders - man denke nur an neue Elemente wie insbes. CANVAS), nicht darum ein "neues, fehlertolerantes HTML" zu kreieren.
HTML 5 ist vieles zugleich, Praxistauglichkeit liegt oft im Auge des Betrachters und viele Parteien projizieren eigene Vorstellung auf HTML 5. Gründe für HTML 5 sind:
• Zukünftige Abwärtskompabilität: man will eine Spezifikation, die für den Großteil der Dokumente da draußen in der Wildnis ein konsistentes DOM erzeugt.
• Eine Möglichkeitkeit zur öffentlichen Spezifizierung proprietärer Erfindungen. <canvas> hätte es wohl auf dem normalen Wege von HTML 5 nicht in die Spezifikation geschafft, hätte Apple nicht vorher mit der unilateralen Veröffentlichung nicht zu ignorierende Tatsachen geschaffen.
• Harmonisierung all der kleinen, nicht in vorherigen Standards enthaltenen Bugfixes, die Browser-Hersteller als best practice erkannt haben.
• Eine zentralisierte Erweiterung des Vokabulars von HTML wobei die entscheidende Zentrale hier eine Person ist. Für ein Konzept dezentraler Erweiterung ist in der Zentrale eher kein Platz vorgesehen.
• Ein soziales Experiment, ob man mit einem benevolent dictator, einer kleinen, aber sehr lauten Gruppe von ihm Unterstützenden und dem daraus folgenden eher rauen, lauten, sozialen Klima besser eine Spezifikation schaffen kann als mit den vorherigen in IETF und W3C genutzten sozialen Mechanismen.
• Eine zentrale Anlaufstelle, in der jeder seinen Wunsch nach einem Pony erklären kann, wobei jedes Pony anders ist und manchmal auf ein Dachs oder ein Elefant gewünscht wird.
Tim