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

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

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

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

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