HTML oder XHTML
0 0 0 
molily
HTML oder XHTML
Hallo Selfhtml,
jetzt suche ich schon seit einigen Stunden nach ein paar guten
Argumenten für HTML und XHTML. Dabei habe ich viele Meinungen,
Blogs und auch Berichte gelesen, dass mir die Haare zu Berge stehen.
Die einen erklären XHTML für tot:
andere wiederrum schreiben, dass HTML nicht mehr weiterentwickelt
wird, aber dann findet man so Schlagwörter wie XHTML2 und HTML5,
was keine der beiden Aussagen bekräftigt. Möchte man jedoch Abwärts-
kompatibel zu Microsofts IE sein, sollte man auf jeden Fall HTML
verwenden, denn immerhin ist der IE noch immer der meistgenutzte
Browser.
Was sollte man also verwenden, wenn man es richtig machem möchte?
Oder ist dieser Gedankenzug unsinnig, hauptsache es kommt irgendwie
lesbar im Browser des Besuchers an?
...
Auch was die Validierung und die Sauberkeit von HTML und XHTML
betrifft, gehen die Meinungen sehr stark auseinander, aber mal
ehrlich... wen juckt das eigentlich? Von Strict, über Transitional
und Frameset bis zum "quirks"-Modus gibt es alle möglichen Varianten
um valide - ja, "valide" ist sehr weit hergeholt - HTML oder XHTML
zu schreiben, aber wirklich richtig macht es selten jemand.
Ich habe einfach mal testweise ein paar sehr bekannte Namen
ausgewählt und die Webseiten mit dem W3C-Validator geprüft...
oreilly.com
microsoft.com
amazon.com
google.com
ebay.com
apple.com
oracle.com
mysql.com
linux.org
php.net
yahoo.com
uvm. Keine der Seiten sind valide. Woran mag das wohl liegen? Sind
die Entwickler einfach nur zu faul oder gibt es soviele Varianten,
dass keiner mehr da durch blickt?
Was haltet ihr davon?
Viele Grüße,
Jonny
-
Bonjour!
jetzt suche ich schon seit einigen Stunden nach ein paar guten
Argumenten für HTML und XHTML. Dabei habe ich viele Meinungen,
Blogs und auch Berichte gelesen, dass mir die Haare zu Berge stehen.Solche Diskussionen findest Du auch massig hier im Archiv. Und die Quintessenz hast Du ja auch schon rausgefunden: Man ist sich nicht einig. ;-)
Die einen erklären XHTML für tot:
andere wiederrum schreiben, dass HTML nicht mehr weiterentwickelt
wird, aber dann findet man so Schlagwörter wie XHTML2 und HTML5,
was keine der beiden Aussagen bekräftigt.Nach meinem Wissensstand werden beide weiterentwickelt, aber es ist auch bei beiden Ansätzen noch nicht klar, ob und wann daraus ein Standard wird, den man in freier Wildbahn auch verwenden kann.
Möchte man jedoch Abwärts-
kompatibel zu Microsofts IE sein, sollte man auf jeden Fall HTML
verwenden, denn immerhin ist der IE noch immer der meistgenutzte
Browser.Nicht unbedingt; der IE kommt auch mit XHTML klar. Man sollte ihm nur nicht per Content-type im HTTP-Header sagen, daß es XHTML ist, denn das versteht er nicht. Laß es ihn als HTML behandeln, dann ist das Ergebnis auch genauso gut.
Was sollte man also verwenden, wenn man es richtig machem möchte?
Oder ist dieser Gedankenzug unsinnig, hauptsache es kommt irgendwie
lesbar im Browser des Besuchers an?Der Gedankengang ist nicht unsinnig, aber es gibt keine unumstrittene Antwort. Hier im Forum bleibt im allgemeinen unwidersprochen, daß man nicht XHTML 1.1 verwenden sollte, denn damit gibt es wirklich noch Schwierigkeiten. XHTML 1.0 ist aber okay.
Auch was die Validierung und die Sauberkeit von HTML und XHTML
betrifft, gehen die Meinungen sehr stark auseinander, aber mal
ehrlich... wen juckt das eigentlich? Von Strict, über Transitional
und Frameset bis zum "quirks"-Modus gibt es alle möglichen Varianten
um valide - ja, "valide" ist sehr weit hergeholt - HTML oder XHTML
zu schreiben, aber wirklich richtig macht es selten jemand.Ich persönlich verwende nur Strict und achte auf die Validität. Sicherlich gibt es invalide Seiten, deren Fehler nicht schlimm sind, aber man erspart sich eine Menge, wenn man es gleich ›richtig‹ macht.
[viele bekannte Seiten]
uvm. Keine der Seiten sind valide. Woran mag das wohl liegen? Sind
die Entwickler einfach nur zu faul oder gibt es soviele Varianten,
dass keiner mehr da durch blickt?Seiten von großen Unternehmen werden gerne mit Content Management Systemen erstellt, ohne daß jemand den Quelltext validiert. Viele CMS und viele Webseiten wurden auch zu Zeiten erstellt, wo man die Standards noch nicht so ernst genommen hat - weil es nur wenige Browser gab, weil die Standards damals für manche Zwecke unzureichend waren usw.
Und jetzt hat man halt keine Zeit und Lust, alles neu zu machen, da es ja auch so hinreichend gut funktioniert. Wenn Du bei den genannten Seiten wegen eines Problems den Webmaster kontaktierst, kann ich mir vorstellen, daß er versuchen wird, dieses Problem zu beheben. Aber nur um der Sache willen mal das CMS neu programmieren? Dafür ist dem Chef die bezahlte Arbeitszeit dann doch zu schade.Was haltet ihr davon?
Neue Projekte sollten valide sein; egal, ob HTML oder XHTML. Der Aufwand für die Erstellung einer validen Seite ist auch nicht spürbar größer als für eine invalide (es sei denn, man verwendet Tools wie Frontpage ;-) ). Bei bestehenden Projekten muß man halt abwägen, ob sich der Aufwand lohnt.
Viele Grüße vom Længlich
-
Hallo,
Nach meinem Wissensstand werden beide weiterentwickelt, aber es ist auch bei beiden Ansätzen noch nicht klar, ob und wann daraus ein Standard wird, den man in freier Wildbahn auch verwenden kann.
Das Ob schon, nur das Wann und Wie noch nicht. HTML-5-Editor Hickson meinte, in HTML 5 seien inzwischen alle wichtigen Features drin, die für diese Version wichtig wären, sehr viel mehr würde nicht mehr kommen. Aber so ein Entwurf befindet sich ja auch im stetigen Wandel.
Nicht unbedingt; der IE kommt auch mit XHTML klar. Man sollte ihm nur nicht per Content-type im HTTP-Header sagen, daß es XHTML ist, denn das versteht er nicht. Laß es ihn als HTML behandeln, dann ist das Ergebnis auch genauso gut.
Nein, wie du selbst sagst kommt der IE nur mit XHTML-Quelltext klar, der sich als HTML ausgibt. Das ist erwiesenermaßen fehlerhaftes HTML (auch wenn das keinen Browser interessiert) und zieht mehr Probleme mit sich als du meinst. Das Dokument muss schließtlich dennoch als XML und HTML identisch verarbeitet werden können und identisch funktionieren. Das ist im Internet Explorer gar nicht möglich. Außerdem ist der IE nicht der einzige Browser der den XHTML-Medientyp nicht versteht.
Der Gedankengang ist nicht unsinnig, aber es gibt keine unumstrittene Antwort. Hier im Forum bleibt im allgemeinen unwidersprochen, daß man nicht XHTML 1.1 verwenden sollte, denn damit gibt es wirklich noch Schwierigkeiten. XHTML 1.0 ist aber okay.
Das ist nur ein Trugschluss. Sieht man sich die anscheinenden XHTML-Webseiten an und verarbeitet Sie mit einem XML-Werkzeug, dann ist der Großteil nicht betrachtbar (weil fehlerhaft) und der kleine Rest schlägt sich mit anderen problematischen Nachteilen rum. Ein Teil der Probleme fällt auch gar nicht auf, weil die Browser sich hier stark unterscheiden.
Ich persönlich verwende nur Strict und achte auf die Validität. Sicherlich gibt es invalide Seiten, deren Fehler nicht schlimm sind, aber man erspart sich eine Menge, wenn man es gleich ›richtig‹ macht.
Nunja, in XHTML führt der kleinste Fehler zum Parseabbruch. Es wird nur eine Fehlermeldug angezeigt. Aber weil XHTML im Web nicht als XML verarbeitet wird interressiert das keinen. XHTML hat im Web versagt. Es wird nicht mehr möglich sein die umzukehren.
In HTML ist das anders, Fehlerhafte Elemente werden ignoriert, feherhafte Verschachtelungen korrigiert. Genau da setzt HTML 5 an. Es werden bestimmte Fehlerkorrekturen standardisiert. Dadurch mag zwar der eindruck entstehen, HTML 5 würde Tagsoup fördern, dem ist aber nicht so. Es gibt Kriterien, was fehlerhaft ist und was nicht. Nur wird die Fehlerkorrektur nicht mehr nur den Browserherstellern überlassen.
Neue Projekte sollten valide sein; egal, ob HTML oder XHTML. Der Aufwand für die Erstellung einer validen Seite ist auch nicht spürbar größer als für eine invalide (es sei denn, man verwendet Tools wie Frontpage ;-) ). Bei bestehenden Projekten muß man halt abwägen, ob sich der Aufwand lohnt.
Nunja, gültigkeit ist sicher nicht alles, aber es erleichtert die Fehlersuche doch sehr, wenn man nur 1 Fehler statt 100 angezeigt bekommt.
Gruß;
-
Shalom!
Das Ob schon, nur das Wann und Wie noch nicht. HTML-5-Editor Hickson meinte, in HTML 5 seien inzwischen alle wichtigen Features drin, die für diese Version wichtig wären, sehr viel mehr würde nicht mehr kommen. Aber so ein Entwurf befindet sich ja auch im stetigen Wandel.
Danke, da war ich noch auf dem vorletzten Stand. ;-)
Nicht unbedingt; der IE kommt auch mit XHTML klar. Man sollte ihm nur nicht per Content-type im HTTP-Header sagen, daß es XHTML ist, denn das versteht er nicht. Laß es ihn als HTML behandeln, dann ist das Ergebnis auch genauso gut.
Nein, wie du selbst sagst kommt der IE nur mit XHTML-Quelltext klar, der sich als HTML ausgibt. Das ist erwiesenermaßen fehlerhaftes HTML (auch wenn das keinen Browser interessiert) und zieht mehr Probleme mit sich als du meinst. Das Dokument muss schließtlich dennoch als XML und HTML identisch verarbeitet werden können und identisch funktionieren. Das ist im Internet Explorer gar nicht möglich. Außerdem ist der IE nicht der einzige Browser der den XHTML-Medientyp nicht versteht.
Okay, hier tut Begriffsklärung not: Mit "klarkommen" meinte ich nicht, daß der IE das richtig könne, sondern daß man eine valide XHTML-Seite bauen kann, die auch im IE wie gewünscht dargestellt wird. Besser wird's nämlich leider auch mit HTML nicht - das kann der IE strenggenommen auch nicht richtig. Beispielsweise verwende ich unsemantischerweise sowohl für Abkürzungen als auch für Akronyme <acronym>, weil der IE bei <abbr> den title nicht darstellt. *roll_eyes*
Der Gedankengang ist nicht unsinnig, aber es gibt keine unumstrittene Antwort. Hier im Forum bleibt im allgemeinen unwidersprochen, daß man nicht XHTML 1.1 verwenden sollte, denn damit gibt es wirklich noch Schwierigkeiten. XHTML 1.0 ist aber okay.
Das ist nur ein Trugschluss. Sieht man sich die anscheinenden XHTML-Webseiten an und verarbeitet Sie mit einem XML-Werkzeug, dann ist der Großteil nicht betrachtbar (weil fehlerhaft) und der kleine Rest schlägt sich mit anderen problematischen Nachteilen rum. Ein Teil der Probleme fällt auch gar nicht auf, weil die Browser sich hier stark unterscheiden.
Der Unterschied ist der, daß man dem IE XHTML 1.0 als HTML vorsetzen kann, ohne gegen irgendeinen Standard zu verstoßen; bei XHTML 1.1 geht das nicht mehr.
Insgesamt ist es nicht ratsam, XHTML tatsächlich als XML parsen zu lassen, und - da hast Du schon recht - damit gehen fast alle Vorteile gegenüber HTML verloren. Es bleiben einzig die besseren Fehlermeldungen des Validators übrig.Ich persönlich verwende nur Strict und achte auf die Validität. Sicherlich gibt es invalide Seiten, deren Fehler nicht schlimm sind, aber man erspart sich eine Menge, wenn man es gleich ›richtig‹ macht.
Nunja, in XHTML führt der kleinste Fehler zum Parseabbruch. Es wird nur eine Fehlermeldug angezeigt. Aber weil XHTML im Web nicht als XML verarbeitet wird interressiert das keinen. XHTML hat im Web versagt. Es wird nicht mehr möglich sein die umzukehren.
XHTML wurde im Web noch nie so verwendet, wie es gedacht war, und konnte deswegen seine Vorteile nicht ausspielen (s.o.). Und daran wird sich wohl auf absehbare Zeit nichts ändern, weil dieses Thema weder bei Browserherstellern noch bei Webmastern große Priorität hat. Es kann gut sein, daß HTML 5 XHTML wieder verdrängen wird.
In HTML ist das anders, Fehlerhafte Elemente werden ignoriert, feherhafte Verschachtelungen korrigiert. Genau da setzt HTML 5 an. Es werden bestimmte Fehlerkorrekturen standardisiert. Dadurch mag zwar der eindruck entstehen, HTML 5 würde Tagsoup fördern, dem ist aber nicht so. Es gibt Kriterien, was fehlerhaft ist und was nicht. Nur wird die Fehlerkorrektur nicht mehr nur den Browserherstellern überlassen.
Das klingt durchaus sehr sinnvoll. Wenn das konsequent und nachvollziehbar durchgezogen wird, ist das sicher eine ernstzunehmende Alternative zu XHTML.
Neue Projekte sollten valide sein; egal, ob HTML oder XHTML. Der Aufwand für die Erstellung einer validen Seite ist auch nicht spürbar größer als für eine invalide (es sei denn, man verwendet Tools wie Frontpage ;-) ). Bei bestehenden Projekten muß man halt abwägen, ob sich der Aufwand lohnt.
Nunja, gültigkeit ist sicher nicht alles, aber es erleichtert die Fehlersuche doch sehr, wenn man nur 1 Fehler statt 100 angezeigt bekommt.
Exakt. Und die Wahrscheinlichkeit, daß es in irgendeinem unbekannten Client funktioniert, den man nicht getestet hat, ist dann auch höher.
Viele Grüße vom Længlich
-
-
-
Hallo,
im Moment hast du zwei Möglichkeiten eine Webseite zu verfassen:
1. in einer Variante von HTML 4.01
2. in einer Variante von XHTML 1.0Beide werden aktiv weiterentwickelt. Sowohl HTML 5 als auch XHTML 2.0 befinden sich in der Entwicklung, auch wenn die XHTML-2.0-Arbeitsgruppe sich momentan um andere Dinge kümmert.
Ich persönlich rate dir zu einer HTML-4.01-Variante. Warum?
Würdest du eine XHTML-1.0-Variante wählen müsstest du das Dokument so gestaltetn, dass es sowohl von XML- als auch von HTML-Parsern verarbeitet werden kann und noch dazu identisch funktioniert. Das hat den Hintergrund, dass nicht jeder Benutzeragent XHTML verarbeiten kann.Genauer: Einige Benutzeragenten kennen den XHTML-Medientyp „application/xhtml+xml“ nicht. Mit diesem Medientyp versendete Dokumente wären echtes XHTML. Sendet man XHTML-Quelltext mit dem HTML-Medientyp „text/html“ verliert man alle bis auf einen Vorteil von XHTML. Müsste aber dennoch sicherstellen, dass das Dokument auch als XML verarbeitet werden kann.
Dadurch entsteht ein großer Mehraufwand, der den einzig übrigen XHTML-Vorteil (strenge Fehlerprüfung) meines Erachtens nicht rechtfertigt.
Die einen erklären XHTML für tot:
XHTML ist nicht tot, aber der Entwurf von XHTML 2.0 geht sehr an der Realität vorbei. Statt der bekannten Forulare müssen z.B. XForms verwendet werden. Deshalb sagt das W3C nun XHTML 2.0 wäre für die Bedrüfnisse von Großunternehmen gemacht.
Das ebenfalls beim W3C in Entwicklung befindende HTML 5 möchte dagegen mit der Realität der heutigen Browserwelt umgehen. HTML 5 definiert aber nicht nur neue Features für HTML, sondern eine eigene HTML-Syntax, so dass diese ähnlich XML auf Fehler geprüft werden kann, aber auch Fehlerbehebungsalgorhytmen im Browser selbst implementiert wrden können.
Das ist noch nicht alles, HTML 5 wird auch als XML-Variante verfügbar sein. Das wird XHTML 5 genannt. Allerdings raten die Autoren von HTML 5 von deren Verwendung ab, weil sich XML im Web nicht wirklich durchgesetzt hat.
Was sollte man also verwenden, wenn man es richtig machem möchte?
Ich rate zu HTML 4.01 Strict. Verwende eine strenge DTD zum Prüfen des Dokuments (z.B. mit David Hammonds Werkzeug) und setze ein bisschen Verstand ein, dann benötigst du den einzig übrigen XHTML-Vorteil (strenge Fehlerprüfung) nicht mehr.
Oder ist dieser Gedankenzug unsinnig, hauptsache es kommt irgendwie
lesbar im Browser des Besuchers an?XHTML ist fehlerhaftes HTML und wird auch meistens so verwendet. Man sollte nicht absichtlich Fehler machen.
Auch was die Validierung und die Sauberkeit von HTML und XHTML
betrifft, gehen die Meinungen sehr stark auseinander, aber mal
ehrlich... wen juckt das eigentlich? Von Strict, über Transitional
und Frameset bis zum "quirks"-Modus gibt es alle möglichen Varianten
um valide - ja, "valide" ist sehr weit hergeholt - HTML oder XHTML
zu schreiben, aber wirklich richtig macht es selten jemand.HTML 4.01 und XHTML 1.0 sind im Sprachumfang nahezu identisch. Da kann man nicht sagen eines wär sauberer als das andere. XHTML kann man zwar heute strenger auf Fehler prüfen als HTML, das soll sich aber mit HTML 5 ändern. Und wie gesagt, HTML kann man strenger als der normale Validator mit einer strengeren DTD prüfen. Damit findet man zwar nicht alle Fehler, aber mit ein bisschen Verstand sollte auch das kein Problem sein.
Ich habe einfach mal testweise ein paar sehr bekannte Namen
ausgewählt und die Webseiten mit dem W3C-Validator geprüft...Microsoft braucht man wohl nicht prüfen, deren browser ist ja der schechteste. Diese Seiten funktionieren nebenbei in anderen Browsern auch nicht so gut und fehlerfrei wie Seiten, bei denen man den Standardkonformen Modus und den ein oder anderen Standard im Hinterkopf hatte.
Bei Google hat man festgestellt, dass man mit standardkonformen Design kleinere Seitengrößen erreichen kann. Ebenso bei E-Bay, wo 2/3 der Seitengröße gespart werden hätten können (ouh, Deutsch).
Warum man hier nicht mit Standards arbeitet? Wahrscheinlich weil noch 0.05% mit dem Netscape Navigator 4.0 surft. Wie viele Benutzer wohl verloren gehen, weil sie durch Ihre Behinderung die Seite auf Grund dieses alten Browsers nicht nutzen können?.....
uvm. Keine der Seiten sind valide. Woran mag das wohl liegen? Sind
die Entwickler einfach nur zu faul oder gibt es soviele Varianten,
dass keiner mehr da durch blickt?Es gibt in der Tat viel verwirrung, was nun richtig ist und keiner ist sich einig. Letztendlich muss jeder für sich die Argumente suchen und danach entscheiden, ob man es so oder so macht. Leider machen die meisten Autoren, die XHTML schreiben wollen, den Fehler, nicht die ganzen Nachteile zu beachten, die sie im Vergleich zu HTML haben. Sie amchen sich nichtmal die Mühe auf Fehler zu testen, wodurch ungültige XHTML-Dokumente entstehen, die als XML gar nicht verarbeitet werden könnten.
Was haltet ihr davon?
HTML 4.01 Strict und der absolut standardkonforme Modus sind die einzig Wahl für mich.
Liebe Grüße;
-
Hallo Daniel,
Beide werden aktiv weiterentwickelt. Sowohl HTML 5 als auch XHTML 2.0 befinden sich in der Entwicklung (...)
Von HTML 5 wird es auch die Variante XHTML 5 geben.
Tim
-
Hallo,
Von HTML 5 wird es auch die Variante XHTML 5 geben.
Wie ich es später im Text auch erwähnt habe ;)
Gruß;
-
-
Hallo,
Sendet man XHTML-Quelltext mit dem HTML-Medientyp „text/html“ verliert man alle bis auf einen Vorteil von XHTML.
Namentlich welche Vorteile verliert man denn?
Müsste aber dennoch sicherstellen, dass das Dokument auch als XML verarbeitet werden kann.
Faktisch macht das übrigens fast niemand.
HTML 5 wird auch als XML-Variante verfügbar sein. Das wird XHTML 5 genannt. Allerdings raten die Autoren von HTML 5 von deren Verwendung ab, weil sich XML im Web nicht wirklich durchgesetzt hat.
»authors are discouraged from trying to use XML on the Web, because XML has much stricter syntax rules than the "HTML5" variant described above, and is relatively newer and therefore less mature.«
http://www.whatwg.org/specs/web-apps/current-work/#html-vsDer erste Punkt ist klar, aber unsinnig, weil dieses Merkmal für diejenigen, die XHTML 5 einsetzen wollen, gerade für den Einsatz spricht; wieso sollte man es sonst tun.
Der Rest ist leeres Gelaber. XML sei »neuer« - als was? HTML 5 ist eine komplette Neuentwicklung und hat mit alten Traditionen wie SGML zum Glück nix zu tun. Dabei ist XML auch schon fast 10 Jahre alt und als Plattform alles andere als unausgereift und experimentell.Verwende eine strenge DTD zum Prüfen des Dokuments (z.B. mit David Hammonds Werkzeug) und setze ein bisschen Verstand ein, dann benötigst du den einzig übrigen XHTML-Vorteil (strenge Fehlerprüfung) nicht mehr.
Verstand setze ich mal voraus; der Zweck von maschineller Überprüfung enthält sich dort, wo man selbigen nicht einsetzen will oder kann. Dafür setze ich doch Validatoren ein. Die tausenden HTML-Dateien von SELFHTML, von deren Validierung ich gerne erzähle, passten z.B. nicht in meinen Verstand. ;)
Mathias
-
Hallo,
Namentlich welche Vorteile verliert man denn?
Aus der Autorensicht: Man sieht keine Fehler. Nach diesem Kriterium arbeiten wiele Webautoren. Wenn da ein XHTML-Doctype dabei ist meint der Großteil außerdem, bei einem Fehler würde man den schon bemerken.
Das etwas nicht stimmt würde spätestens auffallen, wenn man andere XML-Derivate einbinden möchte, was in HTML natürlich nicht möglich ist.
Faktisch macht das übrigens fast niemand.
Das ist mir klar. Daraus muss man ja auch foglern, dass XHTML im Web chancenlos ist. Es führt nur kaum zu Problemen, weil XML-Werkzeuge die für »Speichersensitive« Geräte wie Handys etc. ohnehin nicht eingesetzt werden.
»authors are discouraged from trying to use XML on the Web, because XML has much stricter syntax rules than the "HTML5" variant described above, and is relatively newer and therefore less mature.«
http://www.whatwg.org/specs/web-apps/current-work/#html-vsEine Quelle von vielen ;) In der Arbeitsgruppe gibt es viele Stimmen Für und Wider.
Der erste Punkt ist klar, aber unsinnig, weil dieses Merkmal für diejenigen, die XHTML 5 einsetzen wollen, gerade für den Einsatz spricht; wieso sollte man es sonst tun.
Du sagst aber selbst, dass das faktisch fast überhaupt niemand mache. Wieso sollte XHTML 5 daran etwas ändern? Die HTML-5-Syntax dagegen ist ja gerade so ausgelegt, dass sie zwar streng Prüfbar ist, aber bei Fehlern nicht so zickig ist und dem Benutzer eine Fehlermeldung vorwirft. Genau hier wird ja angesetzt und Vereinheitlichung in der Browserwelt gefördert.
Der Rest ist leeres Gelaber. XML sei »neuer« - als was? HTML 5 ist eine komplette Neuentwicklung und hat mit alten Traditionen wie SGML zum Glück nix zu tun. Dabei ist XML auch schon fast 10 Jahre alt und als Plattform alles andere als unausgereift und experimentell.
Ich denke man meint hier tatsächlich neuer als SGML. Dass SGML und HTML aber nichts miteinander zu tun haben sollen ist falsch. HTML orientiert sich stark an SGML, geht aber darüber hinaus und definiert seine eigenen Regeln. Ein Teil der Syntax ist durchaus mit einer entsprechenden DTD abbildbar. Das ist übrigens auch bei XHTML 1.0 so.
Andererseits denke ich, dass man das nicht ganz so sehen muss wie du es verstanden hast. Nimm beispielsweise Schneegans' XHTML-Einmaleins. Er erklärt zwar zum Großteil, was man beachten sollte, wenn man XHTML einsetzt. Er übersieht aber auch wichtige Punkte, z.B. die Verarbeitung von Stylesheets und des DOMs, Feinheiten wie das tbody-Element, etc.
Verstand setze ich mal voraus; der Zweck von maschineller Überprüfung enthält sich dort, wo man selbigen nicht einsetzen will oder kann. Dafür setze ich doch Validatoren ein. Die tausenden HTML-Dateien von SELFHTML, von deren Validierung ich gerne erzähle, passten z.B. nicht in meinen Verstand. ;)
Das nächträglich noch zu machen wäre wohl nicht möglich und inzwischen auch unnötig. Aber ich muss dir wohl ein Punkt für diese Runde zugestehen. Auch Verstand fehlt vielen Autoren.
Es entsteht vielleicht der Eindruck, aber ich bin kein XHTML-Gegner. XML und Derivate sind eine wirklich tolle Sache. Ich bin nur der Meinung im Web hat wird HTML Marktführer bleiben. Wer die Strenge von XML wünscht, darf gerne seine Daten damit Speichern. Es ist ja (meines Wissens) möglich, diese Daten dann in HTML zu transformieren. So kann man die Vorteile beider Sprachen effektiv nutzen.
Gruß, Daniel.
-
Hallo,
ich wollte dich noch darauf aufmerksam machen, dass es hilfreich wäre, wenn du auf die mehrseitige Variante der Spezifikation verweisen würdest anstatt auf den Browserfresser :)
Gruß, Daniel.
-
-
-
Hallo,
Was sollte man also verwenden, wenn man es richtig machem möchte?
Oder ist dieser Gedankenzug unsinnig, hauptsache es kommt irgendwie
lesbar im Browser des Besuchers an?XHTML macht Sinn, wenn du die Vorteile von XML an irgendeiner Stelle nutzt.
Im Browser ist das, wie hier im Thread schon gesagt wurde, weder möglich (u.a. wegen IE) noch sinnvoll (wegen der fehlenden Fehlertoleranz). Es sei denn, du kannst durch serverseitige Logik garantieren, dass die Ausgabe wohlgeformtes XHTML ist. Browserseitig ist daher HTML-kompatibles XHTML 1.0 realistisch, der Mehraufwand mit application/xhtml+xml lohnt sich m.M.n. nur selten.
Bleiben also mögliche autorenseitige Vorteile, etwa die Verarbeitung der Dokumente durch alle möglichen Tools, die strenge Validierung gegen ein XML-Schema, das einfache Erlernen und Schreiben der eindeutigen XML-Syntax und so weiter. Ob du diese Möglichkeiten ausschöpfen willst, ist eine Frage, die du dir selber stellen musst.
Mathias