nicht angemeldet
Ist HTML 5 gut oder schlecht?
suitHallo,
in letzter Zeit habe ich mir immer mal wieder Gedanken über HTML 5 und die dazugehörigen "Technologien" (JavaScript und CSS) gemacht. In der heutigen Zeit bedeutet Internet und World Wide Web mehr als nur statische Seiten und Bilder auszuliefern, es werden komplette Endbenutzeranwendungen im Browser umgesetzt. Dem möchte HTML 5 gerecht werden, allerdings empfinde ich, dass das auf Kosten einer sauberen Architektur basiert.
Zu diesem Schluss komme ich, da HTML 5 im neuen Standard festschreiben möchte, wie Fehler richtig zu behandeln und zu beheben sind. Nur stellt sich mir dabei die Frage, warum eine Fehlerbehandlung spezifiziert wird, wenn man sie durch fehlerfreies Schreiben umgehen könnte. Diesen Ansatz fand ich bei XHTML auf Basis von XML (natürlich per "Content-Type: application/xhtml+xml" oder vergleichbarem ausgeliefert) sehr schön, da der Parser fest vorgegebene Regeln hat. Wenn nun ein Dokument diese nicht einhält, ist es automatisch ungültig, also wird jeder, der XHTML schreiben möchte, wird dadurch wenigstens einmal syntaktisch korrektes HTML liefern. Es ist zwar durchaus verständlich, dass man die Eintrittshürde für Publizierende im Internet möglichst gering halten will, nur stelle ich mir auch die Frage, warum diese Leute dann selbst HTML schreiben wollten. Dabei gibt es doch so viele schöne vorgefertigte Programme (CMS) und Rich-Text-Editoren, die mehr oder weniger gut eine Möglichkeit zur Publikation von Inhalten im Internet ermöglichen. Alles, was darüber hinausgeht, bedarf doch dann vermutlich sowieso mehr Einarbeitung in das Thema, sodass man auch davon ausgehen könnte, dass dann auch valider Code geschrieben werden könnte.
HTML 5 versucht außerdem abwärtskompatibel zu sein, was einerseits auch wieder verständlich ist, da ja Benutzer älterer Browser wenigstens noch das sehen können möchten, was nicht erst durch neue Features eingeführt wurde, aber andererseits damit auf einer Basis steht, die nicht mehr zeitgemäß ist (erinnert beinahe etwas an den Zwang der Abwärtskompatibilität bei x86-Prozessoren, aber auch das möchte ich nicht schlecht reden!). Einige der Schritte in XHTML 2 hatten mir da besser gefallen. Da war die Tag-Basis sauberer (wenn man auch hätte weiter gehen können), wobei mir die neuen Multimediafunktionalitäten gefehlt hätten. Aber vielleicht wären diese noch in den Standard gekommen. Nach 20 Jahren vielleicht…
Zur "Technologie" HTML 5 gehört ja auch noch JavaScript, was wiederum seine Macken hat. Es heißt so schön, dass Java-Programmierer ohne Einarbeitung kaum gutes JavaScript schreiben können, da es ja auf ganz anderen Gerüsten basiert (ich muss zugeben, dass ich das Funktions- und Objektmodell von JavaScript noch nicht ganz durchblickt habe). Dann stelle ich mir aber auch hier die Frage, wie komplette Anfänger damit sauberen Code schreiben können sollen.
Dazu kommt noch, dass für die komplexen Internetanwedungen JavaScript wohl eine sehr langsame Sprache ist (bzw. durch die Interpretation langsam ist). Es werden zwar viele erfolgreiche Bemühungen getroffen, sie zu beschleunigen, aber wenn ich da an Smartphones denke (nicht an die High-End-Geräte), könnte ich mir schon einen enormen Geschwindigkeitsunterschied zwischen HTML 5 und einem Java-Applet oder gar Flash (so nervig ich es auch selbst finde) zu Gunsten der letzten beiden vorstellen. Leider gibt es aber wohl keine leicht portable Alternative für schnellen Code (man kann ja davon ausgehen: Je portabler, desto langsamer).
Als letzten Punkt möchte ich noch ansprechen, dass Animationen in HTML 5 irgendwie nicht so wirklich "harmonieren". Ein Div-herumzuschieben (z.B. wenn man per Drag & Drop einen Artikel in einen Einkaufswagen zieht), verändert unter Umständen die Bedeutung des Divs (von "nicht auf dem Einkaufszettel" zu "auf den Einkaufzettel"), was unter Umständen nur grafisch aber nicht semantisch umgesetzt wird. Da empfinde ich die Idee, ein Canvas zu nehmen und darauf die Ausgabe zu erledigen (inklusive Animation), während im Hintergrund die Datenstruktur unanimiert angepasst wird schöner. Allerdings weiß ich hier nicht, wie das in der Realität gehandhabt wird.
Dieser Post soll eigentlich nur als Anstoss einer Diskussion dienen, denn mich interessieren die Meinungen von Profis zu diesem Thema. Auch wenn mir HTML 5 nicht gefällt, muss ich zugeben, dass es wohl das nötige Potenzial hat, der führende Standard zu werden (wenn es das nicht schon ist!), auch bei Smartphones (siehe Boot to Gecko).
Zu CSS habe ich mich nicht geäußert und auch viele weitere Aspekte habe ich noch außen vorgelassen. Vielleicht greift das ja jemand anderes auf. Falls jemand Fehler oder Unstimmigkeiten in meinen Ausführungen findet, bitte ich darum, mich auch zu belehren!
Ansonsten möchte ich noch den Administratoren danken, dass das Forum wieder läuft. Auf welchem anderen könnte man sonst so einen Diskussionsanstoss machen?
Viele Grüße,
Rachus
-
Hallo,
Nur stellt sich mir dabei die Frage, warum eine Fehlerbehandlung spezifiziert wird, wenn man sie durch fehlerfreies Schreiben umgehen könnte.
Zum einen, weil dieser Ansatz nicht funktioniert hat. XHTML hat weder auf Seiten der Autoren noch auf Seiten der Browserhersteller Anklang gefunden.
Zum anderen, weil Millarden Websites als Tag-Soup-HTML bereits existierten und jeden Tag Millionen Dokumente dazukamen. Es war notwendig, diese bestehenden Inhalte browserübergreifend einheitlich zu verarbeiten, damit die Inhalte und das damit verbundene kulturelle Erbe technisch zugänglich bleiben.
Wenn nun ein Dokument diese nicht einhält, ist es automatisch ungültig, also wird jeder, der XHTML schreiben möchte, wird dadurch wenigstens einmal syntaktisch korrektes HTML liefern.
Nun, das ist historisch nicht eingetreten. Das XHTML, was zur Hochzeit von XHTML im Web publiziert wurde, war größtenteils nicht wohlgeformt, konnte also nicht einmal hypothetisch mit XML-Prozessoren geparst werden.
Dabei gibt es doch so viele schöne vorgefertigte Programme (CMS) und Rich-Text-Editoren, die mehr oder weniger gut eine Möglichkeit zur Publikation von Inhalten im Internet ermöglichen.
Authoring Tools waren lange Zeit Teil des Problems, sie erzeugten fehlerhaften Code, konnten also damals nicht Teil der Lösung sein.
Alles, was darüber hinausgeht, bedarf doch dann vermutlich sowieso mehr Einarbeitung in das Thema, sodass man auch davon ausgehen könnte, dass dann auch valider Code geschrieben werden könnte.
So einfach ist es nicht. Der Großteil der Websoftware erzeugt HTML-Code durch String-Concatenation, nicht durch einen abstrakten Objektbaum, der letztlich serialisiert wird. Wohlgeformtes XHTML zu erzeugen ist mit diesem Ansatz nicht verlässlich möglich. Websoftware erzeugte vor 10 Jahren Tag Soup und macht es heute immer noch, viele Teiles des Web-Ökosystems basieren auf diesem Prinzip.
Zur "Technologie" HTML 5 gehört ja auch noch JavaScript, was wiederum seine Macken hat. Es heißt so schön, dass Java-Programmierer ohne Einarbeitung kaum gutes JavaScript schreiben können, da es ja auf ganz anderen Gerüsten basiert (…) Dann stelle ich mir aber auch hier die Frage, wie komplette Anfänger damit sauberen Code schreiben können sollen.
JavaScript ist keine Lernsprache wie Java, dafür ist sie zu mächtig, zu dynamisch und zu funktional. Sie gibt einem keine einfache, vorgefertigte Struktur, keine rigorosen Konventionen, die man nur befolgen braucht - das ist bekannt.
Das heißt nicht, dass man nicht mit JavaScript Programmieren lernen kann, aber brauchbares clientseitiges JavaScript zu schreiben bedarf eines Haufens an Wissens.
Dazu kommt noch, dass für die komplexen Internetanwedungen JavaScript wohl eine sehr langsame Sprache ist (bzw. durch die Interpretation langsam ist).
Das ist Quatsch. JavaScript-Engines können es locker mit anderen üblichen Websprachen aufnehmen. Sicher, die JVM ist in vielerlei Hinsicht ausgereifter und überlegen, aber das liegt einfach am Konzept. Diese Vorteile erkauft man sich mit Nachteilen, die man bei dynamischen, interpretierten Sprache nicht hat. Doch die Programmiersprache selbst ist bei Webprogrammierung selten das Bottleneck, sondern Datenbankzugriff und Datenverarbeitung, Parallelisierung, Skalierung.
Es werden zwar viele erfolgreiche Bemühungen getroffen, sie zu beschleunigen, aber wenn ich da an Smartphones denke (nicht an die High-End-Geräte), könnte ich mir schon einen enormen Geschwindigkeitsunterschied zwischen HTML 5 und einem Java-Applet oder gar Flash (so nervig ich es auch selbst finde) zu Gunsten der letzten beiden vorstellen.
Flash für Mobilgeräte ist tot, weil es sich um eine proprietäre VM und Standardbibliothek handelt, die Adobe nicht rechtzeitig optimiert hat. Die JavaScript-Engines und die HTML5-APIs sind währenddessen abgehoben und haben Flash überholt - z.B. durch bessere Hardwareunterstützung. Vielleicht hast du es nicht mitbekommen, aber selbst Adobe hat Flash für Mobilgeräte aufgegeben. Und Java-Applets hat es auf Mobilgeräten nie gegeben. Es gibt höchstens die JVM von Android (Dalvik), auf der laufen aber die nativen Android-Apps.
Leider gibt es aber wohl keine leicht portable Alternative für schnellen Code (man kann ja davon ausgehen: Je portabler, desto langsamer).
JavaScript ist *die* ubiquitäre Sprache, die gleichzeitig schnell und portabel ist. In den letzten Jahren wurde von den größten IT-Unternehmen soviele Ressourcen in die Entwicklung von JavaScript-Interpretern wie in keine andere Websprache. Dadurch haben wir heutzutage fünf hervorragende, portable JavaScript-Interpreter (JavaScriptCore, V8, Chakra, Spidermonkey, Carakan), von denen drei freie Software sind.
JavaScript als Sprache ist wie gesagt nicht das Bottleneck, wenn es um Anwendungsentwicklung geht. Entscheidend sind hier z.B. Grafikperformance, also hardwarebeschleunigtes CSS, sowie die Performance der verschiedenen HTML5-APIs. Hier ist tatsächlich noch viel zu tun, aber der Fortschritt ist enorm.
Als letzten Punkt möchte ich noch ansprechen, dass Animationen in HTML 5 irgendwie nicht so wirklich "harmonieren". Ein Div-herumzuschieben (z.B. wenn man per Drag & Drop einen Artikel in einen Einkaufswagen zieht), verändert unter Umständen die Bedeutung des Divs (von "nicht auf dem Einkaufszettel" zu "auf den Einkaufzettel"), was unter Umständen nur grafisch aber nicht semantisch umgesetzt wird.
Das DOM ist keine reine Datenstruktur, sondern eine Darstellungsweise, eine Repräsentation von Daten. Das DOM sollte daher keine komplexen Informationen enthalten. Das ist ein Architekturproblem, welches man mit gängigen Pattern wie MVC lösen sollte, welche die Darstellung und die Rohdaten und der Anwendungslogik trennen.
Jede gute JavaScript-Anwendungsbibliothek setzt ein MVC-, MVP- oder MVVM-artiges Pattern um (siehe Backbone, Ember, YUI, Dojo, ExtJS usw.). Das ist keine besondere Stärke oder Schwäche von JS/HTML5, das Problem hat man z.B. auch bei Flash (siehe Flex, PureMVC usw.)
Mathias
-
Moin molily,
Nur stellt sich mir dabei die Frage, warum eine Fehlerbehandlung spezifiziert wird, wenn man sie durch fehlerfreies Schreiben umgehen könnte.
Zum einen, weil dieser Ansatz nicht funktioniert hat. XHTML hat weder auf Seiten der Autoren noch auf Seiten der Browserhersteller Anklang gefunden.
Zum anderen, weil Millarden Websites als Tag-Soup-HTML bereits existierten und jeden Tag Millionen Dokumente dazukamen. Es war notwendig, diese bestehenden Inhalte browserübergreifend einheitlich zu verarbeiten, damit die Inhalte und das damit verbundene kulturelle Erbe technisch zugänglich bleiben.
Hinzu kommt, dass eine spezifizierte Fehlerbehandlung immer wünschenswert ist, auch wenn sie nur darin besteht „Brich jetzt ab” zu definieren. Das ist unabhängig davon, ob man nun XHTML oder HTML5 schreibt. Fehler treten auf, und man will im Fehlerfall ein spezifiziertes Verhalten haben.
Prinzipiell zu dem Thema möchte ich sagen, dass ich die Entwicklung sehr begrüße. Endlich passiert wieder etwas und es werden bestehende Probleme angegangen, nach Jahren des Quasi-Stillstands.
LG,
CK -
Vielleicht hast du es nicht mitbekommen, aber selbst Adobe hat Flash für Mobilgeräte aufgegeben.
Ja ich weiß, man soll niemanden treten der am Boden liegt:
Was ich hier nicht verstehe: obwohl Adobe angekündigt hat, dass Flash für mobile Geräte eingestellt wird (und mittlerweile bestätigt hat, dass es ab 15. August 2012 tot ist) haben die Mozilla Leute trotzdem Flash in ihren Browser eingebaut :)
-
Hallo,
nachdem hier die meisten meiner Argumente entkräftet wurden und ich HTML bereits bei meiner Antwort an Daniel.S abgegolten habe, werde ich mich mal mehr JavaScript widmen.
JavaScript ist keine Lernsprache wie Java, dafür ist sie zu mächtig, zu dynamisch und zu funktional. Sie gibt einem keine einfache, vorgefertigte Struktur, keine rigorosen Konventionen, die man nur befolgen braucht - das ist bekannt.
Macht es Sinn, in diesem Falle C++ (gefällt mir persönlich sehr) mit JavaScript zu vergleichen? Denn in C++ hat man auch die Wahl zwischen vielen Programmierparadigmen und nur wenige Beschränkungen, ist aber natürlich im Gegensatz zu JavaScript streng typisiert. Allerdings fällt es mir in JavaScript sehr viel schwerer ein Paradigma anzunehmen, da es nicht richtig funktional ist, aber auch nicht unmittelbar objektorientiert. Wobei man das evtl. auch "zu viel objektorientiert" nennen könnte, nachdem dort prinzipiell auch Klassen und Methoden Objekte zu sein scheinen (oder doch wieder Funktionen?).
Das heißt nicht, dass man nicht mit JavaScript Programmieren lernen kann, aber brauchbares clientseitiges JavaScript zu schreiben bedarf eines Haufens an Wissens.
Also kann JavaScript ohne Probleme mit Java in Konkurrenz treten (z.B. auf Smartphones, nachdem Java aus Webseiten fast komplett verdrängt wurde)?
Das ist Quatsch. JavaScript-Engines können es locker mit anderen üblichen Websprachen aufnehmen. Sicher, die JVM ist in vielerlei Hinsicht ausgereifter und überlegen, aber das liegt einfach am Konzept. Diese Vorteile erkauft man sich mit Nachteilen, die man bei dynamischen, interpretierten Sprache nicht hat. Doch die Programmiersprache selbst ist bei Webprogrammierung selten das Bottleneck, sondern Datenbankzugriff und Datenverarbeitung, Parallelisierung, Skalierung.
Okay, das ist implizit eine Antwort auf meine oben gestellte Frage. Allerdings sehe ich bei strikter Typisierung und Vorkompilierung keine Nachteile gegenüber dynamischer Typisierung und Interpretation. In meinen Augen ist es gar umgekehrt, da Fehler schneller auffallen, wenn nicht implizit eine Variable theoretisch von jedem Typ sein kann.
Besonders in der heutigen Zeit ist es zudem so, dass zunehmend ressourcenaufwändige Webanwendungen auf dem Desktop/Notebook daheim laufen. Für grafische Spielchen und dergleichen benötigt man aber in meinen Augen eben auch eine schnelle Sprache. Ist dem denn JavaScript gewachsen? Auf jeden Fall wird versucht, es darauf vorzubereiten. WebGL ist da das beste Beispiel.Vielleicht hast du es nicht mitbekommen, aber selbst Adobe hat Flash für Mobilgeräte aufgegeben.
Das ist tatsächlich an mir vorübergegangen. Was machen nun die ganzen Seiten, die komplett auf Flash aufbauen (meistens sind diese ja zu Filmen, oder auch mein Zahnarzt nutzt so eine)? Die lassen Smartphones außen vor?
JavaScript ist *die* ubiquitäre Sprache [...]
Wenn das so ist, muss ich sie jetzt nur noch meistern.
JavaScript als Sprache ist wie gesagt nicht das Bottleneck, wenn es um Anwendungsentwicklung geht. Entscheidend sind hier z.B. Grafikperformance, also hardwarebeschleunigtes CSS, sowie die Performance der verschiedenen HTML5-APIs. Hier ist tatsächlich noch viel zu tun, aber der Fortschritt ist enorm.
Dennoch möchte ich noch die Frage stellen, ob den die Schnittstellen, von der Geschwindigkeit abgesehen, die allerdings ja auch sehr wichtig ist, den Zwecken gerecht werden. Ist die DOM-API geeignet für Anwendungen, wie ich sie oben beschrieben habe? Wenn man native GUIs schreibt, ist das Vorgehen doch vermutlich nicht so, dass man bei Manipulationen durch einen DOM-Baum laufen muss, oder? Ich habe bisher immer nur manuell welche geschrieben, könnte mir aber vorstellen, dass man mit Glade oder dergleichen auch einen Baum erhält. Damit wäre mein Einwand hier wieder entkräftet.
Das DOM ist keine reine Datenstruktur, sondern eine Darstellungsweise, eine Repräsentation von Daten. Das DOM sollte daher keine komplexen Informationen enthalten. Das ist ein Architekturproblem, welches man mit gängigen Pattern wie MVC lösen sollte, welche die Darstellung und die Rohdaten und der Anwendungslogik trennen.
Ich dachte immer, Markup soll den Inhalt beschreiben und nicht die Darstellungsweise. Zumindest wird es einem von SELFHTML ja so beigebracht. Wenn man jetzt den Inhalt selbst im Hintergrund verwaltet und den DOM-Baum nur noch zur Ausgabe "missbraucht", ist das doch beinahe so ähnlich wie eine Flash-Seite. Je nach Umsetzung könnte so eine bestimmt das Modell auch sehr gut umsetzen.
Jede gute JavaScript-Anwendungsbibliothek setzt ein MVC-, MVP- oder MVVM-artiges Pattern um (siehe Backbone, Ember, YUI, Dojo, ExtJS usw.). Das ist keine besondere Stärke oder Schwäche von JS/HTML5, das Problem hat man z.B. auch bei Flash (siehe Flex, PureMVC usw.)
Hm, ich muss zugeben, dass ich mich nie mit einer JavaScript-Anwendungsbibliothek beschäftigt habe. Mir ging es immer darum, erst einmal selbst zu verstehen, was im Hintergrund passiert. Daher kam ich nie mit einer in Kontakt. Vielleicht sollte ich mich mal mit der ein oder anderen außeinandersetzen.
Jedenfalls danke für deine Antwort!
Schöne Grüße
-
Hallo,
Macht es Sinn, in diesem Falle C++ (gefällt mir persönlich sehr) mit JavaScript zu vergleichen? Denn in C++ hat man auch die Wahl zwischen vielen Programmierparadigmen und nur wenige Beschränkungen, ist aber natürlich im Gegensatz zu JavaScript streng typisiert.
In der Hinsicht ergibt der Vergleich vielleicht Sinn, ja.
Allerdings fällt es mir in JavaScript sehr viel schwerer ein Paradigma anzunehmen, da es nicht richtig funktional ist, aber auch nicht unmittelbar objektorientiert. Wobei man das evtl. auch "zu viel objektorientiert" nennen könnte, nachdem dort prinzipiell auch Klassen und Methoden Objekte zu sein scheinen (oder doch wieder Funktionen?).
Eine Übersicht habe ich mal hier zusammengestellt:
http://molily.de/js/organisation-ueberblick.htmlJavaScript ist unmittelbar objektorientiert, allerdings nicht klassenbasiert. Alles ist entweder ein Objekt oder verhält sich wie eins, es gibt Funktionen/Konstruktoren und Prototypen.
Das heißt nicht, dass man nicht mit JavaScript Programmieren lernen kann, aber brauchbares clientseitiges JavaScript zu schreiben bedarf eines Haufens an Wissens.
Also kann JavaScript ohne Probleme mit Java in Konkurrenz treten (z.B. auf Smartphones, nachdem Java aus Webseiten fast komplett verdrängt wurde)?
JavaScript tritt nicht generell in Konkurrenz mit Java und hat es auch nicht vor. An ECMAScript werden verschiedene Änderungen vorgenommen, die »programming in the large« erlauben, aber das sind höchstens konzeptionelle Angleichungen.
Java spielte im öffentlichen Web nie eine große Rolle. Java-Applets sind seit Jahren verschwunden, von obskuren Intranets mal abgesehen. Wie gesagt gibt es mit Android eine Mobilplattform, für die man native Apps üblicherweise in Java entwickelt. Es ist tatsächlich so, dass es einen Widerstreit zwischen plattformübergreifenden Web-Apps for Mobilgeräte und nativen Apps gibt. Viele fragen sich, ob sie lieber mobiltaugliche Web-Apps oder verschiedene native Apps entwickeln. Für aufwändigere Dinge sind native oder hybride Apps immer noch die beste (und weitaus teurere) Wahl.
Allerdings sehe ich bei strikter Typisierung und Vorkompilierung keine Nachteile gegenüber dynamischer Typisierung und Interpretation. In meinen Augen ist es gar umgekehrt, da Fehler schneller auffallen, wenn nicht implizit eine Variable theoretisch von jedem Typ sein kann.
Das sind die bekannten Kompromisse, die man bei kompilierten bzw. interpretierten Sprachen eingeht, ja.
Besonders in der heutigen Zeit ist es zudem so, dass zunehmend ressourcenaufwändige Webanwendungen auf dem Desktop/Notebook daheim laufen. Für grafische Spielchen und dergleichen benötigt man aber in meinen Augen eben auch eine schnelle Sprache. Ist dem denn JavaScript gewachsen?
JavaScript-Engines sind in manchen Benchmarks nur zehnmal langsamer als C. Das reicht für das, was die üblichen Anwendungen tun, bei weitem aus. Das zeigen auch Projekte wie Emscripten. Für High-Performance-Spiele sind interpretierte Sprachen natürlich wenig attraktiv, für mittelgroße Spiele wird das Web als Plattform aber zunehmend attraktiver.
Anwendungen fressen üblicherweise nicht Ressourcen im Sinne von reiner CPU-Rechenpower. Sie brauchen Grafikressourcen (hardwarebeschleunigtes CSS, Canvas, WebGL), Asynchronität und Nebenläufigkeit (setImmediate, requestAnimationFrame, Web Workers), schnelle Netzwerkprotokolle (Websockets, Server-sent events, XHR2/CORS, SPDY), clientseitige Datenbanken (indexedDB, Offline-Storage) und so weiter. An diesen APIs wird im Zuge von HTML5 gearbeitet.
Was machen nun die ganzen Seiten, die komplett auf Flash aufbauen (meistens sind diese ja zu Filmen, oder auch mein Zahnarzt nutzt so eine)? Die lassen Smartphones außen vor?
Ja, schon immer. Es gab zwar einige Flash-Releases für Android, aber wirklich benutzen ließen sich große Flash-Sites damit nicht. HTML5 ist in aller Munde ist, weil wir im Post-PC-Zeitalter leben. Für Smartphones, Tablets und manche Netbooks gibt es kein nutzbares Flash.
Dennoch möchte ich noch die Frage stellen, ob den die Schnittstellen, von der Geschwindigkeit abgesehen, die allerdings ja auch sehr wichtig ist, den Zwecken gerecht werden. Ist die DOM-API geeignet für Anwendungen, wie ich sie oben beschrieben habe? Wenn man native GUIs schreibt, ist das Vorgehen doch vermutlich nicht so, dass man bei Manipulationen durch einen DOM-Baum laufen muss, oder?
Das HTML-DOM für Anwendungen zu verwenden ist natürlich ursprünglich ein Hack, denn HTML beschreibt Hypertext-Dokumente, nicht GUIs. Erst mit HTML5 sind ein paar entsprechende native Controls hinzugekommen.
Bei nativen GUI-Toolkits operiert man nicht direkt auf einem DOM-Baum, aber intern haben die auch nur einen Objektbaum aus wiederverwendbaren Controls, die letztlich aus primitiven Zeichenobjekten bestehen. Im Vergleich zum DOM ist nur der Abstraktionsgrad höher. Ansonsten arbeitet z.B. Flex oder Qt durchaus mit einem DOM-ähnlichen Objektmodell.
Für HTML gibt es z.B. mit den Web Components und dem Shadow DOM Erweiterungen, die auf eine höhere Abstraktion abzielen. Außerdem gibt es wie gesagt GUI-Toolkits für JavaScript. ExtJS, YUI, Ember und Co. sorgen dafür, dass man auf Anwendungsebene nicht mehr direkt mit dem DOM zu tun hat, sondern nur mit Views bzw. UI-Komponenten und Widgets.
Ich habe bisher immer nur manuell welche geschrieben, könnte mir aber vorstellen, dass man mit Glade oder dergleichen auch einen Baum erhält. Damit wäre mein Einwand hier wieder entkräftet.
Soweit ich weiß, erzeugen Qt Designer, Glade und Flex (MXML) XML-Dokumenten, aus denen dann ein Objektbaum erstellt wird.
Ich dachte immer, Markup soll den Inhalt beschreiben und nicht die Darstellungsweise.
Ja, siehe oben, das ist die ursprüngliche Aufgabe: Hypertexte zu strukturieren und auszuzeichnen. Webanwendungen gehen natürlich weit darüber hinaus. Wie gesagt gibt es verschiedene Bestrebungen, diesen Paradigmenwechsel auch technisch eine Form zu geben. HTML5 als Spezifikation von »web applications« ist ein Ansatz, zusätzlich gibt es etwa WAI-ARIA, wodurch HTML-Elemente zum Zweck der Zugänglichkeit GUI-Semantik bekommen.
Zumindest wird es einem von SELFHTML ja so beigebracht. Wenn man jetzt den Inhalt selbst im Hintergrund verwaltet und den DOM-Baum nur noch zur Ausgabe "missbraucht", ist das doch beinahe so ähnlich wie eine Flash-Seite. Je nach Umsetzung könnte so eine bestimmt das Modell auch sehr gut umsetzen.
Flash hat im Grunde eine ähnliche Entwicklung durchgemacht, ja. Am Ende kamen wie AS3 und Flex heraus.
Mathias
-
Hallo,
endlich wieder Internet, nachdem mein Provider 5 Tage lang nicht geschafft hat, den Port zu resetten. Naja, zurueck zum Thema.
Eine Übersicht habe ich mal hier zusammengestellt:
http://molily.de/js/organisation-ueberblick.htmlJavaScript ist unmittelbar objektorientiert, allerdings nicht klassenbasiert. Alles ist entweder ein Objekt oder verhält sich wie eins, es gibt Funktionen/Konstruktoren und Prototypen.
Vermutlich ist es das beste, wenn ich mal mehr mit JavaScript arbeite. Dann sollte ich die Moeglichkeit haben, auszuprobieren, wie man es gut umsetzt. Danke uebrigens fuer die Uebersicht.
Java spielte im öffentlichen Web nie eine große Rolle. Java-Applets sind seit Jahren verschwunden, von obskuren Intranets mal abgesehen. Wie gesagt gibt es mit Android eine Mobilplattform, für die man native Apps üblicherweise in Java entwickelt. Es ist tatsächlich so, dass es einen Widerstreit zwischen plattformübergreifenden Web-Apps for Mobilgeräte und nativen Apps gibt. Viele fragen sich, ob sie lieber mobiltaugliche Web-Apps oder verschiedene native Apps entwickeln. Für aufwändigere Dinge sind native oder hybride Apps immer noch die beste (und weitaus teurere) Wahl.
Dass Java wirklich aus dem Web verschwunden ist, kann ich leider nicht bestaetigen. Ich wuerde eher behaupten, dass es ein Nischendasein fristet. Richtige Webanwendungen findet man zwar nicht, aber dafuer noch Veranschaulichungen (meist von Universitaetsseiten) oder auch Spiele.
Und bezueglich der nativen (Java-) Apps stelle ich mir immer noch die Frage, ob eine Ersetzung mit HTML5/JavaScript nicht zu erhoehten Hardwareanforderungen und Mehrbedarf an Energie fuehren koennte, nachdem es eben nicht nativ laeuft, sondern noch einmal abstrahiert wurde. Auch wenn JavaScript "nur zehnmal mal langsamer" ist als C (und noch weniger langsamer bei Java), kann ich mir nicht vorstellen, warum leistungsschwache (bzw. energiesparsame) Systeme darauf umgestellt werden sollen (ich denke wieder an Firefox OS, das angeblich auch auf billigen Smartphones hervorragend laufen soll)Anwendungen fressen üblicherweise nicht Ressourcen im Sinne von reiner CPU-Rechenpower. Sie brauchen Grafikressourcen (hardwarebeschleunigtes CSS, Canvas, WebGL), Asynchronität und Nebenläufigkeit (setImmediate, requestAnimationFrame, Web Workers), schnelle Netzwerkprotokolle (Websockets, Server-sent events, XHR2/CORS, SPDY), clientseitige Datenbanken (indexedDB, Offline-Storage) und so weiter. An diesen APIs wird im Zuge von HTML5 gearbeitet.
Somit kann man die HTML5 zugeordneten Technologien wohl als eine Art "Rolling Release" ansehen, an dem (zumindest in naechster Zeit) immer weiter gearbeitet wird, um den Anforderungen von Webanwendungen gerecht zu werden?
An sich ist ja schon eine ganze Menge vollbracht. Vermutlich hast du mich ueberzeugt, dass JavaScript eine akzeptable Sprache ist und HTML5 gar nicht so viel "schlechter", sondern eventuell sogar besser ist als ein auf XML basierendes Konstrukt.Das HTML-DOM für Anwendungen zu verwenden ist natürlich ursprünglich ein Hack, denn HTML beschreibt Hypertext-Dokumente, nicht GUIs. Erst mit HTML5 sind ein paar entsprechende native Controls hinzugekommen.
Was darf ich unter "nativen Controls" verstehen? Damit ist bestimmt nicht Canvas gemeint, oder? HTML5 will ja immer noch einer Auszeichnungssprache gerecht werden.
Bei nativen GUI-Toolkits operiert man nicht direkt auf einem DOM-Baum, aber intern haben die auch nur einen Objektbaum aus wiederverwendbaren Controls, die letztlich aus primitiven Zeichenobjekten bestehen. Im Vergleich zum DOM ist nur der Abstraktionsgrad höher. Ansonsten arbeitet z.B. Flex oder Qt durchaus mit einem DOM-ähnlichen Objektmodell.
Das DOM ist aber doch eher der Syntaxbaum eines semantischen Inhaltsmodells als ein Objektbaum der grafischen Ausgabe. Da es allerdings zur Ausgabe verwendet wird, fehlt doch irgendwie die Trennung von Layout und Inhalt. Mir wird noch nicht ganz klar, ob du das DOM nun fuer die Ausgabe nutzen wuerdest (bzw. ob die von dir genannten Toolkits das so umsetzen) und die eigentlichen Daten intern in einer Datenstruktur verwalten wuerdest, oder ob das DOM gleichzeitig als Datenstruktur dient. Es wirkt wie ein Zwischenschritt, den ich nicht so ganz einordnen kann.
Für HTML gibt es z.B. mit den Web Components und dem Shadow DOM Erweiterungen, die auf eine höhere Abstraktion abzielen. Außerdem gibt es wie gesagt GUI-Toolkits für JavaScript. ExtJS, YUI, Ember und Co. sorgen dafür, dass man auf Anwendungsebene nicht mehr direkt mit dem DOM zu tun hat, sondern nur mit Views bzw. UI-Komponenten und Widgets.
Das muss ich mir mal anschauen, vielleicht kann das meine Frage von oben klaeren. Ohne einfacheres Tutorial empfinde ich es allerdings als schwierig, mir in kurzer Zeit einen Ueberblick zu verschaffen. Sieht aber sehr schoen aus, muss ich zugeben!
Ja, siehe oben, das ist die ursprüngliche Aufgabe: Hypertexte zu strukturieren und auszuzeichnen. Webanwendungen gehen natürlich weit darüber hinaus. Wie gesagt gibt es verschiedene Bestrebungen, diesen Paradigmenwechsel auch technisch eine Form zu geben. HTML5 als Spezifikation von »web applications« ist ein Ansatz, zusätzlich gibt es etwa WAI-ARIA, wodurch HTML-Elemente zum Zweck der Zugänglichkeit GUI-Semantik bekommen.
Ist das jetzt die Antwort auf meine andere obige Frage? Einfach ausgedrueckt, kann man jetzt wohl sagen, dass HTML5 keine semantische Sprache, sondern eine graphische Sprache sein soll? Wenn ich das jetzt richtig verstanden habe, werfe bitte alle meine obigen Fragen ueber Bord, wenn HTML5 aber immer noch Semantik in das Web bringen soll, bleiben sie stehen ;)
Noch schoene Gruesse,
Rachus
-
-
-
-
Hallo,
Dem möchte HTML 5 gerecht werden, allerdings empfinde ich, dass das auf Kosten einer sauberen Architektur basiert.
Zu diesem Schluss komme ich, da HTML 5 im neuen Standard festschreiben möchte, wie Fehler richtig zu behandeln und zu beheben sind.XML definiert ebenfalls das Verhalten bei Fehlern. Hat XML eine unsaubere Architektur?
Diesen Ansatz fand ich bei XHTML auf Basis von XML (natürlich per "Content-Type: application/xhtml+xml" oder vergleichbarem ausgeliefert) sehr schön, da der Parser fest vorgegebene Regeln hat.
Der HTML5-Parser hat ebenfalls fest vorgegebene Regeln. Tatsächlich haben inzwischen 4 der 5 großen Browserhersteller einen HTML5-Parser, d.h. egal wie viele Fehler ein Dokument hat, diese 4 Browser verarbeiten es identisch. Das ist ein großer Vorteil der nur HTML5 zu verdanken ist.
Der IE ist der noch fehlende Browser, aber auch dieser hat bereits seinen HTML5-Parser in einer Vorabversion veröffentlicht. Das hatte den Nebeneffekt, dass ein paar proprietäre Features entfernt wurden (xml-Element, CSS-Behaviours, Conditional Comments).
HTML 5 versucht außerdem abwärtskompatibel zu sein, was einerseits auch wieder verständlich ist, da ja Benutzer älterer Browser wenigstens noch das sehen können möchten, was nicht erst durch neue Features eingeführt wurde, aber andererseits damit auf einer Basis steht, die nicht mehr zeitgemäß ist (erinnert beinahe etwas an den Zwang der Abwärtskompatibilität bei x86-Prozessoren, aber auch das möchte ich nicht schlecht reden!).
HTML5 führt durchaus auch Inkompatibilitäten zur Vorversion ein, allerdings will HTML5 Uralt-Dokumente darstellen können (was die Browser schon vorher versuchten, nur jeder mit seiner eigenen Methode) und das einführen von neuen Funktionen in der Zukunft vereinfachen.
Bitte beachte auch, dass HTML5 zwar vielen verarbeiten kann, aber nicht alles davon auch für Autoren erlaubt ist. Beispiel: HTML5 legt fest, wie das plaintext-Element zu verarbeiten ist, wenn es in einem Dokument vorkommt. Jeder HTML5-Validator wird dir aber sagen, dass es verboten ist, dieses Element zu benutzen.
Einige der Schritte in XHTML 2 hatten mir da besser gefallen. Da war die Tag-Basis sauberer (wenn man auch hätte weiter gehen können), wobei mir die neuen Multimediafunktionalitäten gefehlt hätten.
Ein paar Konzepte wurden ja in HTML5 übernommen, z.B. die Möglichkeit mehr als sechs Überschriftenebenen zu erstellen.
Zur "Technologie" HTML 5 gehört ja auch noch JavaScript, was wiederum seine Macken hat.
Du bringst ziemlich viel Durcheinander.
HTML5 ist im Kern nur ein Vokabular das in der Terminologie des DOM formuliert ist. Dafür brauchst du kein JavaScript. Das Vokabular kannst du in HTML (dafür spezifiziert HTML5 seinen eigenen Parser) oder in XML nutzen. Für die Browser legt HTML5 zudem fest, wie die Navigation von HTML-Dokumenten funktionieren soll und gibt Hinweise über die Standarddarstellung verschiedener Elemente.Gruß
-
XML definiert ebenfalls das Verhalten bei Fehlern. Hat XML eine unsaubere Architektur?
Die Definition ist aberwesentlich weniger Komplex als jene von HTML5 - je komplexer, desto Fehleranfälliger. Aber Wie molily schon sagte: der drakonische Ansatz hätte in den Weiten des Internet nicht funktioniert.
-
Hallo,
vielen Dank für die Antworten!
XML definiert ebenfalls das Verhalten bei Fehlern. Hat XML eine unsaubere Architektur?
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. Ist aber wie gesagt nur meine Meinung, und vielleicht lasse ich mich ja überzeugen!
Der HTML5-Parser hat ebenfalls fest vorgegebene Regeln. Tatsächlich haben inzwischen 4 der 5 großen Browserhersteller einen HTML5-Parser, d.h. egal wie viele Fehler ein Dokument hat, diese 4 Browser verarbeiten es identisch. Das ist ein großer Vorteil der nur HTML5 zu verdanken ist.
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. Als interne Datenstruktur werden wohl bei beiden Technologien Dokumentenbäume aufgebaut.
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.HTML5 führt durchaus auch Inkompatibilitäten zur Vorversion ein [...]
Bitte beachte auch, dass HTML5 zwar vielen verarbeiten kann, aber nicht alles davon auch für Autoren erlaubt ist. [...]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?).
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.Ein paar Konzepte wurden ja in HTML5 übernommen, z.B. die Möglichkeit mehr als sechs Überschriftenebenen zu erstellen.
Was natürlich auch sehr zu begrüßen ist!
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.
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!Schöne Grüße!
-
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
-
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.
Die allgemeine Regel bei HTML5 ist im Vergleich dazu: Wenn Fehler, dann ignoriere den Token und mache weiter.
Für XML gibt es übrigens einen Entwurf für Fehlerbehandlung in diesem Sinne (aus der HTML5-Ecke natürlich): XML5
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.
XML ist sehr komplex und modular, das ist mehr ein System als eine konkrete Parserspezifikation. Es gibt sehr schnelle und performante Minimal-Implementierungen, die nur die wichtigsten Fälle abdecken und nicht alle XML-Features implementieren.
Wenn man einen XML-Parser entwickeln will, der die Komplexität von Webseiten handhaben kann und die dafür nötigen Techniken aus dem XML-Universum unterstützt, so ist man sicher bei der Komplexität des HTML5-Parsers angekommen oder sogar darüber hinaus geschossen.
Aus dem Dilemma hatte man sich bei XHTML2 herausgestohlen, indem man die Komplexität verleugnet hat und Features von HTML kurzerhand abgeschaltet hatte, wie z.B. das Modifizieren des Dokuments durch JavaScript während des Parsens. Das war ein Grund, warum XHTML2 nicht in der Realität angekommen ist. Nicht dass es an sich keine guten Gründe dafür gibt, solche Features, die die Komplexität und Anfälligkeit des Parsers unglaublich erhöhen, abzuschalten.
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.HTML5 kann m.W. genauso streng auf Fehler geprüft werden. Die HTML5-Spezifikation definiert zwar kein maschinenlesbares Schema, aber der Validator.nu-Validator definiert durchaus maschinenlesbare Schemata, gegen die sowohl HTML5 als auch XHTML5 geprüft wird. Bei XHTML5 kommt nur die Verarbeitung als XML hinzu – und die wird implizit durch den Einsatz eines XML-Parsers geprüft.
Mathias
-
Grüße dich, Matthias,
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.HTML5 kann m.W. genauso streng auf Fehler geprüft werden. Die HTML5-Spezifikation definiert zwar kein maschinenlesbares Schema, aber der Validator.nu-Validator definiert durchaus maschinenlesbare Schemata, gegen die sowohl HTML5 als auch XHTML5 geprüft wird. Bei XHTML5 kommt nur die Verarbeitung als XML hinzu – und die wird implizit durch den Einsatz eines XML-Parsers geprüft.
Ja, das stimmt. Ich wollte damit auch eher sagen, dass HTML5 besser auf Fehler überprüft werden könne als XHTML5, weil bei XHTML5 ein XML-Valitator verwendet wird, der z.B. keine Verschachtelungsregeln prüfen kann.
Allerdings scheine ich mich da geirrt zu haben. Wenn ich dem Validator (W3C) XHTML5 zukommen lasse erhalte ich ebenfalls einige zusätzliche Meldungen im Vergleich zur Prüfung von XHTML 1.x. Von daher scheint es aus Sicht der Validierung keinen Unterschied zwischen beiden Ausprägungen zu geben.
Gruß, Daniel
-
-
-
-