Hat XHTML seinen Sinn verloren?

[Daniel unreg]

Hallo,

das W3C hat einen Working Draft zur überarbeiteten (Second Edition) Version von XHTML 1.1 veröffentlicht. Eine Sache fällt dabei besonders auf: Zukünftig soll man XHTML-1.1-Dokumente ebenfalls mit dem MIME-Typ text/html versenden drüfen.

Wenn ich daran denke, dass ich kaum eine Webseite, die in XHTML (1.0) geschrieben und noch dazu gültig ist, kenne, frage ich mich, ob XHTML seinen Sinn als Dokumentenformat verloren hat.
Es gibt zwar auch jetzt schon Webseiten, die in XHTML 1.1 verfasst (manchmal sogar in Strict [sic]) und nicht gültig sind, aber wenn das W3C XHTML 1.1 nun zum "Abschuss freigibt" sehe ich keine echte Zukunft mehr für XHTML.

Denn was bringt XHTML, wenn keines der Features, die es mit sich bringt genutzt werden kann, da letztendlich ohnehin alles als HTML-TagSoup geparst wird?

Dazu kommt die Arbeit an XHTML 2.0, diese scheint einerseits festgefahren zu sein. Andererseits hat sie jetzt Konkurrenz: HTML wird weiterentwickelt, vermutlich zu HTML 5.0. Dieses soll auch als XML-Dialekt verfügbar werden. Ende der XHTML-2.0-Entwicklung also?

Gruß;

[nam]

Hi!

das W3C hat einen Working Draft zur überarbeiteten (Second Edition) Version von XHTML 1.1 veröffentlicht. Eine Sache fällt dabei besonders auf: Zukünftig soll man XHTML-1.1-Dokumente ebenfalls mit dem MIME-Typ text/html versenden drüfen.

Durfte man das aus Kompatibilitätsgründen nicht schon immer? In XHTML-1.0 ist es klar definiert, zu XHTML-1.1 gibt es lediglich folgende W3C-Note: http://www.w3.org/TR/xhtml-media-types/xhtml-media-types.html die doch auch für XHTML-1.1 gilt, da nicht anders definiert. Oder?

Es gibt zwar auch jetzt schon Webseiten, die in XHTML 1.1 verfasst (manchmal sogar in Strict [sic]) und nicht gültig sind, aber wenn das W3C XHTML 1.1 nun zum "Abschuss freigibt" sehe ich keine echte Zukunft mehr für XHTML.

Solange der IE mit dem MIME-Typ 'application/xhtml+xml' nicht umgehen kann, wird wohl kaum jemand seine XHTML-Dokumente als 'application/xhtml+xml' versenden.

Denn was bringt XHTML, wenn keines der Features, die es mit sich bringt genutzt werden kann, da letztendlich ohnehin alles als HTML-TagSoup geparst wird?

Ich code mein XHTML immer händisch im Texteditor und schätze für die Lesbarkeit die klaren Richtlinien von XHTML-1.0. Ausserdem ist ein fehlerfreies XML Grundvoraussetzung für die automatische Weiterverarbeitung von Text - und das ist im Web2.0 zentral.
XHTML-1.1 wird afaik für kleine und/oder spezielle Geräte entwickelt, die nicht den vollen Funktionsumfang von XHTML bereitstellen.

Dazu kommt die Arbeit an XHTML 2.0, diese scheint einerseits festgefahren zu sein. Andererseits hat sie jetzt Konkurrenz: HTML wird weiterentwickelt, vermutlich zu HTML 5.0. Dieses soll auch als XML-Dialekt verfügbar werden. Ende der XHTML-2.0-Entwicklung also?

Wie gesagt: das Ganze steht und fällt mit der Unterstützung durch die namhaften Browser und MS ist hier (leider) noch immer in der einflussreichsten Position.

Gruss,
Mathias

[molily]

Hallo,

das W3C hat einen Working Draft zur überarbeiteten (Second Edition) Version von XHTML 1.1 veröffentlicht. Eine Sache fällt dabei besonders auf: Zukünftig soll man XHTML-1.1-Dokumente ebenfalls mit dem MIME-Typ text/html versenden drüfen.
Durfte man das aus Kompatibilitätsgründen nicht schon immer?

Nein, es gab keinen Standard, der das vorsah. »HTML-Kompatibilität« war ein Feature von XHTML 1.0.

In XHTML-1.0 ist es klar definiert, zu XHTML-1.1 gibt es lediglich folgende W3C-Note: http://www.w3.org/TR/xhtml-media-types/xhtml-media-types.html die doch auch für XHTML-1.1 gilt, da nicht anders definiert. Oder?

Da steht ausdrücklich, dass XHTML 1.1 nur als application/xhtml+xml oder application/xml ausgeliefert werden sollte.

Mathias

[nam]

Hallo Mathias

Da steht ausdrücklich, dass XHTML 1.1 nur als application/xhtml+xml oder application/xml ausgeliefert werden sollte.

Das dachte ich auch, bevor ich obiges Posting geschrieben habe - und habe zur Sicherheit nochmals nachgeschaut XHTML 1.1 - Module-based XHTML (quasi first edition) und gar nichts gefunden!

Aber ich lasse mich gerne eines Besseren belehren...

Gruss,
Mathias;-)

[nam]

Sorry
Wieder mal nicht richtig gelesen!
Shame on me!

(Wieso nur kann man hier seine Postings nicht löschen :-/)

[Daniel unreg]

Hallo,

(Wieso nur kann man hier seine Postings nicht löschen :-/)

Weil auch andere aus Fehlern lernen können ;-)

Gruß;

[Cybaer]

Hi,

(Wieso nur kann man hier seine Postings nicht löschen :-/)
Weil auch andere aus Fehlern lernen können ;-)

Hmm, das klingt sehr nach Oscar-verdächtigem Drama: Cheatah von Donnerhall präsentiert seinen neuen Film: "Die Fehler der Anderen"! ;)

Gruß, Cybaer

[molily]

Hallo,

Das W3C macht gerade seltsame Zuckungen. Nachdem Tim Berners-Lee auf den Trichter gekommen ist, dass die Masse nicht auf drakonische XML-Fehlerbehandlung steht und der Trend in Richtung geregelte Fehlertoleranz geht, scheint das wunderbar stimmige Konzept zu bröckeln. »Jetzt ist ja auch alles egal«, dachte sich da wohl jemand.

Der kleine Passus im neuen Entwurf sieht mir nach einem unüberlegten Schnellschuss aus. XHTML einfach mal als HTML umdeklarieren ist Unsinn, deshalb gab es bei XHTML 1.0 die Kompatibilitätsrichtlinien. Nur wenn man die penibel beachtet, ergab es wirklich Sinn, doppelt fähige Dokumente schreiben - das heißt, wenn man will, alle Features von XML und gleichzeitig alle Features von »Tag Soup«.

Aber genau das macht (fast) niemand: Kein XHTML-Autor beachtet grundlegende XML-Regeln oder die Kompatibilitätsrichtlinien beim Schreiben von XHTML-als-text/html. Wohlgeformtheit und Validität kann sowieso niemand hundertprozentig garantieren.

Das W3C weiß darauf keine Antwort, stattdessen lässt man die Linie, die man langjährig aufgebaut hat, in sich zusammenfallen. Das ist in dem Fall besonders hohl, weil XHTML 1.1 strukturell nie auf HTML-Kompatibilität ausgelegt war, im Gegenteil. Durch das Wegfallen einiger Attribute sowie Änderungen im Kleinen kann ein XHTML-1.1-Dokument auch überhaupt nicht vollständig »HTML-kompatibel« sein. Es hatte schon Gründe, warum das W3C vorher davon abgeraten hat, XHTML 1.1 einfach mal als HTML-Tag-Soup auszuliefern. Ohne XML-Features ist XHTML 1.1 wertlos, der ganze Effekt von XHTML Modularization und XHTML 1.1 war gerade derjenige des konsequenten XML-Einsatzes. Warum man das ganze dann auch noch unter umgekehrten Vorzeichen neu auflegen will, ist mir ein Rätsel.

Andererseits liegt der Schwerpunkt von XHTML 1.1 darauf, XHTML über die XHTML-Modularisierung und dessen XML-Schemas zu definieren. Bei dieser hat sich aber leider seit einem Working Draft im Juli letzten Jahres nichts getan - wenn ich das richtig sehe, arbeitet der XHTML-1.1-WD mit eigens angepassten Schema-Dateien. Wenn das W3C also völlig abgeschrieben hat, dass XHTML in Browsern und anderen User-Agents als XHTML verarbeitet wird, bleibt ohnehin nur noch die Validierung gegen das Schema sowie die Verarbeitung durch Autorenprogramme. Gut, genau dafür gibt es schon seit Jahren XHTML 1.0, das im Gegensatz zu XHTML 1.1 immer für den Hybrideinsatz gedacht war.

Mathias

[frankx]

Hellihello molily,

Aber genau das macht (fast) niemand: Kein XHTML-Autor beachtet grundlegende XML-Regeln oder die Kompatibilitätsrichtlinien beim Schreiben von XHTML-als-text/html. Wohlgeformtheit und Validität kann sowieso niemand hundertprozentig garantieren.

Zwar ist mir einleuchtend wenn es heißt, XML sei für die Datenspeicherung und (X)HTML für die Datenansicht. Intuitiv denke ich aber, dass Speicherung und Anzeige durch XHTML doch gut zusammen gehen. Und zwar in erster Linie aus "Autoren"-Sicht, denn ich mach mir schlicht zunutze, dass sich meine Datenbank in XML sich direkt  als HTML/mit CSS anschauen lässt.

Somit wäre es ja erst der zweite Schritt, wenn ich mich darüber freute, dass "fremde" Seiten auch der Art auslesbar wären für automatisiertes Suchen/Auslesen.

Oder übersehe ich da was grundsätzlich oder denk in die falsche Richtung oder hat das nichts mit dem Thema zu tun?

Gruß,

frankx

[Cybaer]

Hi,

Oder übersehe ich da was grundsätzlich oder denk in die falsche Richtung oder hat das nichts mit dem Thema zu tun?

Wenn ich XML-"Roh"-Daten direkt angezeigt bekommen möchte, dann mache ich das. Ich sehe nicht, wozu da der Umweg über XHTML notwendig oder auch nur hilfreich sein soll - außer vielleicht, daß ich für die XML-Datei ein eigenes Stylesheet benötige, während das "Default-Stylesheet" bei XHTML schon existiert. Aber Flexibilität zugunsten von etwas (vordergründiger!) Bequemlichkeit aufzugeben, ist IMHO bei diesem Thema nicht unbedingt sinnvoll ...

... eher kontraproduktiv.

Gruß, Cybaer

[frankx]

Hellihello Cybaer,

Aber Flexibilität zugunsten von etwas (vordergründiger!) Bequemlichkeit aufzugeben, ist IMHO bei diesem Thema nicht unbedingt sinnvoll ...

... eher kontraproduktiv.

Offenbar fehlt mir dann doch ein Grundverständnis für XHTML. Bisher hatte ich immer vermutet, dass Datenspeicherung und Datenansicht (zzgl. CCS) hier sozusagen verschmelzen könnten. Dass man statt einem XML-Dokument zur Speicherung und einem HTML-Dokument zur Ansicht eben nur noch ein Dokument, nämlich ein XHTML-Dokument hätte. Dem scheint aber nicht so zu sein.

Dank und Gruß,

frankx

[Cybaer]

Hi,

Offenbar fehlt mir dann doch ein Grundverständnis für XHTML.

XHTML ist HTML nach XML-Spezifikation.

XML läßt mir freie Kontrolle über die Elemente, während XHTML mir bereits vordefinierte Elemente zur Verfügung stellt.

Dass man statt einem XML-Dokument zur Speicherung und einem HTML-Dokument zur Ansicht eben nur noch ein Dokument, nämlich ein XHTML-Dokument hätte.

Das ist unsinnig.

Du hast ein (perfekt auf deine Bedürfnisse passendes und maschinell verarbeitbares) XML-"Dokument", und erstellst daraus in Echtzeit das Ausgabeformat, das der Client benötigt/anfordert. Das kann dann XHTML sein, HTML, WML, ...

Gruß, Cybaer

[frankx]

Hellihello Cybaer,

XML läßt mir freie Kontrolle über die Elemente, während XHTML mir bereits vordefinierte Elemente zur Verfügung stellt.

Ja. Nun dachte ich halt, wenn ich ein kleines (wirklich kleines) CMS hätte zum Beispiel, in dem Absätze und Überschriften eingefügt, gelöscht, bearbeitet werden könnten, dann könnte ich doch direkt im XTHML rumwurschteln und mir den Schritt, ein extra Ausgabeformat zu erstellen (via PHP XSLT) ersparen. Das macht bestimmt nur in eingeschränktem Rahmen Sinn - wenn überhaupt.

Du hast ein (perfekt auf deine Bedürfnisse passendes und maschinell verarbeitbares) XML-"Dokument", und erstellst daraus in Echtzeit das Ausgabeformat, das der Client benötigt/anfordert. Das kann dann XHTML sein, HTML, WML, ...

Warum, vielleicht komm ich so dem Verständnis näher, würde ich mich bei einer Ausgabe denn für XHTML (1.0) statt für HTML entscheiden? (1.1 ist ja dann wohl wegen Ruby-Annotations eine andere Baustelle).

Dank und Gruß,

frankx

[Cybaer]

Hi,

Nun dachte ich halt, wenn ich ein kleines (wirklich kleines) CMS hätte zum Beispiel,

Ja, wenn meine Oma Räder hätt' ... ;)

Man kann seine handvoll Seiten auch mit Frontpage-HTML ins Web stellen ... >;->

in dem Absätze und Überschriften eingefügt, gelöscht, bearbeitet werden könnten, dann könnte ich doch direkt im XTHML rumwurschteln und mir den Schritt, ein extra Ausgabeformat zu erstellen (via PHP XSLT) ersparen. Das macht bestimmt nur in eingeschränktem Rahmen Sinn - wenn überhaupt.

Niemand wird XHTML verwenden, um seine Daten zukunftssicher und portabel zu verwalten. Dafür nimmt man SGML oder jetzt XML.

Wer so wenig Daten hat, daß er sie nicht managen muß, für den stellt sich das Problem natürlich nicht ... =;-)

Warum, vielleicht komm ich so dem Verständnis näher, würde ich mich bei einer Ausgabe denn für XHTML (1.0) statt für HTML entscheiden?

Damit ich mich "Top of the Klops" fühlen, und ein schickes "XHTML strict"-Bepperl auf meine Homepage machen kann

XHTML war schlicht als Nachfolger für HTML gedacht (aus verschiedenen Gründen), und das 3WC hat (mittlerweile) gemerkt, daß die (ursprünglich explizit gewollte) Fehlertoleranz von HTML bei Otto-Normalautor so gut angekommen ist (was Wunder), daß ihre tollen (=praxisfernen) Ideen praktisch gefloppt sind. Und da ist XHTML halt nicht die einzige ...

Gruß, Cybaer

[frankx]

Hellihello Cybaer,

richtig ist aber, dass PHP XHTML-Inhalte mit seinen DOMFunktionen und auch mit SimpleXML direkt auslesen und bearbeiten kann und dass alle(?) Browser XHTML genauso gut verstehen wie "normales" HTML?

Dank und Gruß,

frankx

[Cybaer]

Hi,

richtig ist aber, dass PHP XHTML-Inhalte mit seinen DOMFunktionen und auch mit SimpleXML direkt auslesen und bearbeiten kann

Yep.

dass alle(?) Browser XHTML genauso gut verstehen wie "normales" HTML?

Nein.

Gruß, Cybaer

[Robert Bienert]

Moin!

Warum, vielleicht komm ich so dem Verständnis näher, würde ich mich bei einer Ausgabe denn für XHTML (1.0) statt für HTML entscheiden?

Damit ich mich "Top of the Klops" fühlen, und ein schickes "XHTML strict"-Bepperl auf meine Homepage machen kann

Oder um z.B. ein paar nette XML-Features nutzen zu können, beispielsweise direktes Einbetten von SVG, MathML oder RDF.

XHTML war schlicht als Nachfolger für HTML gedacht (aus verschiedenen Gründen), und das 3WC hat (mittlerweile) gemerkt, daß die (ursprünglich explizit gewollte) Fehlertoleranz von HTML bei Otto-Normalautor so gut angekommen ist (was Wunder), daß ihre tollen (=praxisfernen) Ideen praktisch gefloppt sind. Und da ist XHTML halt nicht die einzige ...

Die Ideen des W3C (3WC ein „freudscher Verschreiber“?) sind nicht praxisfern, sondern höchstens zu abstrakt für Otto Normal. Aber für forgeschrittene Anwendungen sind so Dinge wie XForms, XLink, XHTML 1.1 uvm. ausgesprochen praktisch.

Viele Grüße,
Robert

[Cybaer]

Hi,

Oder um z.B. ein paar nette XML-Features nutzen zu können, beispielsweise direktes Einbetten von SVG, MathML oder RDF.

Darüber reden wir, wenn die marktüblichen Browser das auch unterstützen.

Die Ideen des W3C (3WC ein „freudscher Verschreiber“?) ...

Nein - pure, boshafte Absicht. >:->

... sind nicht praxisfern, ...

Sicher nicht alle - aber hinreichend genug, um sich darüber Gedanken zu machen.

Warum z.B. "floppt" das (an sich gute) SVG, während die einzigen "modernen" Browserhersteller jetzt auch noch angefangen haben, CANVAS zu implementieren?

Wieso wurde nichts aus DOM Load & Save, aber alle stürzten sich aufs proprietäre XMLHttpRequest.

Etc. etc. ...

sondern höchstens zu abstrakt für Otto Normal.

Aufwachen! Das WWW ist *ausdrücklich* für den Otto-Normal-Autor gemacht worden.

Aber für forgeschrittene Anwendungen sind so Dinge wie XForms, XLink, XHTML 1.1 uvm. ausgesprochen praktisch.

Den Reiz des Webs macht halt auch aus, daß es nicht nru aus fortgeschrittenen Anwendungen besteht. Zu dumm, wenn man dann das "Primitiv-Werkzeug" einmotten möchte, und mit dem Entwurf von Luxus-Werkzeug glänzt, daß die Masse nicht will, nicht versteht und auch nicht braucht - sofern die Werkzeug-Hersteller (=Browserprogrammierer) es überhaupt anbieten ...

Gruß, Cybaer

[Mathias Brodala]

Hallo Cybaer.

Warum z.B. "floppt" das (an sich gute) SVG, […]

Wie kommst du auf diese Idee? SVG ist recht erfolgreich und verbreitet sich immer weiter. Nur nicht zwangsläufig da, wo man es erwarten würde. Programmicons sowie ganze Benutzeroberflächen für Programme werden mittlerweile per SVG erstellt.

Einen schönen Mittwoch noch.

Gruß, Mathias

[Cybaer]

Hi,

Wie kommst du auf diese Idee? SVG ist recht erfolgreich und verbreitet sich immer weiter.

Das gilt auch für XML. ;)

Ne, ich bezog das, s. "CANVAS", nur auf die Browser.

Und ggf. auf die Problematik, daß Adobe zu SVG in Konkurrenz geht ...

Gruß, Cybaer

[Mathias Brodala]

Hallo Cybaer.

Wie kommst du auf diese Idee? SVG ist recht erfolgreich und verbreitet sich immer weiter.

Das gilt auch für XML. ;)

Aber nicht so sehr wie SVG!!11einself

Ne, ich bezog das, s. "CANVAS", nur auf die Browser.

Ich wüsste auch gar nicht, ob und wie man in SVG freihändig zeichnen könnte.

Einen schönen Mittwoch noch.

Gruß, Mathias

[Robert Bienert]

Moin!

Ich wüsste auch gar nicht, ob und wie man in SVG freihändig zeichnen könnte.

Von Hand coden ;-) Ne, geht das mit <path>?

Viele Grüße,
Robert

[Cybaer]

Hi,

Wie kommst du auf diese Idee? SVG ist recht erfolgreich und verbreitet sich immer weiter.
Das gilt auch für XML. ;)
Aber nicht so sehr wie SVG!!11einself

?

Ich wüsste auch gar nicht, ob und wie man in SVG freihändig zeichnen könnte.

Googel ggf. einfach mal nach "dynamische SVG Grafiken".

Gruß, Cybaer

[Robert Bienert]

Moin!

Oder um z.B. ein paar nette XML-Features nutzen zu können, beispielsweise direktes Einbetten von SVG, MathML oder RDF.

Darüber reden wir, wenn die marktüblichen Browser das auch unterstützen.

Ich bezeichne die Gecko-Rendering-Engine als marktüblich. Und es gibt in der Entwicklergruppe um das marktübliche WebKit von Apple Ideen, zumindest SVG relativ zügig zu implementieren (die SVG-Unterstützung ist momentan noch experimentell).

Warum z.B. "floppt" das (an sich gute) SVG, während die einzigen "modernen" Browserhersteller jetzt auch noch angefangen haben, CANVAS zu implementieren?

Ich kenne mich mit Grafikprogrammierung nicht aus, aber wahrscheinlich ist den Browserherstellern SVG für „ein bisschen Vektorgrafik“ „zu groß“.

sondern höchstens zu abstrakt für Otto Normal.

Aufwachen! Das WWW ist *ausdrücklich* für den Otto-Normal-Autor gemacht worden.

Das merkt man, wenn man deren Spezifikationen liest >:-> (Zum Glück für SELFHTML ;-) )

Aber für forgeschrittene Anwendungen sind so Dinge wie XForms, XLink, XHTML 1.1 uvm. ausgesprochen praktisch.

Den Reiz des Webs macht halt auch aus, daß es nicht nru aus fortgeschrittenen Anwendungen besteht. Zu dumm, wenn man dann das "Primitiv-Werkzeug" einmotten möchte, und mit dem Entwurf von Luxus-Werkzeug glänzt, daß die Masse nicht will, nicht versteht und auch nicht braucht - sofern die Werkzeug-Hersteller (=Browserprogrammierer) es überhaupt anbieten ...

OK, XLink wird Otto Normal wahrscheinlich nie interessieren, aber die Änderung mit XHTML 2 finde ich schon sehr schön – auch wenn Otto Normal mit Frontpage, Word oder einem anderen „Programm“ vielleicht eher physisch auszeichnet – wofür auch HTML im Übrigen nie gedacht war. Und XForms ist halt die Frage, ob man es braucht oder nicht. Natürlich ist es dahinter stehende Model-View-Control-Konzept erst einmal ein großes Stück zum Lernen, aber dafür ist die Lernkurve hinterher sehr viel flacher, Formulare können leichter angepasst und verändert werden, ganz abgesehen vom Einsatz auf anderen Medien (z.B. Mobiltelefonen).

Vieles ist IMHO auch eine Sache der „Werbung“.

Viele Grüße,
Robert

[Cybaer]

Hi,

Ich bezeichne die Gecko-Rendering-Engine als marktüblich.

Und ich den Browser, der immer noch den größten Anteil ausmacht.

Ich kenne mich mit Grafikprogrammierung nicht aus, aber wahrscheinlich ist den Browserherstellern SVG für „ein bisschen Vektorgrafik“ „zu groß“.

Ich weiß es auch nicht - aber wenn's so wäre, dann ist es schon wieder typisch 3WC: Gute Ideen, aber einfacheres setzt sich durch (man denke auch an DOM vs. innerHTML).

Aufwachen! Das WWW ist *ausdrücklich* für den Otto-Normal-Autor gemacht worden.
Das merkt man, wenn man deren Spezifikationen liest >:->

LOL - aber auch HTML hat ja mal klein angefangen ... ;)

Vieles ist IMHO auch eine Sache der „Werbung“.

Und der Tools, die einem zur Verfügung stehen, und alles quasi automatisch für den Newbie erledigen ... :-)

Gruß, Cybaer

[Robert Bienert]

Moin!

Ich kenne mich mit Grafikprogrammierung nicht aus, aber wahrscheinlich ist den Browserherstellern SVG für „ein bisschen Vektorgrafik“ „zu groß“.

Ich weiß es auch nicht - aber wenn's so wäre, dann ist es schon wieder typisch 3WC: Gute Ideen, aber einfacheres setzt sich durch (man denke auch an DOM vs. innerHTML).

Naja, <canvas> und SVG sind IMHO schon zwei paar Schuhe: Ein Canvas ist doch AFAIK eine Zeichenoberfläche in einer GUI, während SVG ein (Vektor-) Grafikformat ist. Im Sinne von „Web _Applications_“ ist canvas dann schon logisch. Aber wenn man eh Vektorgrafiken in Browsern ermöglichen will – was ich sehr praktisch fände, Pixelgrafik ist häufig suboptimal – würde SVG an sich ja schon reichen.

Vieles ist IMHO auch eine Sache der „Werbung“.

Und der Tools, die einem zur Verfügung stehen, und alles quasi automatisch für den Newbie erledigen ... :-)

Dann muss der Newbie nur mal seinen Horizont ein klitzekleines bisschen erweitern: OpenOffice.org kann MathML, SVG, XHTML+MathML, Inkscape kann SVG sogar richtig gut. Wie siehts mit Corel und Adobe aus?

Viele Grüße,
Robert

[Cybaer]

Hi,

Naja, <canvas> und SVG sind IMHO schon zwei paar Schuhe: Ein Canvas ist doch AFAIK eine Zeichenoberfläche in einer GUI, während SVG ein (Vektor-) Grafikformat ist.

Ich würde nicht behaupten, den vollen Durchblick zu haben, aber so spontan sehe ich eigentlich nicht, daß mit CANVAS (egal ob "statisch" oder "dynamisch" etwas ginge, was mit SVG nicht gehen würde).

Interessant wird *vielleicht* dereinst mal er 3D-Teil ...

Pixelgrafik ist häufig suboptimal – würde SVG an sich ja schon reichen.

Wie wahr, wie wahr ...

Wie siehts mit Corel und Adobe aus?

Daß Adobe *das* SVG-PlugIn zurückgezogen hat, deutet wohl darauf hin, daß man nach dem Kauf von Macromedia die Zukunft wohl eher in seinem Flash sieht, bzw. sehen möchte ... :-(

Gruß, Cybaer

[Robert Bienert]

Moin!

Ich würde nicht behaupten, den vollen Durchblick zu haben, aber so spontan sehe ich eigentlich nicht, daß mit CANVAS (egal ob "statisch" oder "dynamisch" etwas ginge, was mit SVG nicht gehen würde).

Ganz im Gegenteil: Mit SVG geht vieles einfacher, was man sonst manuell auf einem <canvas> zeichnen müsste.

Interessant wird *vielleicht* dereinst mal er 3D-Teil ...

Achja, VRML bzw. X3D …

Wie siehts mit Corel und Adobe aus?

Daß Adobe *das* SVG-PlugIn zurückgezogen hat, deutet wohl darauf hin, daß man nach dem Kauf von Macromedia die Zukunft wohl eher in seinem Flash sieht, bzw. sehen möchte ... :-(

Und wieder ein Grund, auf Gecko umzusteigen ;-) Wobei mir nicht ganz klar ist, wieso SVG in Konkurrenz zu Flash stehen soll – wäre da nicht eher SMIL ein Kandidat?

Viele Grüße,
Robert

[Cybaer]

Hi,

Ganz im Gegenteil: Mit SVG geht vieles einfacher, was man sonst manuell auf einem <canvas> zeichnen müsste.

Sehe ich auch so.

Interessant wird *vielleicht* dereinst mal er 3D-Teil ...
Achja, VRML bzw. X3D …

Ja - vermutlich auch schlechter. Allerdings bis die marktüblichen Browser nativ X3D unterstützen werden (falls ich das noch erleben sollte), haben wir schon Holodecks ... >;->

Wobei mir nicht ganz klar ist, wieso SVG in Konkurrenz zu Flash stehen soll

Flash beherrscht Vektorgrafik.

– wäre da nicht eher SMIL ein Kandidat?

Auch das. Und noch viel mehr. Schließlich kann Flash eigentlich alles, nur viel besser, und ist die göttliche Offenbarung für alle Content-Anbieter!

So lautet jedenfalls IIRC sinngemäß die Werbu^W Produktinformation ... >;->

...  Stichwort: Rich-Internet-Anwendungen - da kräuseln sich mir ja heute noch die Zehennägel hoch. =:->

Gruß, Cybaer

[Robert Bienert]

Moin!

Ja - vermutlich auch schlechter. Allerdings bis die marktüblichen Browser nativ X3D unterstützen werden (falls ich das noch erleben sollte), haben wir schon Holodecks ... >;->

Da lohnt sich ja das Warten ;-)

Wobei mir nicht ganz klar ist, wieso SVG in Konkurrenz zu Flash stehen soll

Flash beherrscht Vektorgrafik.

Wer macht schon statische Vektorgrafiken mit Flash?

– wäre da nicht eher SMIL ein Kandidat?

Auch das. Und noch viel mehr. Schließlich kann Flash eigentlich alles, nur viel besser, und ist die göttliche Offenbarung für alle Content-Anbieter!

So lautet jedenfalls IIRC sinngemäß die Werbu^W Produktinformation ... >;->

Flash benötigt darüber hinaus aber ein Plugin beim Client und kostet Geld, welches ich als Student nicht habe – und OpenOffice.org, Inkscape sowie Blender3D kosten kein Geld. Ganz abgesehen davon, dass Flash proprietär ist und ich nie weiß, ob es abwärtskompatibel ist oder was passiert, sollte Macromedia/Adobe den Laden dicht machen.

...  Stichwort: Rich-Internet-Anwendungen - da kräuseln sich mir ja heute noch die Zehennägel hoch. =:->

Ne, lieber mit Internet-Anwendungen reich werden ;-)

Viele Grüße,
Robert

[Cybaer]

Hi,

Wobei mir nicht ganz klar ist, wieso SVG in Konkurrenz zu Flash stehen soll
Flash beherrscht Vektorgrafik.
Wer macht schon statische Vektorgrafiken mit Flash?

Diejenigen, die VG brauchen/haben möchten, und dafür eine *möglichst breite* Basis suchen (zumal nach dem Einstampfen von Adobes SVG-PlugIn)?

Und da die Flasher davon ausgehen/auszugehen scheinen, daß ohnehin (fast) jeder Flash hat (oder haben kann), was man (momentan) von SVG nicht sagen kann ... Bingo! :-/

Flash benötigt darüber hinaus aber ein Plugin beim Client und kostet Geld, welches ich als Student nicht habe

Na ja, es gibt ja IIRC mittlerweile auch das eine oder andere kostenlose Tools zur Flash-Erstellung. Aber daß der Sinn von proprietären Formaten durchaus darin begründet ist, Geld damit zu verdienen, versteht sich doch wohl von selbst, oder?! =;->

Davon abgesehen möchte Adobe (mittlerweile) ja durchaus seine proprietären Standards standardisieren lassen (nein, über diese "Chuzpe" bitte keine Diskussion! =;-<).

...  Stichwort: Rich-Internet-Anwendungen - da kräuseln sich mir ja heute noch die Zehennägel hoch. =:->
Ne, lieber mit Internet-Anwendungen reich werden ;-)

LOL - aber eben noch armer Student sein, was? ;-)

Gruß, Cybaer

[Robert Bienert]

Moin!

Wobei mir nicht ganz klar ist, wieso SVG in Konkurrenz zu Flash stehen soll
Flash beherrscht Vektorgrafik.
Wer macht schon statische Vektorgrafiken mit Flash?

Diejenigen, die VG brauchen/haben möchten, und dafür eine *möglichst breite* Basis suchen (zumal nach dem Einstampfen von Adobes SVG-PlugIn)?

Das passt für mich trotzdem irgendwie nicht zusammen. (Solche Diskussionen liefern immer mehr Argumente, Firefox zu benutzen ;-) )

Flash benötigt darüber hinaus aber ein Plugin beim Client und kostet Geld, welches ich als Student nicht habe

Na ja, es gibt ja IIRC mittlerweile auch das eine oder andere kostenlose Tools zur Flash-Erstellung.

Wie denn das eigentlich? Ist Flash denn als Standard veröffentlicht oder womit bezahlen die Hersteller kostenloser Tools eventuelle Lizenzen?

Aber daß der Sinn von proprietären Formaten durchaus darin begründet ist, Geld damit zu verdienen, versteht sich doch wohl von selbst, oder?! =;->

Deshalb mag ich Proprietäres nicht so. Der Vorteil an offenen Formaten ist, dass der Konkurrenzkampf zwischen den Programmen ausgetragen wird, d.h. Features, Bedienung, Ergonomie, …

...  Stichwort: Rich-Internet-Anwendungen - da kräuseln sich mir ja heute noch die Zehennägel hoch. =:->
Ne, lieber mit Internet-Anwendungen reich werden ;-)

LOL - aber eben noch armer Student sein, was? ;-)

Man wird doch wohl noch träumen dürfen!

Viele Grüße,
Robert

[molily]

Hallo,

Warum z.B. "floppt" das (an sich gute) SVG, während die einzigen "modernen" Browserhersteller jetzt auch noch angefangen haben, CANVAS zu implementieren?

Ist eine seltsame Frage, weil die Browser, die sich auf Canvas stürzen auch SVG nativ können bzw. danach streben. Ich halte beides im Web bisher für marginal und das würde ich primär weniger an den Techniken selbst festmachen.

Wieso wurde nichts aus DOM Load & Save, aber alle stürzten sich aufs proprietäre XMLHttpRequest.

Vielleicht hat das wenig mit DOM L&S zu tun, sondern einfach mit der Marktmacht von Microsoft, die eine Technik durchgedrückt und etabliert hat, sodass andere nur nachzogen und gehorsamst die proprietäre Technik implementierten. (Ich glaube es nicht, aber möglich ist es ebenso bzw. ein Faktor.)

Mathias

[Cybaer]

Hi,

Ist eine seltsame Frage, weil die Browser, die sich auf Canvas stürzen auch SVG nativ können bzw. danach streben.

Ist die Frage seltsam? Dann formulier ich sie um: Warum erfinden Browserhersteller eine neue (erstmal) proprietäre Technik, bevor die standardisierte Technik noch gar nicht (bzw. nicht nativ und nur rudimentär) implementiert ist?

Ja, wenn das MS machen würde. Aber Open-Source-Vertreter wie Mozilla?

Ich weiß es nicht, aber interessieren würde es mich schon - und dann kann die Frage danach auch nicht seltsam sein, oder? =;-)

Ich halte beides im Web bisher für marginal

Sicher. Was aber IMHO eher an der mangelnden Unterstützung liegt.

Anderes Beispiel: VRML (kennt das noch jemand? ;->==) ist "gefloppt". Hach, was habe ich mich darauf gefreut. Egal, jetzt ist Second Life angesagt und nun wird halt *das* ein Erfolg (und ich bin mir sehr sicher, daß jedweder SL-Hype absolut berechtigt ist). Was wäre das geil (gewesen), das Web (und seine Welten und Anwendungen) à la SL in jedem Browser zur Verfügung zu haben ...

Vielleicht hat das wenig mit DOM L&S zu tun, sondern einfach mit der Marktmacht von Microsoft, die eine Technik durchgedrückt und etabliert hat, sodass andere nur nachzogen und gehorsamst die proprietäre Technik implementierten. (Ich glaube es nicht, aber möglich ist es ebenso bzw. ein Faktor.)

Mag ein Faktor sein. Aber Fakt ist doch, daß "Ajax" (wenigstens prinzipiell) auch ohne XMLHttpRequest funktionieren würde (nur eben nicht mit XML sondern mit HTML - halt via (I)Frames und mit etwas weniger Komfort). Und der Hype entstand erst, nachdem *alle* (relevanten) Browserhersteller diese Technik unterstützt haben.

Gruß, Cybaer

[Robert Bienert]

Moin!

Ist eine seltsame Frage, weil die Browser, die sich auf Canvas stürzen auch SVG nativ können bzw. danach streben.

Ist die Frage seltsam? Dann formulier ich sie um: Warum erfinden Browserhersteller eine neue (erstmal) proprietäre Technik, bevor die standardisierte Technik noch gar nicht (bzw. nicht nativ und nur rudimentär) implementiert ist?

Ja, wenn das MS machen würde. Aber Open-Source-Vertreter wie Mozilla?

Widerspruch, Geckos können mittlerweile SVG von Haus aus.

Viele Grüße,
Robert

[Cybaer]

Hi,

Ja, wenn das MS machen würde. Aber Open-Source-Vertreter wie Mozilla?
Widerspruch, Geckos können mittlerweile SVG von Haus aus.

Die waren ja aber auch die ersten (oder nach Safari zumindest die knapp zweiten?), die CANVAS implementiert hatten.

Gruß, Cybaer

[Orlando]

Geckos können mittlerweile SVG von Haus aus.

Die waren ja aber auch die ersten (oder nach Safari zumindest die knapp zweiten?), die CANVAS implementiert hatten.

Gecko hat sich viele gute Sachen von WebKit abgeschaut, so auch <canvas>. Mist erfindet man lieber selbst. >;-) Opera 9 kennt es ebenfalls.

3D Walker finde ich schon ziemlich geil.

Roland

[Tim Tepaße]

Hallo Cybaer,

Ist eine seltsame Frage, weil die Browser, die sich auf Canvas stürzen auch SVG nativ können bzw. danach streben.
Ist die Frage seltsam? Dann formulier ich sie um: Warum erfinden Browserhersteller eine neue (erstmal) proprietäre Technik, bevor die standardisierte Technik noch gar nicht (bzw. nicht nativ und nur rudimentär) implementiert ist?

Ich denke, das ist eine Mischung aus zum einem anderen Anwendungsbereich und zum anderen Aufwandseinschätzung. SVG, selbst in seinen kleineren („Tiny“) Profilen, ist nunmal ein riesiges Monster von Spezifikation, das dauert halt, das richtig zu implementieren.

Und jetzt wirf mal einen Blick dahin, woher <canvas> ursprünglich kommt. Apples Interesse lag im Dashboard. Aus Apples Sicht sind Widgets keine Webseiten, sondern kleine Programme, die nur deswegen in HTML, CSS und JS implementiert sind, weil die Techniken zum einen dank WebKit bereitstehen, zum anderen weil es haufenweise Leute gibt, die sich damit auskennen, nämlich die Pixelschubser des Webs. Aber Widgets laufen prinzipiell erst unter "kleine Programme" und nicht unter "Webseiten".

Aus dieser Sicht rechtfertigen sich auch die proprietären Erweiterungen Apples, schließlich kommen diese kleinen Programme nur in Apples Umgebung zum Tragen. Das Widget-Objekt ist massgeschneidert auf Apples Dashboard-Umgebung und nicht irgendein abstrahiertes Wolkenkuckucksobjekt. Und <canvas> macht nicht weiter, als Zugriff in Javascript auf die prozeduralen 2D-APIs (Quartz) zum Malen auf den Bildschirm zu geben, die in OS X ja eh existieren.

Hätte Apple erst eine komplette SVG-Unterstützung programmieren sollen, um etwas mehr grafische Effekte? In einer idealen Welt vielleicht, ja. Aber das dauert und irgendwann muss man sein Produkt ja zum Kunden bringen. Zum Vergleich: Meines Wissens ist das Nebenprojekt „SVG-Unterstützung in WebKit“ jetzt schon seit zwei Jahren in der Mache. Ich kann gut verstehen, wenn man da lieber erst mal zu dem „simpelsten Ding, das funktioniert“ greift, anstatt zu warten und ewig lang kein Produkt auszulieferen.

Tim

[Cybaer]

Hi,

Ich kann gut verstehen, wenn man da lieber erst mal zu dem „simpelsten Ding, das funktioniert“ greift, anstatt zu warten und ewig lang kein Produkt auszulieferen.

Hmm, ja, da hast Du wohl sicher recht!

Allerdings: Warum hat das Mozilla auch gleich implementiert?

Dafür fällt mir dann eigentlich nur eine Erklärung ein: Weil es da war!? Getreu dem Motto: Apple hat's gewollt, Apple hat's gemacht, die Sourcen sind frei, die Anpassungen minimal (von einer OS-X-API auf eine Windows- bzw. X-API) also machen wir es doch mal nebenbei?

Gruß, Cybaer

[molily]

Hallo,

Dass man statt einem XML-Dokument zur Speicherung und einem HTML-Dokument zur Ansicht eben nur noch ein Dokument, nämlich ein XHTML-Dokument hätte.

Das ist unsinnig.

Wieso soll das unsinnig sein? Genau dahin geht die Entwicklung, denk mal an Mikroformate.

Du hast ein (perfekt auf deine Bedürfnisse passendes und maschinell verarbeitbares) XML-"Dokument", und erstellst daraus in Echtzeit das Ausgabeformat, das der Client benötigt/anfordert. Das kann dann XHTML sein, HTML, WML, ...

Äh, wenn ich strukturierte Texte und sonstige Informationen (siehe Mikroformate) speichern will, wieso soll ich dann nicht XHTML verwenden, wo ich gleich tausende fertige Möglichkeiten der Verarbeitung habe, wieso soll ich da irgendein neues XML-Derivat erfinden, wo ich doch alles mit (X)HTML machen kann?

Mathias

[frankx]

Hellihello Mathias,

Dass man statt einem XML-Dokument zur Speicherung und einem HTML-Dokument zur Ansicht eben nur noch ein Dokument, nämlich ein XHTML-Dokument hätte.

Das ist unsinnig.

Wieso soll das unsinnig sein? Genau dahin geht die Entwicklung, denk mal an Mikroformate.

Dank für das Stichwort. Bin ich auch gleich fündig geworden: Semantisches XHTML leicht gemacht:

"Ziel der Mikroformatersteller ist es, XHTML-Dokumente durch ein paar Ergänzungen mit mehr Informationen zu versehen. Das Ganze soll für Menschen wie Maschinen lesbar sein. Wie sich gleich erweisen dürfte, haben Anwender Gewinn davon, wenn die Rechner mit den Daten etwas anfangen können.

Tantek Çelik und andere haben auf microformats.org eine Reihe von Spezifikationen zusammengetragen, die die XHTML-Attribute class, rel und rev nutzen, um Metainformationen in Elementen unterzubringen. class können Webautoren für fast alle HTML-Elemente verwenden, rel und rev in den Elementen a und link. Kein Wunder, dass Mikroformate überwiegend class als Attribut nutzen."

Damit ist doch auch der OP beantwortet, oder?

Dank und Gruß,

frankx

[Cybaer]

Hi,

Damit ist doch auch der OP beantwortet, oder?

Kommt drauf an, wie Du sie beantwortest! ;-)

Mikroformate bedürfen keines X. Da reicht HTML bereits aus. Insofern ist XHTML wirklich überflüssig.

"Ernsthafte" Datenverarbeitung wird weiter SGML bzw. jetzt und in Zukunft XML verwenden. Da ist dann XHTML nur die Kirsche auf dem Kuchen, die man dort plaziert oder eben nicht ...

Gruß, Cybaer

[frankx]

Hellihello Cybaer,

"Ernsthafte" Datenverarbeitung wird weiter SGML bzw. jetzt und in Zukunft XML verwenden. Da ist dann XHTML nur die Kirsche auf dem Kuchen, die man dort plaziert oder eben nicht ...

Da wäre dann die Frage wohl: machen Kirschen auf dem Kuchen Sinn, oder?

Dank und Gruß,

frankx

[Cybaer]

Hi,

Da wäre dann die Frage wohl: machen Kirschen auf dem Kuchen Sinn, oder?

Das kann man natürlich nicht allgemein beantworten. Nicht jeder mag Kirschen. Ich z.B. mag echte Kirschen (sowohl süße wie auch saure), aber keine "Deko"-Kirschen. Vielleicht gibt es Menschen mit Kirsch-Allergie? Sicherlich gibt es auch Steinobst-Fundamentalisten. Und last but not least: Für einen Kirschkern-Weitspucker ist die Kirsche ja ohnehin nur Mittel zum Zweck ... ;-))

Gruß, Cybaer

[frankx]

Hellihello Cybaer,

Das kann man natürlich nicht allgemein beantworten. Nicht jeder mag Kirschen. Ich z.B. mag echte Kirschen (sowohl süße wie auch saure), aber keine "Deko"-Kirschen. Vielleicht gibt es Menschen mit Kirsch-Allergie? Sicherlich gibt es auch Steinobst-Fundamentalisten. Und last but not least: Für einen Kirschkern-Weitspucker ist die Kirsche ja ohnehin nur Mittel zum Zweck ... ;-))

Du vergaßest getrocknete Kirschen. Hatte ich letztlich zum ersten Mal, aus der Schweiz und biologisch. Auch sehr schön.

Dank und Gruß,

frankx

[Cybaer]

Hi,

Du vergaßest getrocknete Kirschen. Hatte ich letztlich zum ersten Mal, aus der Schweiz und biologisch. Auch sehr schön.

Ich wußte gar nicht, daß es so etwas gibt! =:-) Sind das dann "rote Rosinen mit Kirschgeschmack"? ;)

Gruß, Cybaer

[Robert Bienert]

Moin!

„Macht Sinn“ macht sprachlich keinen Sinn, es ist in gewisser Weise sinnlos, frag mal Bastian Sick ;-)

Viele Grüße,
Robert

[Johannes Zeller]

Hallo Robert,

„Macht Sinn“ macht sprachlich keinen Sinn, es ist in gewisser Weise sinnlos, frag mal Bastian Sick ;-)

Der Ausdruck »Sinn machen« mag früher vielleicht nicht gebräuchlich gewesen sein, aber heutzutage wird es dir mit Sicherheit ziemlich schwerfallen jemanden zu finden, dem dies intuitiv falsch vorkommt. Deswegen halte ich es für unsinnig, zu sagen das es sprachlich sinnlos sei.

Schöne Grüße,

Johannes

[Cybaer]

Hi,

Wieso soll das unsinnig sein? Genau dahin geht die Entwicklung, denk mal an Mikroformate.

Mikroformate sind IMHO ein (X)HTML-Workaround wg. der XML-Probleme der Browser, bzw. eine Möglichkeit verbesserter Maschinenlesbarkeit für kleinere Datenbestände (sozusagen "kleine Münze").

Kein "Daten-Manager" der bei Verstand ist, wird das als Rohformat verwenden.

Andererseits: Der IE wird ja auch genutzt - und über den ließe sich ähnliches sagen ... >;->

Äh, wenn ich strukturierte Texte und sonstige Informationen (siehe Mikroformate) speichern will, wieso soll ich dann nicht XHTML verwenden, wo ich gleich tausende fertige Möglichkeiten der Verarbeitung habe, wieso soll ich da irgendein neues XML-Derivat erfinden, wo ich doch alles mit (X)HTML machen kann?

Wieso denn "neues XML-Derivat"? XML ist XML ist XML. Ich denke schlicht an eine eigene DTD bzw. eigene Schemata.

Wenn man X(!)HTML als Ausgangspunkt für die Verwendung eigener Schemata verwenden möchte: Keine Frage, keine Probleme (also XML mit eigenem/n Schema/ta mit einem zusätzlichen XHTML-Schema).

Aber (X)HTML selbst (zumal bei geklammertem X) ist dafür, Mikroformate hin oder her, ernsthaft nicht tauglich.

Wenn man diese Aussage verschärfen möchte, dann kann man ja mal "(X)HTML" durch "HTML" ersetzen, und "XML" durch "SGML" - vielleicht wird die Intention dann klarer, weil die Diskrepanz stärker hervor tritt ...

"Generationen" von Firmen haben ihre Daten in SGML bzw. später XML gesichert. Wir reden hier über Datenvorhaltung in Geschäftsumfeld und nicht über Workarounds von HTML-Liebhabern und Hobbyseitenbastlern, die sich vielleicht im Low-Level-Bereich mal eine gute Akzeptanz erreichen werden - oder auch nicht.

Gruß, Cybaer

[Robert Bienert]

Moin!

das W3C hat einen Working Draft zur überarbeiteten (Second Edition) Version von XHTML 1.1 veröffentlicht. Eine Sache fällt dabei besonders auf: Zukünftig soll man XHTML-1.1-Dokumente ebenfalls mit dem MIME-Typ text/html versenden drüfen.

Was hat man denn damit eigentlich gewonnen? Geht das W3C davon aus, dass schlaue Browser(TM) die XML-Deklaration sowie den Namesraum erkennen und dann automatisch XML verarbeiten, während veraltete Browser(IE) Tag-Suppe löffeln?

BTW: Was macht eigentlich der MSIE, wenn man ihm XHTML als XML gibt?

Wenn ich daran denke, dass ich kaum eine Webseite, die in XHTML (1.0) geschrieben und noch dazu gültig ist, kenne, frage ich mich, ob XHTML seinen Sinn als Dokumentenformat verloren hat.

Naja, wie weit wird denn XHTML tatsächlich verarbeitet? Der IE kann es nicht, welche HTML-Editoren sind denn auch XHTML-Editoren? Und welchen konkreten Vorteil kann denn der 0815-Webautor aus XHTML ziehen?

IMHO sind die Antworten darauf gar nicht groß bekannt und HTML ist zu bekannt und verbreitet, als dass sich Otto Normal vielleicht damit beschäftigen muss. Aber in einer „XMLisierten“ Welt ist XHTML IMHO viel wichtiger als „die alte Krücke“ HTML, gerade was die Wieder- und Weiterverarbeitung betrifft, aber sieht Otto diese Vorteile?

Es gibt zwar auch jetzt schon Webseiten, die in XHTML 1.1 verfasst (manchmal sogar in Strict [sic]) und nicht gültig sind, aber wenn das W3C XHTML 1.1 nun zum "Abschuss freigibt" sehe ich keine echte Zukunft mehr für XHTML.

Die Befürchtung teile ich. Dabei war XHTML 1.1 schon wegen der „neuen Bescheidenheit“ viel versprechend.

Denn was bringt XHTML, wenn keines der Features, die es mit sich bringt genutzt werden kann, da letztendlich ohnehin alles als HTML-TagSoup geparst wird?

Genau das ist es. Außerdem bedeutet Tagsuppe doch, dass es beispielsweise mit XML-Namensräumen nicht mehr weit her ist, oder?

Dazu kommt die Arbeit an XHTML 2.0, diese scheint einerseits festgefahren zu sein. Andererseits hat sie jetzt Konkurrenz: HTML wird weiterentwickelt, vermutlich zu HTML 5.0. Dieses soll auch als XML-Dialekt verfügbar werden. Ende der XHTML-2.0-Entwicklung also?

Hoffentlich nicht! XHTML 2.0 beschränkt sich einerseits auf die Features, die eine Auszeichnungssprache für Hypertexte benötigt, bringt andererseits aber auch lang erwartete Features mit (nl, h, section). Das kann „HTML 5“ alles nicht bieten, weil es nur ein um Web2.0-Features aufgeblähtes HTML 4 ist. Meinetwegen soll es auch HTML 5 geben, wenn die Mehrheit der Webautoren es zu brauchen meint, aber ich finde es sehr schade, wenn das innovative XHTML 2 eingestampft wird.

Viele Grüße,
Robert

[Daniel unreg]

Hallo,

Was hat man denn damit eigentlich gewonnen? Geht das W3C davon aus, dass schlaue Browser(TM) die XML-Deklaration sowie den Namesraum erkennen und dann automatisch XML verarbeiten, während veraltete Browser(IE) Tag-Suppe löffeln?

Das wollte man eigentlich schon mit XHTML 1.0 erreichen, darum gibt es ja auch die HTML-Kompatibilitätsrichtlinien. Der Versuch schlug allerdings fehl. Ob heutige Browser das Dokument als XML oder Suppe verarbeiten hängt vom Media-Type ab, mit dem es versendet wird. Das allein finde ich schon eine Gegenzug zur XHTML-Bewegung.

BTW: Was macht eigentlich der MSIE, wenn man ihm XHTML als XML gibt?

Mit einem Trick werden als XML versendete XHTML Dokumente mit dem XML-Parser verarbeitet. Dazu wird dann zwar die DTD geladen, aber meines Wissens gibt es keine Vorteile bei diesem Trick.

IMHO sind die Antworten darauf gar nicht groß bekannt und HTML ist zu bekannt und verbreitet, als dass sich Otto Normal vielleicht damit beschäftigen muss.

Weil er es auch leider nicht muss. Mal schnell XHTML in den Doctype geschrieben und im Browser X klappts. Wie gesagt, das ich meiner Meinung nach der größte Rückschlag für XHTML-basierte Webseiten gewesen.

Aber auch professionellere Webautoren machen Fehler. Sieht man sich die Startseite der Tagesschau an ist diese gültiges XHTML. Eine Seite weiter kommen schon Attribute doppelt vor und vernichten die Unfehlbarkeit.
Das ist sehr wahrscheinlich ein Problem des CMS, aber hier wird (X)HTML meist nur belächelt.

Genau das ist es. Außerdem bedeutet Tagsuppe doch, dass es beispielsweise mit XML-Namensräumen nicht mehr weit her ist, oder?

Der Suppenparser kennt X(HT)ML nicht. Er sieht nur fehlerhaftes HTML (z.B. img und br mit /> oder).

Hoffentlich nicht! XHTML 2.0 beschränkt sich einerseits auf die Features, die eine Auszeichnungssprache für Hypertexte benötigt, bringt andererseits aber auch lang erwartete Features mit (nl, h, section). Das kann „HTML 5“ alles nicht bieten, weil es nur ein um Web2.0-Features aufgeblähtes HTML 4 ist. Meinetwegen soll es auch HTML 5 geben, wenn die Mehrheit der Webautoren es zu brauchen meint, aber ich finde es sehr schade, wenn das innovative XHTML 2 eingestampft wird.

Ich frage mich, wie du deine Kritik an HTML 5 begründest, denn bisher gibt es ja keine wirklichen Fakten dazu (HTML 5 ist außerdem nicht mit Web Applications 1.0 gleichzustellen). Darum hoffe ich momentan, dass die Arbeitsgruppe die guten Ideen der XHTML 2.0 Gruppe übernehmen wird. nl-Elemente und eingie andere Innovationen sind echte Killerapps.

Gruß;

[Robert Bienert]

Moin!

BTW: Was macht eigentlich der MSIE, wenn man ihm XHTML als XML gibt?

Mit einem Trick werden als XML versendete XHTML Dokumente mit dem XML-Parser verarbeitet. Dazu wird dann zwar die DTD geladen, aber meines Wissens gibt es keine Vorteile bei diesem Trick.

D.h. man müsste dem IE dann eine entsprechende CSS-Datei servieren, die ihm z.B. mitteilt, wie XHTML-Elemente angezeigt werden?

Das ist sehr wahrscheinlich ein Problem des CMS, aber hier wird (X)HTML meist nur belächelt.

Vor allem wenn man anscheinend aus dem Printbereich kommt.

Genau das ist es. Außerdem bedeutet Tagsuppe doch, dass es beispielsweise mit XML-Namensräumen nicht mehr weit her ist, oder?

Der Suppenparser kennt X(HT)ML nicht. Er sieht nur fehlerhaftes HTML (z.B. img und br mit /> oder).

Das bedeutet doch auch, dass so nette Dinge wie XHTML+MathML oder XHTML+SVG nicht möglich sind, oder?

Hoffentlich nicht! XHTML 2.0 beschränkt sich einerseits auf die Features, die eine Auszeichnungssprache für Hypertexte benötigt, bringt andererseits aber auch lang erwartete Features mit (nl, h, section). Das kann „HTML 5“ alles nicht bieten, weil es nur ein um Web2.0-Features aufgeblähtes HTML 4 ist. Meinetwegen soll es auch HTML 5 geben, wenn die Mehrheit der Webautoren es zu brauchen meint, aber ich finde es sehr schade, wenn das innovative XHTML 2 eingestampft wird.

Ich frage mich, wie du deine Kritik an HTML 5 begründest, denn bisher gibt es ja keine wirklichen Fakten dazu (HTML 5 ist außerdem nicht mit Web Applications 1.0 gleichzustellen).

Wirklich? Die WHATWG verlinkt unter »Specs« HTML5 bzw. XHTML5 (gleicher Link) »Web Applications 1.0«. Im Text finden sich dann auch Andeutungen in Richtung (X)HTML 5, Unterschiede zu HTML 4, XHTML 1 und 2 uvm. Den Working Draft sehe ich allerdings durchaus als Faktum an.

Darum hoffe ich momentan, dass die Arbeitsgruppe die guten Ideen der XHTML 2.0 Gruppe übernehmen wird. nl-Elemente und eingie andere Innovationen sind echte Killerapps.

Nach dem genaueren Vergleich beider Spezifikationen (XHTML 2 vs. HTML 5) habe ich festgestellt, dass beide Sprachen unterschiedliche Ziele haben und mMn gar nicht zwingend in Konkurrenz miteinander treten (müssen).

Interessant ist allerdings, dass XForms viel eher in Richtung einer Webanwendung geht, während in HTML 5 einfach ein paar neue und nette Elemente sowie Attribute für Formulare hinzugefügt werden.

Viele Grüße,
Robert

[Daniel unreg]

Hallo,

D.h. man müsste dem IE dann eine entsprechende CSS-Datei servieren, die ihm z.B. mitteilt, wie XHTML-Elemente angezeigt werden?

XSL triffts eher. Aber besser liest du den Eintrag der XHTML FAQ selbst :-)
Außerdem finde ich den XHTML media types test interessant.

Das bedeutet doch auch, dass so nette Dinge wie XHTML+MathML oder XHTML+SVG nicht möglich sind, oder?

Richtig. Erwähnenswert finde ich, dass Chris Wilson (IE Platform Architect) angab, dass man mit einem Parser für XHTML experimentiere. Allerdings kann das alles und nichts bedeuten. Es ist nichtmal klar, ob dieser Parser im IE Next einzug halten wird.
Ich selbst würde es begrüßen, wenn der IE alle XHTML Dokumente als XML parst, aber die Chancen stehen eher schlecht.

Wirklich? Die WHATWG verlinkt unter »Specs« HTML5 bzw. XHTML5 (gleicher Link) »Web Applications 1.0«. Im Text finden sich dann auch Andeutungen in Richtung (X)HTML 5, Unterschiede zu HTML 4, XHTML 1 und 2 uvm. Den Working Draft sehe ich allerdings durchaus als Faktum an.

Ja, Web Applications 1.0 wird zwar häufig als HTML 5 bezeichnet, der Name ist aber nur ein Synonym. Das "echte" HTML 5 (der Name steht noch nicht fest) wurde erst vor kurzem von Tim Berners-Lee angekündigt (entsprechend XHTML2).

Nach dem genaueren Vergleich beider Spezifikationen (XHTML 2 vs. HTML 5) habe ich festgestellt, dass beide Sprachen unterschiedliche Ziele haben und mMn gar nicht zwingend in Konkurrenz miteinander treten (müssen).

Ja, Web Applications 1.0 geht auch auf andere Bereiche ein und definiert z.B. neue DOM Methoden, die sehr nützlich sind. Die WHATWG hat durchaus ihre Berechtigung.

Interessant ist allerdings, dass XForms viel eher in Richtung einer Webanwendung geht, während in HTML 5 einfach ein paar neue und nette Elemente sowie Attribute für Formulare hinzugefügt werden.

Ach ja, zu den Forms gibt auch was "neues".

Gruß;

[Robert Bienert]

Moin!

D.h. man müsste dem IE dann eine entsprechende CSS-Datei servieren, die ihm z.B. mitteilt, wie XHTML-Elemente angezeigt werden?

XSL triffts eher. Aber besser liest du den Eintrag der XHTML FAQ selbst :-)

D.h. der Trick basiert darauf, dass der IE davon ausgeht, dass XSLT für ihn HTML erzeugt?

Meine Frage bezüglich CSS zielte darauf ab, dass frühere IE-Versionen XML ohne Stylesheet einfach als Parserbaum darstellen, d.h. mit CSS hätte man ein HTML-Grundgerüst nachbilden müssen.

Das bedeutet doch auch, dass so nette Dinge wie XHTML+MathML oder XHTML+SVG nicht möglich sind, oder?

Richtig. Erwähnenswert finde ich, dass Chris Wilson (IE Platform Architect) angab, dass man mit einem Parser für XHTML experimentiere. Allerdings kann das alles und nichts bedeuten. Es ist nichtmal klar, ob dieser Parser im IE Next einzug halten wird.
Ich selbst würde es begrüßen, wenn der IE alle XHTML Dokumente als XML parst, aber die Chancen stehen eher schlecht.

Ich frage mich auch, wie Microsoft den Rückstand des Internet Exploiters sowohl gegenüber der Konkurrenz als auch den Standards gegenüber je wieder aufholen will? Interessant ist in diesem Zusammenhang ja, das Microsoft W3C-Mitglied ist. Aber vielleicht weht auch daher der Wind in Richtung „XHTML als HTML“. Andererseits ist wäre das auch sehr merkwürdig, schließlich betonen deren Marketing-Experten seit Windows ME die Bedeutung von XML.

Ich finde es trotzdem suboptimal, dass man auch in Zukunft einem Großteil seiner Besucher den Tipp zum Umstieg geben muss, vor allem, wenn man mathematische Formeln korrekt und Vektorgrafiken anzeigen will.

Wirklich? Die WHATWG verlinkt unter »Specs« HTML5 bzw. XHTML5 (gleicher Link) »Web Applications 1.0«. Im Text finden sich dann auch Andeutungen in Richtung (X)HTML 5, Unterschiede zu HTML 4, XHTML 1 und 2 uvm.

Ja, Web Applications 1.0 wird zwar häufig als HTML 5 bezeichnet, der Name ist aber nur ein Synonym. Das "echte" HTML 5 (der Name steht noch nicht fest) wurde erst vor kurzem von Tim Berners-Lee angekündigt (entsprechend XHTML2).

Die Benennung als „HTML 5“ hätte ich noch nachvollziehen können, aber „XHTML 5“ für Web Applications wäre angesichts der aktuellen Entwicklung von XHTML 2 ganz schön gewagt gewesen, schließlich ist nicht auszuschließen, dass es irgendwann einmal ein XHTML 5 vom W3C gibt.

Zu dem Weblog-Artikel von Tim Berners-Lee gibt es übrigens eine Diskussion im W3C QA-Blog, die sehr gut den Zwiespalt zwischen den verschiedenen Wünschen an (X)HTML aufzeigt.

Im Übrigen lassen die „Charters“ große Vorfreude auf den Sommer 2008 aufkommen ;-)

Die WHATWG hat durchaus ihre Berechtigung.

Wenn ich mir die von dir verlinkten Beiträge durchlese und noch diverse Blog-Artikel hinzunehme, scheint die WHATWG dem W3C mal ein bisschen Dampf gemacht zu haben, was vielleicht gar nicht verkehrt ist. Bleibt nur zu hoffen, dass die Browserentwickler die geplanten, durchaus segensreichen Neuerungen nicht „boykottieren“.

Viele Grüße,
Robert

[Der Martin]

Hallo Robert,

Meine Frage bezüglich CSS zielte darauf ab, dass frühere IE-Versionen XML ohne Stylesheet einfach als Parserbaum darstellen,

was heißt "frühere Versionen"? Seit welcher Version tut er das denn nicht mehr? Ich nutze das nämlich gern und oft als ersten schnellen Check, ob meine XML-Dateien gültig sind und die Struktur wirklich die ist, die ich gemeint habe. Die relativ übersichtliche Art des IE, solche XML-Bäume darzustellen, ist dafür recht gut geeignet.

Ich frage mich auch, wie Microsoft den Rückstand des Internet Exploiters sowohl gegenüber der Konkurrenz als auch den Standards gegenüber je wieder aufholen will? Interessant ist in diesem Zusammenhang ja, das Microsoft W3C-Mitglied ist.

Vermutlich zum Bremsen?  ;-)

So long,
 Martin

[Robert Bienert]

Moin!

Meine Frage bezüglich CSS zielte darauf ab, dass frühere IE-Versionen XML ohne Stylesheet einfach als Parserbaum darstellen,

was heißt "frühere Versionen"? Seit welcher Version tut er das denn nicht mehr?

Ich hab mich falsch ausgedrückt: Ich meinte natürlich, dass der IE XHTML als XML darstellt(e), wenn man ihm dieses als solches serviert(e) und man daher per CSS oder XSL ihm XHTML beibringen konnte/kann.

Viele Grüße,
Robert

[Daniel unreg]

Hallo,

D.h. der Trick basiert darauf, dass der IE davon ausgeht, dass XSLT für ihn HTML erzeugt?

Was sich der IE dabei denkt weiß wohl nur Microsoft. Ansonnsten denke ich aber ja ;-)

Meine Frage bezüglich CSS zielte darauf ab, dass frühere IE-Versionen XML ohne Stylesheet einfach als Parserbaum darstellen, d.h. mit CSS hätte man ein HTML-Grundgerüst nachbilden müssen.

Wenn der "Trick" in früheren IE Versionen so nicht funktioniert vermutlich ja. Allerdings beschäftige ich mich schon lange nicht mehr mit IEs < 6, darum kann ich keine gute Antwort liefern.

Ich frage mich auch, wie Microsoft den Rückstand des Internet Exploiters sowohl gegenüber der Konkurrenz als auch den Standards gegenüber je wieder aufholen will? Interessant ist in diesem Zusammenhang ja, das Microsoft W3C-Mitglied ist. Aber vielleicht weht auch daher der Wind in Richtung „XHTML als HTML“. Andererseits ist wäre das auch sehr merkwürdig, schließlich betonen deren Marketing-Experten seit Windows ME die Bedeutung von XML.

Aufholung wird wohl nicht geschehen, aber Weiterentwicklung. Das ist besser als der Stillstand, den wir ein halbes Jahrzehnt ertragen mussten.
Das WaSP war außerdem vor kurzem zu Besuch bei den Entwicklern.

Witzig ist, das in der XHTML-FAQ steht, dass XHTML 1.1 pures XML ist und daher nicht als text/html versendet werden sollte. Aber momentan ist es nur ein Working Draft, mal sehen, was kommt.

Ich finde es trotzdem suboptimal, dass man auch in Zukunft einem Großteil seiner Besucher den Tipp zum Umstieg geben muss, vor allem, wenn man mathematische Formeln korrekt und Vektorgrafiken anzeigen will.

Für diese Dinge ja. Wobei ich denke oder zumindest hoffe, dass die Entwickler unter Chris Wilson wirklich was erreichen wollen.

Die Benennung als „HTML 5“ hätte ich noch nachvollziehen können, aber „XHTML 5“ für Web Applications wäre angesichts der aktuellen Entwicklung von XHTML 2 ganz schön gewagt gewesen, schließlich ist nicht auszuschließen, dass es irgendwann einmal ein XHTML 5 vom W3C gibt.

2050? *scnr*

Wenn ich mir die von dir verlinkten Beiträge durchlese und noch diverse Blog-Artikel hinzunehme, scheint die WHATWG dem W3C mal ein bisschen Dampf gemacht zu haben, was vielleicht gar nicht verkehrt ist. Bleibt nur zu hoffen, dass die Browserentwickler die geplanten, durchaus segensreichen Neuerungen nicht „boykottieren“.

Das mit dem Dampf machen scheint auch eines der Ziele der WHATWG zu sein. Was deren Web Applications 1.0 Working Draft angeht, so basiert ja Firefox' 2.0 Session Resore auf diesem. In der Entwicklerversion (3.0, Gecko 1.9) des Fx ist außerdem die getElementsByClassName() Methode implementiert worden (mehr soll folgen).

Microsoft will sich von der WHATWG eher fernhalten, da der anscheinend eine Patent Policy fehlt, wie sie z.B. das W3 hat (so Wilson in einem Interview).
Was Opera zur WHATWG sagt weiß ich leider nicht. Die Safarientwickler haben aber gefordert, dass die WHATWG an der Entwicklung von HTML teilnehmen darf.

Gruß;

[Robert Bienert]

Moin!

Ich frage mich auch, wie Microsoft den Rückstand des Internet Exploiters sowohl gegenüber der Konkurrenz als auch den Standards gegenüber je wieder aufholen will? Interessant ist in diesem Zusammenhang ja, das Microsoft W3C-Mitglied ist. Aber vielleicht weht auch daher der Wind in Richtung „XHTML als HTML“. Andererseits ist wäre das auch sehr merkwürdig, schließlich betonen deren Marketing-Experten seit Windows ME die Bedeutung von XML.

Aufholung wird wohl nicht geschehen, aber Weiterentwicklung. Das ist besser als der Stillstand, den wir ein halbes Jahrzehnt ertragen mussten.

Dann können wir ja gespannt sein, mit welcher Geschwindigkeit der IE weiter entwickelt wird. Vielleicht stellen sie es ja so geschickt an, dass sie später eine Standard-Version direkt auslassen können und ruckzuck aufgeschlossen haben ;-)

Das WaSP war außerdem vor kurzem zu Besuch bei den Entwicklern.

Was ist denn eigentlich mit „generated content“ gemeint?

Ich finde es trotzdem suboptimal, dass man auch in Zukunft einem Großteil seiner Besucher den Tipp zum Umstieg geben muss, vor allem, wenn man mathematische Formeln korrekt und Vektorgrafiken anzeigen will.

Für diese Dinge ja. Wobei ich denke oder zumindest hoffe, dass die Entwickler unter Chris Wilson wirklich was erreichen wollen.

Naja, wenn der IE 7 nicht gekommen wäre, hätte es wahrscheinlich wirklich nicht mehr lange gedauert, bis Banner auf den Webseiten aufgetaucht wären, auf denen der IE als veraltet deklassiert worden wäre – wie schon einmal das Netscape-4-Bashing.

Wenn ich mir die von dir verlinkten Beiträge durchlese und noch diverse Blog-Artikel hinzunehme, scheint die WHATWG dem W3C mal ein bisschen Dampf gemacht zu haben, was vielleicht gar nicht verkehrt ist. Bleibt nur zu hoffen, dass die Browserentwickler die geplanten, durchaus segensreichen Neuerungen nicht „boykottieren“.

Das mit dem Dampf machen scheint auch eines der Ziele der WHATWG zu sein. Was deren Web Applications 1.0 Working Draft angeht, so basiert ja Firefox' 2.0 Session Resore auf diesem. In der Entwicklerversion (3.0, Gecko 1.9) des Fx ist außerdem die getElementsByClassName() Methode implementiert worden (mehr soll folgen).

Was mich an der WHATWG, deren Entwürfen und der Realisierung ein bisschen stört, ist Web Applications zwar unter dem Aspekt des Tagsuppelöffelns korrekt beschrieben ist, aber damit die Standards bricht. Natürlich wäre es ein größerer Aufwand, Web Applications als DTD für HTML und Schema/RelaxNG/DTD + XML-Namensraum formal korrekt zu beschreiben und in den Browsern zu implementieren, aber momentan sind doch „angereicherte“ HTML-Dokumente kein richtiges HTML mehr, oder?

Microsoft will sich von der WHATWG eher fernhalten, da der anscheinend eine Patent Policy fehlt, wie sie z.B. das W3 hat (so Wilson in einem Interview).

Vielleicht auch, um ActiveX und .Net+XAML länger hochalten zu können?

Die Safarientwickler haben aber gefordert, dass die WHATWG an der Entwicklung von HTML teilnehmen darf.

Das wundert mich kaum, war nicht Safari der erste Browser, der z.B. <canvas> implementiert hatte?

Viele Grüße,
Robert

[Mathias Brodala]

Hallo Robert.

Das WaSP war außerdem vor kurzem zu Besuch bei den Entwicklern.

Was ist denn eigentlich mit „generated content“ gemeint?

Die Nutzung der content-Eigenschaft.

Einen schönen Montag noch.

Gruß, Mathias

[Robert Bienert]

Moin!

Was ist denn eigentlich mit „generated content“ gemeint?

Die Nutzung der content-Eigenschaft.

Der neue IE soll doch wohl nicht etwa so etwas hinbekommen können:

h1:before {  
    content: "Kapitel ";  
}  
.klasse:after {  
    content: url(caption.png);  
}

Viele Grüße vom erstaunten Robert

[Daniel unreg]

Hallo,

Der neue IE soll doch wohl nicht etwa so etwas hinbekommen können:

Achtung: Das WaSP hat Wünsche geäußert, die repräsentativ sein sollen. Es steht nicht fest, dass die Entwickler das auch entsprechend durchziehen!

Gruß;

[D.R.]

Hallo,

… welche HTML-Editoren sind denn auch XHTML-Editoren?

In NVU kann man z.B. XHTML einstellen (nein ich nutze trotzdem lieber meinen Quelltext-Editor ;-)).

Und welchen konkreten Vorteil kann denn der 0815-Webautor aus XHTML ziehen?

XHTML ist einfacher als HTML. Allerdings nur, wenn man nicht dauernd die Kompatiblitätsregeln beachten muss. Denn sonst muss man ja beide Sprachen lernen.

mfg. Daniel