Mittwoch, 20. April 2005
W3C: XHTML2 und XFORMS Tutorial
Gestern war in St. Augustin ein vom Deutsch-Österreichischen W3C-Büro veranstaltetes Tutorial zu XHTML 2 und XFORMS, gehalten von Steve Pemberton.
Beim zuletzt veranstalteten Vortrag über RDF war ich auch schon dabei, und war davon so angetan, dass ich natürlich auch dieses Mal teilnehmen musste. Das dachten sich wohl auch andere, denn im Gegensatz zu den damals 40 Teilnehmern waren diesmal 100 angemeldet. Darunter auch Tom, Andy und Nadine mit denen ich dort gemeinsam in der großzügig ausgestatteten Konrad-Adenauer-Stiftung aufschlug.
Das Tutorial wurde in Englisch gehalten und dauerte mit 30-minütiger Pause gut 4 Stunden. In dieser Zeit hat Steve, mit typisch britischem Humor, sehr eindrucksvoll und mit praktischem Beispielen so ziemlich alles über XHTML2 und XFORMS erzählt, was man sich vorstellen kann.
Die vollständigen und sehr ausführlichen Unterlagen zu dem Tutorial befinden sich auf W3.org, die ich jedem nur ans Herzen legen kann.
Hier dennoch ein kurzer Abriss, mit meinem eigenen knappen Kommentar:
Beim zuletzt veranstalteten Vortrag über RDF war ich auch schon dabei, und war davon so angetan, dass ich natürlich auch dieses Mal teilnehmen musste. Das dachten sich wohl auch andere, denn im Gegensatz zu den damals 40 Teilnehmern waren diesmal 100 angemeldet. Darunter auch Tom, Andy und Nadine mit denen ich dort gemeinsam in der großzügig ausgestatteten Konrad-Adenauer-Stiftung aufschlug.
Das Tutorial wurde in Englisch gehalten und dauerte mit 30-minütiger Pause gut 4 Stunden. In dieser Zeit hat Steve, mit typisch britischem Humor, sehr eindrucksvoll und mit praktischem Beispielen so ziemlich alles über XHTML2 und XFORMS erzählt, was man sich vorstellen kann.
Die vollständigen und sehr ausführlichen Unterlagen zu dem Tutorial befinden sich auf W3.org, die ich jedem nur ans Herzen legen kann.
Hier dennoch ein kurzer Abriss, mit meinem eigenen knappen Kommentar:
XHTML 2 vs. XHTML1
- Es gibt kein <h1>, <h2> usw. mehr. Stattdessen werden geschachtelte <header> und <section> Tags eingeführt. Die Wertigkeit der Gliederung ergibt sich so anhand der benutzten Verschachtelung, und nicht anhand von manueller Angabe mit Zahlen.
Sehr sinnvoll um den Leuten die Entscheidung der h-Zahl abzunehmen und so auch mehr der menschlichen Gliederung zu entsprechen. Allerdings auch ein höherer Parsingaufwand für u.a. Suchmaschinen - <hr> muss endlich weichen und dem semantisch passenden Tag <separator> weichen.
Auch sehr sinnvoll, da das vorige Tag eher nach "Präsentation" und nicht "Struktur" roch. - Listenaufzählungen (<ul>, <ol>) dürfen nun auch in block-Elementen erscheinen.
Entspricht ebenfalls wie das Platzieren von Sektionen eher dem, was ein Autor beim Schreiben von Absätzen empfindet: Subjektiv gehören Listenelemente für mich auch in ein Blockelement (z.B. Paragraph) - Für Bilder kann ein src="..." Attribut nun auf jedes Element angewendet werden. Alles innerhalb eines Tags wie z.B. <p src="bild.gif">...</p> wird dann als Alternative dargestellt wenn ein Bild nicht gefunden wird. Das macht das alt="..." -Attribut quasi überflüssig und erlaubt endlich auch vollständiges Markup als Alternative.
Zusätzlich können Bilder-Fallbacks angegeben werden. Ein <p src="bild" type="image/png, image/jpeg">...</p> würde so erst versuchen per Content-Negotioation (Browser sendet Accept: Header, gibt keine Dateiendung an, und der Server liefert automatisch das bevorzugte Bild zurück) das PNG-Bild zu finden, und danach das JPEG-Bild.
Gerade Content-Negotiation anhand des type="..." Attributes war für mich ein Aha-Effekt. Wirklich genial, auch wenn es Server- bzw. Scriptseitig implementiert werden muss ist es doch ein Traum auf Browserweichen zu verzichten und auch barrierefreien Content anzubieten je nach Screenreader - <br /> stirbt und wird abgelöst durch <l>...</l> Tags.
Das scheint mir noch etwas kompliziert zu sein. Mit Grauen sehe ich Dokumente mit zigtausend dieser Tags kommen, da es ja auch nur dann Sinn macht wenn man fast jede Zeile damit einschließt. Auf der anderen Seite fördert es, breaks nicht als Layout-Umbruch anzusehen und seinen Text mit semantisch passenderen paragraphen zu umschließen. - href="..." darf auf jedes Element angewandt werden.
Auch ein nettes Gadget, wenn nicht wirklich erforderlich. Kann aber viele >a<-Tags überflüssig machen, das ist als Autor ganz schön - <nl> Tag als neue Listenaufzeichnung für die semantische Definition einer Navigation
Da sag ich einfach nur "Ja!" zu. - Die Tags <ins>, <del>, <bdo> sind entfernt worden und erscheinen stattdessen als Attribute von Tags (<p edit="deleted">).
Das ist ein stellvertretendes Beispiel für ein anscheinend globales Vorgehen des W3C: Anstelle neue Tags zu erfinden vergibt man lieber Attribute. Ist als Autor auch meiner Meinung nach besser nachzuvollziehen, für die Maschinen bedeutet das jedoch mehr Parsing-Aufwand - media="..." kann für jedes Tag verwendet werden, um anzugeben ob ein Element in einem speziellen Medium (Screenreader, Handy, PC, ...) erscheinen soll.
Nette Idee, allerdings finde ich sollte sowas eher nur in CSS realisiert werden. Auf der anderen Seite sind das auch wieder semantische Zusatzdaten, die von generellem Interesse sein können, also schadet es nicht wirklich dies in XHTML2 zu haben - RDF-Integration, jedoch mit eigener Beschreibungssprache. Anstelle der etwas müßigen und nicht-validierbaren HTML-Kommentare und endlosen <rdf:RDF>-Tags wird auf <meta about/property/ref="...">...</meta> Tags zurückgegrifen. Diese sind für Autoren doch leichter nachzuvollziehen und auch für Editoren leichter zu implementieren. Das <meta>-Tag kann auch überall im Dokument eingesetzt werden, und jedes beliebige Tag-Konstrukt mittels URL oder ID beschreiben. Mittels eines Parsers namens GRDDL können diese Metadaten wohl auch schon in RDF recoded werden.
Anfangs hielt ich es für eher ungeschickt, eine neue Syntax für RDF einzuführen, und die Komplexität von RDF mittels Triplets so etwas zu unterbrichen und eigentlich "Duolets" daraus zu machen. Dadurch verlieht das Model schon etwas an Abstraktion, ist dafür aber auch wirklich viel verständlicher. - Zentrales role="..." Attribut für jedes Tag. Dieses universelle Attribut ermöglicht es jedes beliebige Tag mit einer selbstdefinierten Rolle (bzw. vordefinierten aber erweiterbaren) auszustatten, um so einen Browser nach etwaigen Rollen filtern zu lassen.
So könnte man beispielsweise gewisse Elemente als "Notiz" auszeichen, und der Browser könnte alle Notizen auf einer Unterseite gesammelt anzeigen. Oder man kann Paragraphen die Rolle "Einleitung" verpassen und so später nur Einleitungen filtern für Querleser.
Pemberton stellte dieses Attribut zudem als RSS-Killer vor. So kann man nämlich beliebige Rollen (dc:title, entry, lastModified, ...) als Attribut von einfachen div/p-Tags in die XHTML-Seite einfügen. Und schon braucht man keine separate RSS-Seite mehr, sondern der Feedreader kann die unveränderte XHTML-Seite vollständig parsen.
Da gewöhnt man sich müßig an RSS, und jetzt soll es sofort wieder obsolet sein? Es hat auf jeden Fall Vorteile nur eine einzige Seite anzubieten, die für mehrere Medien evaluiert werden kann. Jedoch erhöht dies auch den Overhead sehr: Wenn eine XHTML-Seite geparsed wird, werden für einen RSS-Feed vermutlich 50% des Inhalts verworfen. Ausserdem wird eine Seite so komplett auswertbar, während man bei RSS-Feeds schon noch etwas Content "unauswertbar" machen kann und als Mehrwert für die Hauptseite anbietet. Ich bin gespannt, wie sich das in "echten Welt" auswirken wird. - Accesskeys sind nun schön gesammelt im <head>Bereich aufzufinden via <access targetrole/targetid="..." key="..." />. Keys können so auf jedes Tag angewendet werden, sind zentral evaluierbar und können auch direkt für Objektklassen (targetrole) spezifiziert werden.
Herrlich! - onclick, onmousedown etc. Handler werden verworfen. Sie haben sich als nicht erweiterbar rausgestellt und werden nun durch XML Events abgelöst. Diese sind mittels <input ...><handler ev:Event="DOMActivate"></input> ansprechbar. Damit können nun beliebige neue Handler-Namespaces erfunden werden, die auch deutlicher als bisher ausgewertet wurden. Früher war ein onclick doch serh interpretationsfähig für Browserhersteller: Soll es ausgeführt werden wenn der User klickt, oder auch wenn er das Feld mit "Enter" auslöst? Zusätzlich ermöglichen die neuen Handler auch Mehrfachverwendung von identischen Handlern mit unterschiedlichen Scripting-Sprachen (VBScript oder JavaScript, früher konnte man immer nur eine von beiden nutzen).
Sehr genial, wenn auch vom Parsingaufwand wesentlich größer. Aber auch lassen sich jetzt XSS Exploits besser handeln - einfach alle <handler>-Tags aus dem Userinput filtern, und gut ist. Klasse! Die VBScript + JavaScript-Argumente vermögen mich eher nicht zu überzeugen: "One scripting language ought to be enough for everybody"
XFORMS
Der XFORMS-Teil des Vortrages war deutlich geprägt von praktischen Beispielen und dem "Werbetrommel rühren" für die Implementation von XFORMS. Die Grundlagen von XFORMS sind die Trennung in
- Modell - Dies spezifiziert die Datenquellen des Formulares. Z.B. Benutzername, Alter usw., komplett mit Angabe der Datentypen und Abhängigkeiten soviel etwaiger Validationen
- Interface/Bindings - Hier können spezifizierte Datenquellen visualisiert werden und der Nutzer kann Eingaben vornehmen.
Diese praktische Trennung ermöglicht so coole Sachen wie das Vorladen von Daten mittels externen XML-Daten, oder auch die Ausgabe von Formulardaten als XML-Datensatz.
Die Datenquellen können komplett mit XML-Schemas beschrieben werden, also ein Segen für jeden der seine Datenquellen schon in diesem Format vorliegen hat.
Datenquellen und Bindings können mittels XPath selektiert und evaluiert werden, und auch per XMLRPC Methoden ausgeführt werden.
Was so einfach klingt, ist in "wirklicher Syntax" doch schon sehr kompliziert. Was da an Metadaten, XML-Schemas und Bindings anfällt ist fast garnicht mehr lustig. Doch der Mehrwert ist unabstreitbar: Alleine mit XFORMS ist es möglich ein XHTML-Dokument komplett mittels Formularen zu bearbeiten und später ein gültiges XHTML-Dokument auszuspucken. Das kann dann per XMLRPC oder HTTP-PUT auch schon direkt weiterverarbeitet werden. Lecker!
Der Vorteil von XML-Schemas für die Datenquellen ist zudem folgender: Bei der Validation von Clienteingaben kann dasselbe Schema für die erneute Validierung Serverseitig verwendet werden. So stelle ich mir das zumindest vor, denn in einer Serverapplikation würde ich nicht darauf vertrauen wollen, dass eine manipulierbare XFORMS-Applikation mir Daten unterjubelt.
Für XFORMS 1.1 sollen solche Sicherheitsmodelle, auch für erlaubte Modelländerungen und Zugriffsmethoden, wohl auch zentrales Thema sein/werden.
Mein Eindruck von XFORMS ist also sehr mächtig, da wird man schon einiges machen können. Die XFORMS-Clients jedoch scheinen mir alle noch etwas "beta" zu sein, und laufen auch nicht richtig flüssig. Die von Steve angesprochenen 5 Jahre Dauer, bis eine W3C-Recommendation praxistauglich ist, sehe ich da durchaus als notwendig an.
Der gesamte Vortrag war wirklich spannend zu erleben, mir brennt es fast unter den Fingern, XHTML2 einsetzen zu können. Bilder des ganzen gibt es die Tage sicher bei Andy, Nadine oder anderen Teilnehmern.
Update 21.04. - Auf der Seite des deutschen W3C gibt es eine aktualisierte Teilnehmerliste, ein paar Links und Bilder zu dem Tutorial.
[ P.S.: Diese Seite hier ist sogar XHTML 1.1 valide.
]Kommentare
Ansicht der Kommentare:
(Linear | Verschachtelt)
Zum ersten: Das habe ich mich auch gefragt. Ich schätze das sollte per CSS geschehen. Da wäre es dann nur wichtig, dass der Browser das CSS vor dem eigentlichen Rendern lädt, denn sonst hat man den Effekt ja erneut. Ansonsten müsste man mal in dem Spec-Draft nachsehen ob width/height in allen Tags erlaubt ist. Das würde aber dann die Trennung von Layout/Content schon wieder etwas verwischen.
Die beste Lösung wäre theoretisch ja, wenn der Browser bei Bildern einen HTTP-Header mit width/height zurückliefert.
2.: Da könnte ich mir Browsersupport mit Popup-Links vorstellen, oder gewissen "onmouseover" Regionen, so wie es jetzt schon ist wenn man Tabellen/Divs verschachtelt die jeweils onmouseover Events haben.
3.: Mit CSS-Selektoren:
*[href] { color: blue}
vermute ich.
Die beste Lösung wäre theoretisch ja, wenn der Browser bei Bildern einen HTTP-Header mit width/height zurückliefert.
2.: Da könnte ich mir Browsersupport mit Popup-Links vorstellen, oder gewissen "onmouseover" Regionen, so wie es jetzt schon ist wenn man Tabellen/Divs verschachtelt die jeweils onmouseover Events haben.
3.: Mit CSS-Selektoren:
*[href] { color: blue}
vermute ich.
QUOTE:
P.S.: Diese Seite hier ist sogar XHTML 1.1 valide.
Ist sie laut Validator garnicht, aber mal davon abgesehen sollen laut W3C XHTML 1.1 Seiten nicht mit mehr mit dem Content Type "text/html", sondern stattdessen mit "application/xhtml+xml" ausgeliefert werden. Letzteres aktiviert z. B. im Mozilla Browser auch den entsprechenden Parsermodus. Nur der dumme IE kann damit nichts anfangen und muss folglich weiter mit dem "falschen" text/html beliefert werden.
Mehr Infos unter:
http://www.w3.org/TR/xhtml-media-types/
http://schneegans.de/tips/apache-xhtml/
Also bitte entweder XHTML 1.1 valid und mit richtigem Header oder besser nur XHTML 1.0.
MfG
Spuerhund
PS: ich habe gerade mindestens 10 Versuche gebraucht, diesen Kommentar hier loszuwerden. Das System ist ultrabuggy, zum einen funktioniert es nur mit Cookies, dann muss man Name, Mail und Homepage bei jedem neuen Versuch nochmal eintragen und schließlich sind die Buchstaben der Spamschutzgrafik teilweise nicht eindeutig zu entzifffern. :-[
Spürhund,
vielen Dank für den Hinweis bei der Validierung. Der Fehler kommt aufgrund von zwei Sachen:
1. Ein JavaScript was ich erst vor kürzerem eingebunden habe, bei dem die &-Entities nicht validieren.
2. Eingehende Links in der rechten Seitenleiste von fremden Seiten enthalten ebenfalls falsche Entities.
Das war also zum Zeitpunkt des Schreibens meines Artikels nicht der Fall, daher validierte es damals. Ich werde natürlich mal probieren das bei nächster Gelegenheit zu beheben.
Übrigens ist auch genau das der Fall warum ich kein xhtml+html Content-Type schicke. Das ganze würde dann leicht fehlerhafte Seiten nicht mehr parsen und darstellen, und das passiert einfach aufgrund freier Benutzereingaben und menschlicher Fehler zu schnell. HTML ist ein Standard zur einfachen Darstellung, und ich finde man sollte den Validierungswahn nicht so ad absurdum treiben dass darunter die "Usability" scheitert.
Zu Deinen fehlerhaften Kommentaren: Das tut mir sehr leid, aber in den Hinweisen im Kommentarformular steht eindeutig dass Cookies benötigt werden. Das ist einfach erforderlich weil ich hier sonst mehrere Hundert Spamkommentare am Tag hätte. Vor die Wahl gestellt ob ich am Tag 100 Spams erhalten, oder ein Benutzer ein wertvolles Kommentar 1-2mal mehr eingeben muss bzw. dazu Cookies aktivieren muss ist für mich leider der einzig gangbare Weg. Da muss man sich bei den Spammern bedanken, die das Web für alle Nutzer einschränken.
Dass man Name usw. neu eintragen muss passiert nur wenn man "Daten merken" nicht aktiviert und kein JavaScript aktiviert hat. Sorry auch hierfür.
vielen Dank für den Hinweis bei der Validierung. Der Fehler kommt aufgrund von zwei Sachen:
1. Ein JavaScript was ich erst vor kürzerem eingebunden habe, bei dem die &-Entities nicht validieren.
2. Eingehende Links in der rechten Seitenleiste von fremden Seiten enthalten ebenfalls falsche Entities.
Das war also zum Zeitpunkt des Schreibens meines Artikels nicht der Fall, daher validierte es damals. Ich werde natürlich mal probieren das bei nächster Gelegenheit zu beheben.
Übrigens ist auch genau das der Fall warum ich kein xhtml+html Content-Type schicke. Das ganze würde dann leicht fehlerhafte Seiten nicht mehr parsen und darstellen, und das passiert einfach aufgrund freier Benutzereingaben und menschlicher Fehler zu schnell. HTML ist ein Standard zur einfachen Darstellung, und ich finde man sollte den Validierungswahn nicht so ad absurdum treiben dass darunter die "Usability" scheitert.
Zu Deinen fehlerhaften Kommentaren: Das tut mir sehr leid, aber in den Hinweisen im Kommentarformular steht eindeutig dass Cookies benötigt werden. Das ist einfach erforderlich weil ich hier sonst mehrere Hundert Spamkommentare am Tag hätte. Vor die Wahl gestellt ob ich am Tag 100 Spams erhalten, oder ein Benutzer ein wertvolles Kommentar 1-2mal mehr eingeben muss bzw. dazu Cookies aktivieren muss ist für mich leider der einzig gangbare Weg. Da muss man sich bei den Spammern bedanken, die das Web für alle Nutzer einschränken.
Dass man Name usw. neu eintragen muss passiert nur wenn man "Daten merken" nicht aktiviert und kein JavaScript aktiviert hat. Sorry auch hierfür.
Andys Blog am : W3C Tutorial xHTML2+XForms
Vorschau anzeigen