Einsatz von XHTML

[Michael K.]

Hallo,

ich bin auf der Suche nach Informationen, die mir zur Beurteilung helfen, ob es sinnvoll erscheint, XHTML für ein Projekt einzusetzen bzw. Daten im XHTML-Format abzulegen. Einfach formuliert könnte man ja sagen, dass HTML5 den Vorrang vor XHTML bekommen hat und XHTML sich nicht wirklich durchgesetzt hat.

• Gibt es sachliche Argumente, warum man nicht auf XHTML setzen sollte? Gibt es öffentliche Aussage/Stellungnahmen von gewichtigen gremiem, warum XHTML nicht (mehr) verwendet werden sollte?
• Könnte es Probleme geben, wenn man XHTML-Fragmente in eine HTML5 einbinden möchte (z.B. ein Progamm bekommt von einer Datenbank die Daten, die als XHTML-String in der Datenbank abgelegt, und bindet diese in eine HTML5 Webseite ein)? Konkrete Beispile, was da schief gehen könnte?
• Gibt es Aussagen von Browser-Herstellern, dass die Unterstützung von XHTML eingestellt wird bzw. in absehbarer Zeit nicht mehr gewährleistet wird? Ich konnte bei Google und Mozilla keine Infos dazu finden.

Ich wäre sehr dankbar für Tipps, die ich dann auch selber nachlesen kann. Aber meine Google-Suche hat mich nicht wirklich zufrieden gestellt.

VG Micahel

[dedlfix]

Tach!

Meinst du mit XHTML das XHTML 4.01 oder ein vom Sprachumfang her mit HTML5 vergleichbares?

• Gibt es sachliche Argumente, warum man nicht auf XHTML setzen sollte? Gibt es öffentliche Aussage/Stellungnahmen von gewichtigen gremiem, warum XHTML nicht (mehr) verwendet werden sollte?

Anders gefragt, was bringt es denn, Webseiten zu erstellen, die es verwenden? Die Browser müssen sowieso mit HTML5 umgehen können, also kannst du das nehmen. Andere Automaten außer Suchmaschinen sind mit REST-Schnittstellen besser bedient, als Webseiten mit jeder Menge für sie nicht weiter wichtigen Elementen auszuwerten.

• Könnte es Probleme geben, wenn man XHTML-Fragmente in eine HTML5 einbinden möchte (z.B. ein Progamm bekommt von einer Datenbank die Daten, die als XHTML-String in der Datenbank abgelegt, und bindet diese in eine HTML5 Webseite ein)? Konkrete Beispile, was da schief gehen könnte?

Das reicht zwischen nichts, weil die Browser fehlertolerant sind, oder weil der Standard die XHTML-Schreibweise erlaubt und ... kommt drauf an.

• Gibt es Aussagen von Browser-Herstellern, dass die Unterstützung von XHTML eingestellt wird bzw. in absehbarer Zeit nicht mehr gewährleistet wird?

Siehe Einleitungsfrage. Wenn damit veraltete Elemente gemeint sind, dann ist möglich, aber eher unwahrscheinlich. Ansonsten zieht die Fehlertoleranz.

dedlfix.

[Michael K.]

Vielen Dank für die Antowrt.

Meinst du mit XHTML das XHTML 4.01 oder ein vom Sprachumfang her mit HTML5 vergleichbares?

Das hätte ich dazuschrieben können. Es geht konkret um das modulare XHTML 1.1

Das reicht zwischen nichts, weil die Browser fehlertolerant sind, oder weil der Standard die XHTML-Schreibweise erlaubt und ... kommt drauf an.

Na ja, Browser sind das eine, aber könnte nicht auch die Software striken, wenn z.B. versucht wird, ein XHTML Fragment ind eine HTML Seite einzubinden (über DOM). XHTML braucht ja namespace. Die Software müsste also vorher die ganze Namespace-Deklarierung entfernen?

Siehe Einleitungsfrage. Wenn damit veraltete Elemente gemeint sind, dann ist möglich, aber eher unwahrscheinlich. Ansonsten zieht die Fehlertoleranz.

Wenn ich richtig verstehe, der Brwoser versucht immer, noch etwas brauchbares darzustellen, aber ein einheitliches/standardisiertes Vorgehen gibt es nicht.

[Regina Schaukrug]

Informationen, ob es sinnvoll erscheint, XHTML für ein Projekt einzusetzen bzw. Daten im XHTML-Format abzulegen

Da würde mir als einziges die Anforderung einfallen, dass die Daten clientseitig(!) mit den einst "gehupten" XML-Techniken maschinell weiter verarbeitet werden sollen. Das war, glaub ich, zu einer Zeit als IT-Verantwortliche alles auf eine möglichst schwierige und umständliche Art und Weise zu realisieren versuchten und dabei vor allem die eigene Wichtigkeit sowie die exorbitanten Kosten für die Server, die das Zeug so gründlich wie unschnell verarbeiteten, mit Schlagworten wie "Java" und "XML" begründeten.

Die ist noch nicht ganz vorbei.

[Michael K.]

Na ja, "wohlgeformt" ist ja nicht unbedingt schlecht. Mir geht es aber darum zu beurteilen, ob Gründe dagegen sprechen, auf XHTML zu setzen, anstelle von html5 konformen Markup.

[MrMurphy1]

Hallo

ob Gründe dagegen sprechen, auf XHTML zu setzen

Ja. XHTML wurde und wird zwar auch zukünftig von allen relevanten Browsern unterstützt werden.

Offiziell ist XHTML aber bereits im Jahr 2008 beerdigt worden. Die Weiterentwicklung wurde komplett eingestellt.

Für die Besucher bietet HTML5 durch die neuen Elemente viele Vorteile. Die Syntax von HTML5 ist deutlich vereinfacht worden.

Suchmaschinen, aber auch zum Beispiel Ebay, betrachten Seiten mit XHTML grundsätzlich als veraltet und werten sie ab.

Gruss

MrMurphy

[Gunnar Bittersmann]

@@MrMurphy1

Die Syntax von HTML5 ist deutlich vereinfacht worden.

?? Vereinfacht gegenüber was?

Man kann über HTML5 vieles sagen, aber gewiss nicht, dass die Sprache einfache Regeln hätte.

LLAP 🖖

[Auge]

Hallo

Na ja, "wohlgeformt" ist ja nicht unbedingt schlecht.

Natürlich nicht. Wohlgeformt kannst du aber auch mit HTML5 schreiben.

Mir geht es aber darum zu beurteilen, ob Gründe dagegen sprechen, auf XHTML zu setzen, anstelle von html5 konformen Markup.

Dagegen spricht der damit einhergehende Verzicht auf neue semantische Elemente, neue Typen für Formularelemente, an ein paar Stellen auch vereinfachte Schreibweisen. HTML5 kannst du übrigens auch in der XML-Notation schreiben, falls es dir um dei Verarbeitung als XML geht. Ansonsten musst du dir das nicht antun.

Tschö, Auge

[Gunnar Bittersmann]

@@Auge

Wohlgeformt kannst du aber auch mit HTML5 schreiben.

„Wohlgeformt“ ist ein Begriff aus der XML-Welt. Du meinst hier die XML-Syntax für HTML5?

LLAP 🖖

[Auge]

Hallo

Wohlgeformt kannst du aber auch mit HTML5 schreiben.

„Wohlgeformt“ ist ein Begriff aus der XML-Welt. Du meinst hier die XML-Syntax für HTML5?

Ja, mit allem Brimborium von der expliziten Pflicht zum schließen von Elementen bis zu den strengeren Regeln was wo rein darf und was nicht (Verschachtelung).

Tschö, Auge

[Gunnar Bittersmann]

@@Auge

„Wohlgeformt“ ist ein Begriff aus der XML-Welt. Du meinst hier die XML-Syntax für HTML5?

Ja, mit allem Brimborium von der expliziten Pflicht zum schließen von Elementen bis zu den strengeren Regeln was wo rein darf und was nicht (Verschachtelung).

Letzteres gehört nicht zu Wohlgeformtheit. Letzteres gehört zu Gültigkeit (Validität).

In meinem jugendlichen Leichtsinn hatte ich mal den Unterschied herausgestellt.

LLAP 🖖

[Rolf B]

Hallo Michael,

bei XHTML hat man seinerzeit die "leichtere Parse-barkeit" und die über XML-Namespaces mögliche Erweiterbarkeit gehyped (oder gehupt :-D).

Dass Browser kein XHTML mehr unterstützen, sehe ich eher nicht. Den Web wohnt der Fluch der Rückwärtskompatibilität inne, und bevor der XHTML/HTML4 Zopf abgeschnitten wird, haben wir alle schon SHIT 3D (Standardized Hypermedia Integration Technology, 3D enabled) gelernt.

Problem ist eben, dass XHTML 1 die Entsprechung zu HTML 4.01 ist. Die Entwicklung ging über XHTML 1.1 zum Draft von XHTML 2, was aber dann zu Gunsten von HMTL 5 aufgegeben wurde. D.h. es gibt keinen XHTML-Standard, der HTML 5 entspricht. Statt dessen wird HTML 5 als gemeinsamer Nachfolger von HTML 4 und XHTML 1 gesehen.

D.h. es ist heute komplett unsinnig, neue Projekte basierend auf XHTML aufzusetzen. Und es ist noch unsinniger, DATEN als XHTML abzulegen. Daten legt man besser, wenn's filebasierend sein soll, mit fachlich passendem Schema als XML oder als JSON ab.

Rolf

[Gunnar Bittersmann]

@@Rolf B

bei XHTML hat man seinerzeit die "leichtere Parse-barkeit" und die über XML-Namespaces mögliche Erweiterbarkeit gehyped

Von Hype würde ich da nicht sprechen. Eher von einer vernüftigen Lösung. Heute erkennt man den Sinn von Namensräumen wieder und es wird irgendwie in HTML reingefrickelt.

D.h. es gibt keinen XHTML-Standard, der HTML 5 entspricht.

Nicht? XHTML5?

LLAP 🖖

[Rolf B]

Hallo Gunnar,

das ist aber kein eigener Standard, sondern ein XMLisierter Aufschrieb von HTML 5. Aber eigentlich - siehe §9.2 der HTML 5.2 oder 5.3 Spec:

An XML parser, for the purposes of this specification, is a construct that follows the rules given in the XML specification to map a string of bytes or characters into a Document object.

Note: At the time of writing, no such rules actually exist.

Oder habe ich da was mistverstanden?

Rolf

[pl]

hi Rolf,

Daten legt man besser, wenn's filebasierend sein soll, mit fachlich passendem Schema als XML oder als JSON ab.

Daten legt man so ab, daß man sie wiederherstellen kann. Das kann JSON oder XML sein, muß aber nicht. Vielmehr hängt der Serialize Algorithmus von der Anwendung ab welche die Daten bekommt und vom konkreten Anwendungsfall. Diese Erkenntnis haben wir doch gerade eben wieder aktuell gewonnen beim Bau einer SPA für den SelfWiki. Während JavaScript überhaupt kein Problem damit hat, eine 50MB JSON Datei in den Hauptspeicher zu lesen, ist dieselbe Datei für eine serverseitige Anwendung der ultimative Killer.

MfG

[dedlfix]

Tach!

Diese Erkenntnis haben wir doch gerade eben wieder aktuell gewonnen beim Bau einer SPA für den SelfWiki. Während JavaScript überhaupt kein Problem damit hat, eine 50MB JSON Datei in den Hauptspeicher zu lesen, ist dieselbe Datei für eine serverseitige Anwendung der ultimative Killer.

Das sagst du so, als ob das ein Naturgesetz ist. Das darf man doch stark bezweifeln. War genau sollten sämtliche Server damit ein "ultimatives Killer"-Problem haben?

dedlfix.

[pl]

Tach!

Diese Erkenntnis haben wir doch gerade eben wieder aktuell gewonnen beim Bau einer SPA für den SelfWiki. Während JavaScript überhaupt kein Problem damit hat, eine 50MB JSON Datei in den Hauptspeicher zu lesen, ist dieselbe Datei für eine serverseitige Anwendung der ultimative Killer.

Das sagst du so, als ob das ein Naturgesetz ist. Das darf man doch stark bezweifeln. War genau sollten sämtliche Server damit ein "ultimatives Killer"-Problem haben?

Probier doch den konkreten Fall einfach mal aus. Eine 27MB JSON Datei findest Du hier. Entscheidend ist jedoch das was ich allgemein festgestellt habe, nämlich: Es hängt immer vom entsprechenden Anwendungsfall ab -- Und wenn Du das bezweifeln möchtest, solltest Du keine Anwendungen entwicklen.

MfG

PS: Das parsen o.g. Datei mit dem pure Perl JSON Parser dauert bei mir mehr als 5 Minuten. Wie lange dauert es denn bei Dir mit PHP?

[dedlfix]

Tach!

Diese Erkenntnis haben wir doch gerade eben wieder aktuell gewonnen beim Bau einer SPA für den SelfWiki. Während JavaScript überhaupt kein Problem damit hat, eine 50MB JSON Datei in den Hauptspeicher zu lesen, ist dieselbe Datei für eine serverseitige Anwendung der ultimative Killer.

Das sagst du so, als ob das ein Naturgesetz ist. Das darf man doch stark bezweifeln. War genau sollten sämtliche Server damit ein "ultimatives Killer"-Problem haben?

Probier doch den konkreten Fall einfach mal aus. Eine 27MB JSON Datei findest Du hier. Entscheidend ist jedoch das was ich allgemein festgestellt habe, nämlich: Es hängt immer vom entsprechenden Anwendungsfall ab -- Und wenn Du das bezweifeln möchtest, solltest Du keine Anwendungen entwicklen.

Danke für die Unterstellung, aber eine Formulierung, aus der klar daraus hervorgeht, dass sie sich auf eine konkrete Situation bezieht, wäre eindeutiger verständlich gewesen als eine, die sehr pauschal klingt.

dedlfix.

[pl]

Schwätzer. Was macht denn Dein konkretes Benchmark? Bitte Ergebnis!

[Mitleser]

Schwätzer. Was macht denn Dein konkretes Benchmark? Bitte Ergebnis!

time perl test.pl

real 0m0.229s user 0m0.179s sys 0m0.050s

test.pl:

#!/usr/bin/perl
use strict;
use warnings;
use JSON ();

my $json = '';
open (INFILE, '<:utf8', 'selfwiki.bin') or die $!;
while (<INFILE>) {
	$json .= $_;
}
close INFILE;

my $data = JSON->new()->decode($json);

print "done\n";

[pl]

Danke für Deinen Test. Vermutlich hast Du die XS Version die freilich deutlich schneller ist als pure Perl aber der Algorithmus ist derselbe. Was aber letztendlich auch nur meine Feststellung bestätigt, nämlich daß es immer vom konkreten Anwendungsfall abhängt. Und mit Sicherheit auch von System. Eben das sind genau die Fragen wenn es um die Portability geht und nicht etwa die Frage des Dateiformat.

JavaScript braucht im Übrigen auch auf meinem System nur Bruchteile von Sekunden um eine 30MB-JSON Datei zu parsen. Mit pure Perl jedoch habe ich den Test nach 5 Minuten abgebrochen.

MfG

[markk]

Moin,

Feststellung war:

Es hängt immer vom entsprechenden Anwendungsfall ab

Dann Anwendungsfall:

Während JavaScript überhaupt kein Problem damit hat, eine 50MB JSON Datei in den Hauptspeicher zu lesen, ist dieselbe Datei für eine serverseitige Anwendung der ultimative Killer.

Gegenbeweis:

real 0m0.229s user 0m0.179s sys 0m0.050s

Reaktion:

Was aber letztendlich auch nur meine Feststellung bestätigt

wie man sich dreht und wendet..

Cheers, markk

[Matti]

Hallo,

ich habe lange(!) kein perl mehr programmiert, aber das Einlesen mit "slurp mode" sollte doch ein wenig schneller sein als die String-Konkatenierun in der while-Schleife.

Probier bitte mal

#!/usr/bin/perl

use strict;
use warnings;
use JSON ();

my $json;
{
  open my $fh, '<:utf8', 'selfwiki.bin';
  local $/;
  $json = <$fh>;
  close $fh;
}

my $data = JSON->new()->decode($json);
print "done\n";

Viele Grüße Matti

[Mitleser]

ich habe lange(!) kein perl mehr programmiert, aber das Einlesen mit "slurp mode" sollte doch ein wenig schneller sein als die String-Konkatenierun in der while-Schleife.

Probier bitte mal

Dem ist auch so! Das bringt auf meinem Testsystem einen nennenswerten Vorteil von ca. 70ms. Sollte man bei der Dateigröße auch so machen. Aber der Löwenanteil geht tatsächlich auf das JSON->decode, bei der Menge ja auch nachvollziehbar.

[Rolf B]

Hallo pl,

war dein Problem nicht der Javascript-ArrayBuffer, oder irgendwas in Perl? PHP ist es jedenfalls nicht...

<?php
$start = now();
$wikiFile = file_get_contents("selfwiki.bin");
$gotFile = now();

echo "Gelesen: " . strlen($wikiFile) . " bytes in " . ($gotFile-$start) . "ms\n";

$wiki = json_decode($wikiFile, true);
$gotJson = now();

echo "Decodiert wurde ein " . getType($wiki) . " mit " . count($wiki) . " keys in " .($gotJson-$gotFile)."ms\n";

function now() {
   return microtime(true) * 1000;
}

Gelesen: 27669562 bytes in 46.0048828125ms
Decodiert wurde ein array mit 3 keys in 306.03002929688ms

Ob's richtig decodiert wurde habe ich nicht überprüft. json_decode will einen UTF-8 codierten String, deine .bin ist UTF-8 codiert, d.h. solange file_get_contents nicht dran rummaggelt sollte es passen.

Rolf

[Rolf B]

Hallo pl,

Das kann JSON oder XML sein, muß aber nicht.

Stimmt natürlich. Ich schrieb ja auch "besser" - im Vergleich zu XHTML als Speicherstruktur.

Es ist jedem unbenommen, ein für den Anwendungszweck passendes Format zu wählen, proprietär oder offen.

Rolf

[pl]

Hi Rolf,

Es ist jedem unbenommen, ein für den Anwendungszweck passendes Format zu wählen, proprietär oder offen.

Nein ist es eben nicht. Und wenn eine Datenwiederherstellung aus einer JSON Datei länger als 5 Minuten dauert, würde ich auch nicht unbedingt von einem portablen Dateiformat reden. Portabel ist das nämlich erst in dem Moment wenn die entsprechenden Libraries verfügbar sind, was für JavaScript und PHP zutrifft wie ich gerade eben am konkreten Beispiel dieser Datei nun auch für PHP feststellen konnte.

Bei einem ArrayBuffer hingegen würde ich da schon eher von Portabilität reden, denn ein Solcher wird sowohl mit JavaScript als auch mit pure Perl mit derselben Performance eingelesen. Die browserinterne Speicherbegrenzung ist wieder eine ganz andere Geschichte, aber auch zu berücksichtigen.

Und schließlich sei noch angemerkt, daß diese Datei hier zur Laufzeit mit pure Perl erstellt wird: Aus derzeit 3 einzelnen Binaries mit den Objekten für contents:{} und examples:{} und redirects:{}. Genau das ist eben die Praxis portabler Deiteiformate -- umsetzten was im konkreten Fall machbar ist -- und da steckt eben doch ein bischen mehr dahinter als nur eine lapidare Feststellung daß JSON und XML portable Dateiformate sind.

Denn daran ist schon so mancher gescheitert, u.a. einer meiner verflossenen Arbeitgeber und was soll ich sagen, das geht bei mir runter wie Öl 😉

MfG

[Mitleser]

Bei einem ArrayBuffer hingegen würde ich da schon eher von Portabilität reden, denn ein Solcher wird sowohl mit JavaScript als auch mit pure Perl mit derselben Performance eingelesen.

Hatten wir vor ein paar Monaten schonmal. Da war Deine Lösung im Client drastisch langsamer und erzeugte auch mehr Datenoverhead als JSON.

[Rolf B]

Hallo pl,

wenn eine Datenwiederherstellung aus einer JSON Datei länger als 5 Minuten dauert

... dann ist sie für den Anwendungszweck "Wiederherstellbarkeit auf dieser zu langsamen Plattform" eben nicht geeignet.

Portabel ist das nämlich erst in dem Moment wenn die entsprechenden Libraries verfügbar sind

Wenn der Anwendungszweck im Verarbeiten auf einem System besteht, wo die Lib für das Format fehlt, dann erfüllt das Format nicht den Anwendungszweck.

Insofern: Wir widersprechen uns doch gar nicht mit unseren Aussagen. Ich habe eine Menge X von zu unterstützenden Plattformen, eine Menge Y von verfügbaren Daten-/Dateiformaten, und wähle aus Y eins, das für alle X funktioniert (d.h. in akzeptabler Zeit und fehlerfrei gelesen und/oder geschrieben werden kann). JSON und XML sind gute Kandidaten, aber nicht das Allheilmittel.

Wenn das Einlesen einer JSON-Datei auf einem System $$X_i$$ 5 Minuten braucht, während sie auf anderen Systemen in 0,5s gelesen wird, ist das noch kein Portabilitäts K.O., sondern erstmal die Frage ob die verwendete Lesetechnik vielleicht ein Problem hat. Natürlich kann auch einfach die Hardware von $$X_i$$ für diese JSON-Bombe untauglich sein (die selfhtml.bin möchte ich auf meinem TI-59 nicht verarbeiten). Aber ist das dann ein Portabilitätsmangel im Datenformat? Oder - bei adäquater Hardware - ein Bug in der verwendeten JSON-Libary?

Ein ArrayBuffer ist übrigens kein Dateiformat, sondern eine Technik zum Speichern eines Binärwurms mit beliebigem Format 😉

Rolf

[pl]

Hi Rolf,

Insofern: Wir widersprechen uns doch gar nicht mit unseren Aussagen.

Stimmt.

Ein ArrayBuffer ist übrigens kein Dateiformat, sondern eine Technik zum Speichern eines Binärwurms mit beliebigem Format 😉

Dieser Serializer arbeitet mit ArrayBuffer und Uint32 Array. Das sind c-bekannte Datentypen die halt in JS nur auf diese Art und Weise verfügbar sind. Das ist zwar ziemlich umständlich aber möglicherweise verursacht mein JS Code selbst ein Speicherleck. Da gibts also auf jeden Fall was zu verbessern (bezogen auf JS). Dieser extrem einfache, RAM und CPU gefällige und leicht verständliche (!) Algorithmus selbst ist in allen PLs implementierbar mit JS, PHP, Perl und c usw.

Man kann damit binärsicher, performant, ressourcensparend und plattformübergreifend Daten transportieren ohne den Prozessor zu vergewaltigen. JSON ist nämlich, wie sämtliche anderen zeichenorientierten Serializer, alles Andere als CPU compliant und vor 5 Jahren noch ist bereits mit 100 kB JSON Dateien so mancher Entwickler damit mächtig auf die Schnauze gefallen.

MfG

[Gunnar Bittersmann]

@@Michael K.

Einfach formuliert könnte man ja sagen, dass HTML5 den Vorrang vor XHTML bekommen hat

Ja. Es gibt aber für HTML5 zwei Syntaxen.

Du kannst HTML5 polyglott schreiben, d.h. in XML-Syntax, es aber als HTML (text/html) ausliefern. Oder als XHTML5 (applicacion/xhtml+xml) – aber welchen Vorteil hätte das?

• Gibt es sachliche Argumente, warum man nicht auf XHTML setzen sollte?

Wenn du XHMTL 1.x meinst: ja. Es fehlen darin viele Dinge, die für die Benutzbarkeit von Webseiten (UX und Barrierefreiheit) bedeutsam sind.

Verwende HTML5, a/k/a HTML. Wenn du magst, polyglott.

LLAP 🖖