nicht angemeldet
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