nicht angemeldet
Hallo,
Inwiefern wird denn in XML Fehlerverhalten definiert? Doch wahrscheinlich nur soweit, dass bei einem Parserfehler jegliche Weiterverabeitung des Dokuments abgebrochen wird, oder? Steht da mehr dahinter. An sich möchte ich Fehlerbehandlungsdefinitionen nicht verteufeln, aber wenn man Seitenautoren einen "Freifahrtsschein" für schlechtes HTML gibt, finde ich das unsauber.
Nagle mich nicht fest, ich arbeite relativ wenig mit XML. In einfachen Worten stimmt es aber wirklich, dass XML in der Abteilung Fehlerbehandlung nur sagt: Wenn Fehler, dann Abbruch.
Ich hab mir noch nie viele Gedanken darüber gemacht, aber ich bin mir nicht sicher, ob dieses Vorgehen wirklich so sinnvoll ist. Im echten Leben gibts wohl für beide Varianten (Fehler=Abbruch und Fehlerkorrektur) viele Beispiele die funktionieren.
So habe ich das noch gar nicht gesehen. Nun frage ich mich aber doch, wie groß der Unterschied in der Komplexität zwischen einem XML- und HTML5-Parser ist.
Ich habe schon öfter gehört, dass der Unterschied nicht sehr groß sein soll. Zugegeben, teilweise von HTML5-Befürwortern. Ich kann das selbst nicht nachweisen. Da müsstest du jemanden Fragen, der bereits einen XML- und einen HTML5-Parser geschrieben hat.
Zudem ist mir nicht klar, ob man mit HTML5 den Weg zum semantischen Web beschreiten kann, nachdem die Abwärtskompatibilität dazu zwingt, einige kontraproduktive Elemente beizubehalten.
Der Begriff des semantischen Web ist ja recht Weit gefasst. HTML5 unterstützt aber von Haus aus z.B. auch ARIA.
Es ist auch durchaus diskutabel, dass Elemente wie b, i und andere weiterhin erlaubt sein werden. Zwar wurde diesen Elementen eine neue Bedeutung zugewiesen, die ist aber durchaus recht schwammig.
Das sehe ich nun wieder als Vorteil, denn erstens wurden einige Elemente des alten Standards noch von kaum einem Browser unterstützt und zweitens sind ohne diese sonderbare SGML-Syntax der Code-Standard einfacher zu verstehen. XML wäre eben noch "strukturierter". Zur Not, kann man ja auch XHTML5 schreiben, wobei davon eher abgeraten wird (warum eigentlich?).
Das siehst du ganz richtig, viele SGML-Artefakte sind durch die neue Definition in HTML5 nicht mehr möglich. Daher gibts hier weniger unterschiede zwischen den Browsern, von denen manche das eine und andere anderes teilweise utnerstützt haben.
Mir ist nicht bekannt, dass von XHTML5 abgeraten wird.
Es gibt aber z.B. keine DTD und vor allem kein Prüfschema für XHTML5, so dass XHTML5 weniger streng auf Fehler geprüft werden kann als HTML5.
(Hinweis: Die momentan verfügbaren HTML5-Validatoren prüfen nicht so streng, wie es laut Spec möglich wäre).
Nur um das kurz zurechtzurücken, mir geht es in erster Linie darum, wie "zukunftssichere" Technik wohl am besten ausgesehen hätte, weniger darum, wie realistische und abwärtskompatible Technik aussieht.
Die Frage ist doch am besten beantwortet, wenn man sie die Browser anschau, nicht? Wie viele XForms-Implementierungen gibt es? Ich kenne nur ein Firefox-AddOn. Wie viele Browser haben HTML5-Formularelemente implementiert? Entwicklerversionen eingeschlossen: alle.
Ich denke dass XML und HTML5 sich die Wage halten, was Vorwärtskompatibilität angeht. "Dank" des HTML5-Parsers können neue Elemente und Attribtue nun leichter eingeführt werden, als das vorher der Fall war (das war in XML z.B. nie ein Problem).
Du bringst ziemlich viel Durcheinander. [...]
Nein, tue ich nicht. Nur ist es im allgemeinen Sprachgebrauch so, auch für die zur "gleichen Zeit" mit HTML5 eingeführten Neuerungen (Canvas, WebGL, Workers, CSS3 etc.) auch unter den Oberbegriff HTML5 zu stellen, und so hatte ich vor ihn zu gebrauchen.
Der allgemeine Sprachgebrauch weicht öfter von den tatsächlichen Begrifflichkeiten ab. Ich will nicht verleugnen, dass es bei HTML5 besonders schwierig ist, sich durchzuwühlen. Das ändert aber nichts daran, dass z.B. WebGL nichts mit HTML5 zu tun hat, außer, dass es Schnittstellen nutzt, die von HTML5 definiert werden.
Beispielsweise Mozillas neues Firefox OS (für das ich mich im Übrigens sehr interessiere, jedoch mir nicht vorstellen kann, dass das auf einem Smartphone effizient läuft) "basiert ja auf HTML5", obwohl die komplette Logik in JavaScript geschrieben werden muss. Sollte ich mich falsch ausgedrückt haben, bitte ich das zu entschuldigen!
Das FOS ist im Grunde auch nur ein Browser. Ob Gecko auf Smartphones jetzt besser funktioniert als Android oder iOS, sofern man das Vergleichen kann bleibt abzuwarten.
Im Grunde ist aber der einzige Unterschied, dass FOS-Apps auf HTML oder XML in Verbindung mit JavaScript und CSS fuktionieren (im Grunde also nicht anderes sind als Webseiten) während iOS-Apps Schnittstellen zur Verfügung stehen, die von einem Mini-Mac-OS angeboten werden.
Gruß, Daniel