nicht angemeldet
Moin!
• ein leerer DOCTYPE (wozu überhaupt? HTML ist SGML, also eine DTD, und für die XHTML-Variante hätte man sich was Schönes (DTD, Schema, Relax NG) für den Parser aussuchen können)
Der Doctype ist ein notwendiges Übel: Mit ihm sorgt man dafür, dass jeder Browser den Full standards mode verwendet! Ansonnsten hat er keine bedeutung und ist daher in XHTML5 überflüssig. Er ist deshalb leer, weil die Restlichen informationen sinnlos wären und die aktuelle Form schnell und einfach und vor allem problemlos (case-insesitive) von der Hand geht.
Erst einmal vorweg: Ich finde case-insensitive nicht problemlos, sondern problembeladen: Es erzeugt Verwirrung beim Anwender, vor allem bei mehreren Anwendern, und erzeugt Mehraufwand beim Programmierer.
Der Doctype enthält nicht nur das „notwendige SGML-Übel“, sondern für den Parser potenziell wichtige Informationen: Eine DTD zum Prüfen sowie eine Versionsangabe. Wenn sich HTML5 mit <!DOCTYPE html> zufrieden gibt, wie will ich dann den Unterschied zu HTML6 kennzeichnen? Das ist einfach nicht zu Ende gedacht. Oder soll es in Zukunft HTML5 + Zusätze geben?
• XML-Namensraum von XHTML 1 zum Verwirren von Parsern oder Transformatoren
Das selbe gilt auch für XHTML 1.1 und 2.0, beide wollen zum jetzigen zeitpunkt diesen Namensraum verwenden, sind aber zueinander inkompatibel!
Arbeiten da irgendwo auch Informatiker oder Mathematiker ;-)
• audio, video und embed: Erinnert sich noch jemand daran, warum object eingeführt worden ist? Aber gleichzeitig: „applet has been obsoleted in favor of object.“
Hier kann man natürlich streiten, und embed hat leider wirklich eher Nachteile. Aber: Mit der selben Logik musst du auch das img-Element verbannen. Tust du das?
Ich hätte keine Probleme damit, img aus der Sprach zu entfernen. object ist doch viel flexibler: Der alternative Inhalt kann HTML sein, Microsofts CSS-Vergewaltigung, damit der MSIE transparente PNGs kann, hätte man als param definieren können. OK, für longdesc gäbe es dann keinen Ersatz …
• absent attributes: „longdesc attribute on img and iframe“
Ja, aber reiß das nicht aus dem Zusammenhang. Hier wurde geforscht und man hat herausgefunden, dass das longdesc-Attribut sehr sehr selten seinem Zweck entsprechend verwendet wird. Darüberhinaus sind sich die benutzer von Screanredern usw. dieser Möglichkeit nicht bewusst (auf Youtube gibts dazu auch ein Video von einem Jaws-Benutzer).
Sofern das Attribut denn überhaupt verwendet wird, wie wird es denn „falsch“ verwendet. Und dass User-Agents darauf keinen gescheiten Zugriff bieten würde ich nicht der Sprache anlasten, sondern den Entwicklern.
Da finde ich XHTML 2 schon den konsequenteren Entwurf, auch wenn XForms ganz schön starker Tobak ist.
Ich finde XHTML 2.0 nicht konsequent. Es ist eine Sprache, die mit HTML nichts mehr zu tun haben will, sondern etwas ganz neues darstellt. Dennoch will man nicht auf obsolote Elemente, wie z.B. das body-Element verzichten.
Die Schnittmenge von XHTML2 und XHTML1 ist allerdings nicht leer, sondern schon ganz gut gefüllt. Was ich wirklich gut finde, ist, dass man Navigationslisten auch als solche auszeichnen kann oder die Strukturierung mittels section und h. Warum soll denn body eigentlich obsolet sein?
Gut, hierüber kann man ebenfalls streiten. Aber der Web Forms 2.0 der WHATWG (der sich ebenfalls beim W3C befindet), will ähnliche Fortschritte machen, wie XForms, dabei aber kompatibel bleiben und für Benutzer verständlich. Auch hier wird eine Live-Überprüfung der Eingaben möglich sein.
Bei XForms geht es mir nicht nur um die Live-Überprüfung der Eingabe, sondern auch das klare MVC, was dahinter steckt oder die Serialisierung in XML. Wer sich mit GUI-Programmierung auskennt, findet da viele Gemeinsamkeiten. Das ist aber auch gleichzeitig eine Hürde für HTML-Autoren, das gebe ich zu. Web Forms 2.0 ist da ein recht guter Ansatz, zumal die Elemente, die es einführt, wahrscheinlich auf der Wunschliste fast jeden HTML-Autors stehen.
Wenn man jetzt „in XML machen würde“, könnte man beides als Module anbieten …
Schönen Sonntag,
Robert
Auge
Gunnar Bittersmann
MudGuard