Neues Profil: XHTML+RDFa

Webdesign & Technik HTML & CSS
1

Während sich ja (immer noch) zahlreiche bei HTML5 vor allem
mit Vergangenheitsbewältigung beschäftigen - also das
unheilvolle Aufschaukeln von browser-Fehlern und -Lücken und
der Vertuschung von Fehlern in Dokumenten durch dieselben
bei gleichzeitigem Anstieg des relativen Anteils fehlerhafter
Dokumente - und wie man all dies spezifizieren könnte, tut sich
an anderer Stelle mal wirklich etwas Interessantes, was sich bei
XHTML als sehr nützlich erweisen kann/wird,

Es gibt ein neues XHTML-Profil, welches mit Attributen die
Möglichkeiten von RDF integriert, so daß man Dokumente
erstellen kann, deren Inhalte viel bedeutungsvoller ausgezeichnet
werden können als mit bisherigen Varianten von (X)HTML und
das sogar in einer maschinenlesbaren Form.

Ein weiterer Nebeneffekt ist wohl, daß der doctype nicht
angegeben werden muß, stattdessen eine Versionsangabe, was
es einem auch ohne weitere Probleme ermöglichen sollte,
damit endlich zusammengesetzte Dokumente (‘compound
documents’) zu erstellen, also solche, wo man einfach Formate
wie XHTML, MathML, SVG etc mischen kann, ohne darauf
angewiesen zu sein, daß jemand eine DTD entwickelt, die
die jeweilige Variante abdeckt (praktisch funktioniert das ohnehin
schon seit längerem, durch den Wegfall des doctypes kann man
nun aber auch wirklich eine XHTML-Variante mit Versionsangabe
zu dem Zwecke als Wurzeldokument nutzen. Speziell für
XHTML+RDFa gibt es allerdings auch eine DTD).

Insofern es geht also doch voran mit XHTML, wer Interesse hat,
kann ja mal gucken, man kann das Profil ab sofort samt der neuen
Attribute nutzen, ist auch nicht bekannt, daß das Probleme bei
älteren browsern bewirken täte (die die neuen Attribute eben nur
als unbekannt ignorieren werden).

Das ist eine schnelle Erklärung des generellen Prinzips:
w3.org/TR/xhtml-rdfa-primer/
Das ist die im Oktober finalisierte Empfehlung:
w3.org/TR/rdfa-syntax/

Ich denke, ich werde in näherer Zukunft einige meiner Projekte
von XHTML1.1 auf XHTML+RDFa umstellen, weil letzteres
nützlicher erscheint.

2

Da tut sich zur Zeit wirklich viel… Das Problem ist die Umsetzung :wink: Die Standards sind schnell definiert. Wann das Ganze aber von den verschiedenen Browsern unterstützt wird, ist eine andere Sache (ja, ich spiele auf den MSIE an…)

Daher halte ich es jetzt noch nicht besonders sinnvoll sich auf neue Standards zu verlassen, da speziell der MSIE7 noch nicht mal XHTML 1.1 komplett unterstützt :wink:

3

Hinsichtlich des MSIE-Problems scheint mir da auch
XHTML+RDFa etwas freundlicher zu sein, weil man da anders als
bei XHTML1.1 eben keinen doctype angeben muß. Wenn man
dem MSIE das einfach als application/xml statt als
application/xhtml+xml unterschiebt, könnte das bereits
funktionieren, da der XML durchaus interpretiert (nicht so gut
wie moderne browser, aber immerhin). Und selbst, wenn man dem
MSIE den Kram als text/html unterschiebt (was man nicht bei
moderneren browsern tun sollte, die kein Problem mit
application/xhtml+xml haben), sollte der keine Probleme damit
haben, weil mal abgesehen von ruby (was es auch schon in
XHTML1.1 gibt) ‘nur’ neue Attribute auftauchen oder die
Bedeutungen von Attributwerten erweitert werden oder neue
Namensräume auftauchen. Das sind aber alles Dinge, die den
’HTML’-parser vom MSIE nicht besonders stören sollten, weil der
ja gerade darauf ‘optimiert’ ist, alles als HTML darzustellen, selbst
Konstruktionen, die er nicht versteht. Nur deswegen funktioniert
es ja derzeit auch, daß man dem MSIE XHTML1.0 oder XHTML1.1
als text/html unterschiebt und der da was halbwegs sinnvolles
darstellt. Demgegenüber können die Geckos, Opera oder die
Konqueror/WebKit-Gruppe das einfach als application/xhtml+xml
interpretieren. Selbst wenn die gewisse neue Attribute noch nicht
kennen, wird sie das nicht daran hindern, den Inhalt darzustellen.
Insofern ist da das XHTML+RDFa so trickreich angelegt, daß es
alten browsern keine Probleme bereitet oder gar weniger als die
anderen XHTML-Varianten …
Das ist auch relativ harmlos in Vergleich zu neuen Elementen
und Funktionalitäten in ‘HTML5’ - die eben drolligerweise nicht
wie von der Arbeitsgruppe ursprünglich anvisiert
rückwärtskompatibel sind, wenn man das wirklich braucht, darf
man die wirklich schönen Neuerungen wie die Elemente
section, article, aside, audio, video etc von ‘HTML5’ gar nicht
erst verwenden. Mit XHTML+RDFa kann man die damit verbundene
Bedeutung allerdings recht einfach bereits heute angeben, ohne
neue Probleme in alten browsern hervorzurufen.

Die alten browser können eben nur nicht vermitteln, was der
Inhalt bedeutet, obgleich es im Dokument bereits drinsteht, viel
detaillierter als man es mit XHTML allein jemals angeben könnte.
Sobald modernere browser oder auch Roboter von Suchmaschinen
die neuen Attribute interpretieren, ist all die Information verfügbar,
ohne daß es alte browser behindern täte. Daher kann man das
bereits jetzt recht bedenkenlos einsetzen. Denn nur, wenn es
reichlich Dokumente gibt, die das verwenden, steigt der Druck
auf die browser-Anbieter, das auch zu interpretieren, statt nur in
der Nabelschau (‘HTML5’) zu schwelgen.

Was der MSIE zu der Variante sagt, muß ich aber mal selber
testen (besonders mit dem XML-parser, der HTML-parser sollte
ziemlich sicher klarkommen - wie immer, dem kann man ja
so ziemlich alles vorsetzen, irgendwas macht der draus ;o)

Achso, kein einziger browser beherrscht HTML4 komplett, trotzdem
haben da bereits Millionen von Menschen Milliarden von
Dokumenten veröffentlicht ;o) Genaugenommen beherrschen
die browser (mal abgesehen vom MSIE) heute bereits XHTML
deutlich vollständiger als HTML4, weil es viel einfacher zu
implementieren ist.

4

Das finde ich gut, trotzdem wäre ich ohne das MSIE-Problem um einiges glücklicher, da ja schon sehr fortgeschrittene Gestaltungsmöglichkeiten für Webseiten bestehen: Quellcode eu.wowarmory.com/character-sheet … sza&n=Smoo (Mozilla Firefox)

Diese Möglichkeiten würde ich wirklich gerne verwenden, wenn nicht der MSIE der häufigste Browser im Internet ist :wink:

5

Nunja, die referenzierte Seite ist ja auch eine dubiose
Konstruktion ;o)
So sollte man es wohl gerade nicht machen.
Die gibt per doctype XHTML1.0 an, hat zudem eine
XML-Stilvorlagenverarbeitungsanweisung für XSL, sendet den
Kram dann allerdings wieder als text/html - offenbar an alle
browser. Anders ginge es auch gar nicht, denn die Seite gibt
keinen Namensraum an und enthält auch grobe
XML-Strukturfehler.
Wenn man das aber als text/html sendet, ergibt die
XML-Stilvorlagenverarbeitungsanweisung dann allerdings keinen
Sinn, weil es ja kein XML ist, wird wohl auch gar nicht interpretiert
werden, wenn doch, wäre das für text/html sicher ein
browser-Fehler. Ein HTML-parser sollte es ignorieren, der Validator
gibt an, daß es ein Fehler ist.
Sieht für mich jedenfalls nicht so aus, als wären da die Grundlagen
entweder von HTML oder XHTML wirklich verstanden worden ;o)

Inhaltlich könnte die Seite wohl dringend sowas wie XHTML+RDFa
gebrauchen, denn im Quelltext kommen da verdächtig viele
div-Elemente vor.
Die Seite könnte auch dringend das noch in Arbeit befindliche
role-Attribut brauchen, denn da kommen ja doch reichlich
Skripte im Quelltext vor (wofür auch immer, ich habe das bei
mir unbekannten Seiten nicht aktiviert).

6

Naja, die Seite selbst finde ich auch etwas dubios gestaltet…der FF3 erhält XML mit XSL-Sheet, FF2/Opera/Webkit bekommen XHTML 1.1 und der MSIE bekommt HTML 4.1… Das heißt erstens, dass Blizzard mit WoW viel zu viel verdient und zweitens, dass sie nicht wissen, dass der Code ein mal genügt hätte :ps:

7

Bei einem ziemlich alten firefox2 von 2006, den ich herumliegen
habe, sehe ich da irgendein (fehlerhaftes bis blödsinniges, weil
ohne Namensraumangabe) XML, welches falsch als text/html
gesendet wird und wohl auch fälschlich vom firefox2 als XML
interpretiert wird. Bei allen anderen aktuelleren Versionen vom
Gecko (iceweasel, iceape), bei Opera und beim Konqueror sehe
ich da einfach (fehlerhaftes) XHTML1.0 transitional, welches
ebenfalls als text/html gesendet wird.
Da ist nicht nur der sichtbare Quelltext blödsinnig, das
’browser-sniffing’ scheint auch komplett in die Hose zu gehen.
Der Autor scheint also auch massive Probleme mit dem Skript
zu haben, was das Zeug produziert ;o)

Da kann man schon verstehen, daß einige Leute meinen, HTML
dürfe nicht mehr als 5-10 Elemente haben, damit solche Autoren
damit zurechtkommen. Hilft aber nix - die vermurksen dann auch
noch XML, wie man sehen kann ;o)

8

Naja, mein FF3 bekommt das: pastebin.com/m5471089a (habs mal nicht gekürzt :wink: )

9

Ja, sowas sehe ich mit dem firefox2 von 2006 auch, mit neueren
Geckos dann aber nicht mehr (die haben aber auf Debian dann
auch kein ‘firefox’ mehr in der Kennung vom ‘user-agent’ stehen
;o)

10

hmm…Warscheinlich haben da mehrere dran gearbeitet, ansonsten schafft man es kaum, so einen Murks zu fabrizieren :wink: