nicht angemeldet molily
Gunnar Bittersmann
JürgenB
Gunnar Bittersmann
Struppi
Gunnar Bittersmann
Struppi
Hi,
folgendes Problem.
Ein einem Javascript auf meiner Seite (ajax) funktioniert alles wunderbar ohne Doctype oder mit dem 4.01-HTML-Doctype.
Wenn ich jetzt nichts ausßer dem Doctype wie folgt ändere:
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
funktioniert das Javascript nicht mehr und ich bekomme bei folgender Zeile eine "is not defined" Fehlermeldung:
document.getElementById(blablablub).style.visibility = 'visible';
Wieso bzw. wie funktioniert dass auch bei obigem Doctype?
Gruß
Vermeer
Hi Vermeer,
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
funktioniert das Javascript nicht mehr und ich bekomme bei folgender Zeile eine "is not defined" Fehlermeldung:
document.getElementById(blablablub).style.visibility = 'visible';
Hast du es auch mal ohne die allererste Zeile
<?xml version="1.0" encoding="UTF-8" ?> probiert?
Die versetzt einige Browser in den Quirks-Mode.
Grüße,
Engin
GYRO
Wäre dann mein Doctype noch korrekt?
Hi Vermeer,
andere Möglichkeit:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de" lang="de">
<head>
<meta http-equiv="content-type" content="application/xhtml+xml; charset=utf-8" />
Das ist valide und dann läuft auch jedes JS.
Gruß
Antipitch
Hallo,
<meta http-equiv="content-type" content="application/xhtml+xml; charset=utf-8" />
Das ist widersinnig - dort gehört text/html hin.
(Wenn das Dokument wirklich als application/xhtml+xml ausgeliefert wird, hat der meta-Tag mit Kodierungsangabe sowieso keine Wirkung.)
Mathias
Moin molily,
Das ist widersinnig - dort gehört text/html hin.
du hast natürlich Recht. Neulich mal irgendwo aufgeschnappt, dass das von Nutzen sei. Glaub in irgend'nem Ajax Forum. Aber inzwischen auch nochmal die in diesem thread genannten Artikel gelesen (plus bißchen nachgedacht ;-) und: totaler Quatsch.
Gruß
Antipitch
Hello out there!
Die versetzt einige Browser in den Quirks-Mode.
Welcher mit JavaScript was zu tun hätte?
See ya up the road,
Gunnar
Sicher, dass getElementById() erst nach / mit onload verwendet wird?
Sicher, dass getElementById() erst nach / mit onload verwendet wird?
Ja, denn erstens funktionierts ja mit anderem Doctype, zweitens wird's erst per click aufgerufen.
Hallo Vermeer,
... zweitens wird's erst per click aufgerufen.
das heitere Raten geht weiter: kann es ein sein, dass du onClick und nicht onclick geschrieben hast? XHTML ist in Sachen Groß-Kleinschreibung recht pingelig.
Gruß, Jürgen
Hallo Vermeer,
... zweitens wird's erst per click aufgerufen.
das heitere Raten geht weiter: kann es ein sein, dass du onClick und nicht onclick geschrieben hast? XHTML ist in Sachen Groß-Kleinschreibung recht pingelig.
Gruß, Jürgen
Nein, ich habe onclick geschrieben, es wird ja ausgeführt, sonst würde ich ja auch die Fehlermedlung nicht bekommen.
Hello out there!
Wieso bzw. wie funktioniert dass auch bei obigem Doctype?
Ohne Quelltext (in diesem Fall wohl HTML und JavaScript; also Link zur Seite) bleiben alle Glaskugeln trübe.
See ya up the road,
Gunnar
Wenn ich jetzt nichts ausßer dem Doctype wie folgt ändere:
<?xml version="1.0" encoding="UTF-8" ?>
Diese Zeile versetzt den IE in den Quirksmodus ist also für den IE genau wie ohne Doctype.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
und im FF ist zumindest wenn es um JS geht egal ob du XHTML oder HTML schreibst.
funktioniert das Javascript nicht mehr und ich bekomme bei folgender Zeile eine "is not defined" Fehlermeldung:
Von welchem Browser reden wir?
document.getElementById(blablablub).style.visibility = 'visible';
Hast du dir mal das Ergebnis von document.getElementById(blablablub) angeschaut?
Struppi.
Hello out there!
und im FF ist zumindest wenn es um JS geht egal ob du XHTML oder HTML schreibst.
Nicht, wenn XHTML als XML verarbeitet wird. [PCDATA-CDATA]
See ya up the road,
Gunnar
Von welchem Browser reden wir?
Vom Firefox, neueste Version.
document.getElementById(blablablub).style.visibility = 'visible';
Hast du dir mal das Ergebnis von document.getElementById(blablablub) angeschaut?
Wie angeschaut? Ja schon, indem ich den Doctype ändere, dann passt nämlich alles und der Layer wird sichtbar.
Hast du dir mal das Ergebnis von document.getElementById(blablablub) angeschaut?
Wie angeschaut?
alert(document.getElementById(blablablub));
Sowas nennt man debugging und ist Essenziell beim programmieren.
Struppi.
Hi,
Warum überhaupt XHTML? Und wenn schon XHTML, warum dann als Mime-Type text/html parsen lassen? Dieser Artikel (schon etwas älter) erklärt, warum das keine gute Idee ist.
Don P
Hello out there!
Warum überhaupt XHTML?
Weil es Vorteile gegenüber HTML 4.01 hat. [Jendryschik, Schneegans]
Und wenn schon XHTML, warum dann als Mime-Type text/html parsen lassen?
Weil IEs zu blöd für 'application/xhtml+xml' sind und M$ nicht daran denkt, das zu ändern.
Welcher „jedoch hauptsächlich dadurch besticht, dass er vor allem einseitig und irreführend ist.“ [Jendryschik]
(schon etwas älter) erklärt, warum das keine gute Idee ist.
Diese Artikel [Jendryschik, Schneegans] erklären, warum das doch eine gute Idee ist.
See ya up the road,
Gunnar
Hi,
Warum überhaupt XHTML?
Weil es Vorteile gegenüber HTML 4.01 hat. [Jendryschik, Schneegans]
Habe nicht alles gelesen, dieser Jendryschik z.B. behauptet
sagenhaften Blödsinn:
"Konstrukte, die falsch zu sein scheinen (wie <p/Absatz/ statt <p>Absatz</p>, um ein wenig vorzugreifen), aber syntaktisch richtig sind"
Sowas ist nur dann syntaktisch gültiges SGML (wenn SHORTTAGs aktiviert sind, was in der Regel nicht so ist) und ist sicher kein gültiges HTML.
"Die Schreibweise <p>ä</p> ist ebenso gültig wie <p>ä</p>"
Ist sie nicht. Die Browser sind zwar sehr fehlertolerant und verstehen das, aber dadurch wird es noch lange nicht gültiges HTML.
Und wenn schon XHTML, warum dann als Mime-Type text/html parsen lassen?
Weil IEs zu blöd für 'application/xhtml+xml' sind und M$ nicht daran denkt, das zu ändern.
Eben. IEs sind leider am meisten verbreitet, und genau diese können die Vorteile von XHTML nicht nutzen. Man muss ihnen txt/html anbieten, was sie angesichts XHTML-Syntax in den Quirks-Modus bringt und das XHTML somit wertlos macht.
Hickson räumt ja ein, dass XHTML Vorteile gegenüber HTML hat, die aber eben sämtlich verloren gehen, wenn es als txt/html ausgeliefert wird.
Welcher „jedoch hauptsächlich dadurch besticht, dass er vor allem einseitig und irreführend ist.“ [Jendryschik]
Das wird einfach behauptet, aber in keiner Weise belegt.
Gruß, Don P
Hello out there!
Habe nicht alles gelesen, dieser Jendryschik z.B. behauptet
sagenhaften Blödsinn:
Da solltest du dich mal nicht so weit ausm Fenster lehnen!
"Konstrukte, die falsch zu sein scheinen (wie <p/Absatz/ statt <p>Absatz</p>, um ein wenig vorzugreifen), aber syntaktisch richtig sind"
Sowas ist nur dann syntaktisch gültiges SGML (wenn SHORTTAGs aktiviert sind, was in der Regel nicht so ist)
(*) Doch, genau das ist die Regel: “SHORTTAG YES” [HTML401 §20]
[…] und ist sicher kein gültiges HTML.
Solltest du immer noch dieser Ansicht sein, goto (*)
"Die Schreibweise <p>ä</p> ist ebenso gültig wie <p>ä</p>"
Ist sie nicht.
(**) Siehe 2. Anmerkung in [HTML401 §5.3]
[…] dadurch wird es noch lange nicht gültiges HTML.
Solltest du immer noch dieser Ansicht sein, goto (**)
IEs sind leider am meisten verbreitet, und genau diese können die Vorteile von XHTML nicht nutzen.
Die Vorteile von XHTML liegen ja auch beim _Autor_ der Webseite, nicht beim Nutzer.
Man muss ihnen txt/html anbieten, was sie angesichts XHTML-Syntax in den Quirks-Modus bringt
(***) Das ist Quatsch. Eine XML-Deklaration ist nur dann erforderlich, wenn eine andere Codierung als UTF-8 oder UTF-16 verwandt wird und diese nicht auf andere Weise (HTTP-Header) angegeben wird. [XML §F.1]
und das XHTML somit wertlos macht.
Solltest du immer noch dieser Ansicht sein, goto (***)
Hickson räumt ja ein, dass XHTML Vorteile gegenüber HTML hat, die aber eben sämtlich verloren gehen, wenn es als txt/html ausgeliefert wird.
Wie gesagt: Die Vorteile von XHTML liegen ja beim _Autor_ der Webseite, nicht beim Nutzer.
Ich wiederhole das gern nochmal. ;-)
Apropos wiederholen: Du schriebst zum 2. Mal 'txt/html'; da sei der Hinweis gestattet, dass es 'text/html' heißt.
See ya up the road,
Gunnar
Hello!
Habe nicht alles gelesen, dieser Jendryschik z.B. behauptet
sagenhaften Blödsinn:Da solltest du dich mal nicht so weit ausm Fenster lehnen!
Dann mach ich das Fenster halt wieder zu, halte es trotzdem für Blödsinn.
Sowas ist nur dann syntaktisch gültiges SGML (wenn SHORTTAGs aktiviert sind, was in der Regel nicht so ist)
(*) Doch, genau das ist die Regel: “SHORTTAG YES” [HTML401 §20]
(1)Weia, ich bin entsetzt. Dann ist diese SGML-Deklaration halt foobar, "Für'n A...".
Habe schon lange mit SGML und HTML zu tun, aber sowas ist mir bis jetzt nicht untergekommen.
Wenn einem als Autor Validität wichtig ist, verwendet man einen "gescheiten" Validator, der solches Zeug natürlich anmeckert, auch wenn es laut SGML-Deklaration vielleicht noch durchginge.
XHTML nimmt einem diese Arbeit nur clientseitig ab, weil konforme Clients ungültiges Markup gleich anmeckern. Wieso sollte das aber besser sein, als gleich einen richtigen Validator zu benutzen?
[…] und ist sicher kein gültiges HTML.
Solltest du immer noch dieser Ansicht sein, goto (*)
(2)Ok, ich korrigiere: kein brauchbares HTML.
"Die Schreibweise <p>ä</p> ist ebenso gültig wie <p>ä</p>"
(**) Siehe 2. Anmerkung in [HTML401 §5.3]
[…] dadurch wird es noch lange nicht gültiges HTML.
Solltest du immer noch dieser Ansicht sein, goto (**)
Siehe (1) und (2).
IEs sind leider am meisten verbreitet, und genau diese können die Vorteile von XHTML nicht nutzen.
Die Vorteile von XHTML liegen ja auch beim _Autor_ der Webseite, nicht beim Nutzer.
(3)Ist es denn ein Vorteil für den Autor, wenn er sich perfekt in einer Sprache äussern kann, die die meisten nicht richtig verstehen?
Hickson räumt ja ein, dass XHTML Vorteile gegenüber HTML hat, die aber eben sämtlich verloren gehen, wenn es als txt/html ausgeliefert wird.
Wie gesagt: Die Vorteile von XHTML liegen ja beim _Autor_ der Webseite, nicht beim Nutzer.
Siehe (3).
Apropos wiederholen: Du schriebst zum 2. Mal 'txt/html'; da sei der Hinweis gestattet, dass es 'text/html' heißt.
Ja sorry, ein typo, beim cut/paste auch noch wiederholt :(
Gruß, Don P
Hello out there!
(1)Weia, ich bin entsetzt. Dann ist diese SGML-Deklaration halt foobar, "Für'n A...".
Dann kreide den Bödsinn nicht Jendryschik & Schneehans an, sondern – ähm – Tim Berners-Lee!
Wenn einem als Autor Validität wichtig ist, verwendet man einen "gescheiten" Validator, der solches Zeug natürlich anmeckert, auch wenn es laut SGML-Deklaration vielleicht noch durchginge.
Sollte ein Validator mit künstlicher Intelligenz ausgestattet sein? Oder einfach nur seine Arbeit tun, das Wortproblem zu lösen?
(3)Ist es denn ein Vorteil für den Autor, wenn er sich perfekt in einer Sprache äussern kann, die die meisten nicht richtig verstehen?
Nein. Eben das spricht ja gegen HTML.
See ya up the road,
Gunnar
Hallo,
Wenn einem als Autor Validität wichtig ist, verwendet man einen "gescheiten" Validator, der solches Zeug natürlich anmeckert, auch wenn es laut SGML-Deklaration vielleicht noch durchginge.
Genau auf das Problem soll XHTML doch die Lösung sein - und nicht irgendwelche nicht-standardisierten Zusätze für Validatoren. Sondern einfach eine saubere, festgelegte Definition der Syntax.
In HTML 4 kann ich nicht einfach die vorgegebenen DTD nehmen und ein Dokument dagegen prüfen, dabei kommt unter Umständen Murks heraus, weil SGML sowie die SGML-Deklaration doof sind.
Sicher kann ich da einen Validator bauen, der mehr ein Lint ist, also der viel mehr macht, als das das Dokument gegen Standards (DTD) zu checken, nämlich auf »guten, praxiskompatiblen Code« - meiner persönlichen Definition nach - prüft. Das ist aber nunmal was ganz anderes.
XHTML nimmt einem diese Arbeit nur clientseitig ab, weil konforme Clients ungültiges Markup gleich anmeckern. Wieso sollte das aber besser sein, als gleich einen richtigen Validator zu benutzen?
Da wirfst du alles durcheinander. Der Vorteil bei XHTML ist nicht, dass kaputte Seiten kaputt angezeigt werden, sondern dass ich keinen speziellen Validator brauche, der mehr als einfach nur validiert, um solche Fehler zu finden. Ich kann die »eingebauten« Features verwenden, um die meisten Fehler zu finden. http://aktuell.de.selfhtml.org/weblog/xhtml-validierung
Mathias
Hallo,
Habe nicht alles gelesen, dieser Jendryschik z.B. behauptet
sagenhaften Blödsinn:
Nicht wirklich. Man kann zwar der Auffassung sein, dass seine Argumente die anderen Argumente nicht wettmachen, aber Blödsinn sind sie deswegen noch lange nicht.
"Konstrukte, die falsch zu sein scheinen (wie <p/Absatz/ statt <p>Absatz</p>, um ein wenig vorzugreifen), aber syntaktisch richtig sind"
Sowas ist nur dann syntaktisch gültiges SGML (wenn SHORTTAGs aktiviert sind, was in der Regel nicht so ist) und ist sicher kein gültiges HTML.
Doch. HTML ist eine SGML-Applikation, siehe HTML 4.01 § 4.2 SGML:
| HTML 4 is an SGML application conforming to International Standard ISO 8879 -- Standard Generalized Markup Language SGML (defined in [ISO8879]).
Ferner ist SHORTTAG aktiviert, siehe die SGML-Deklaration zu HTML (http://www.w3.org/TR/html401/HTML4.decl):
| SHORTTAG YES
Und Michael Jendryschik schreibt selbst, dass:
| [Konstrukte, die] aber syntaktisch richtig sind und dennoch von keinem
| modernen Browser richtig verstanden werden. Webautoren verwenden diese
| Konstrukte zumeist unabsichtlich und wundern sich dann über eine falsche
| Darstellung, die aus »Fehlern« resultiert, die sie auch mithilfe von
| Werkzeugen wie Validatoren nicht aufspüren können, weil es sich rein
| syntaktisch nicht um Fehler handelt.
Die Kritik ist also nicht so gemeint, dass irgendjemand tatsächlich <p/bla/ versucht zu benutzen, sondern dass man derartige Konstrukte, sollten sie sich aus Versehen in den Code schleichen, nicht mit automatisierten Tools wie Validatoren finden kann, die andere Syntaxfehler problemlos finden.
Ferner: Genau diese Features machen es auch so schwierig, einige Validator-Fehlereldungen zu verstehen. Siehe z.B. folgende Links:
http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fwww.christian-seiler.de%2Ftemp%2Ftest-hr-1.html
http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fwww.christian-seiler.de%2Ftemp%2Ftest-hr-2.html
Einziger Unterschied zwischen beiden Seiten ist, dass in der einen <hr> steht, in der anderen <hr /> (also XHTML-Syntax, obwohl HTML4 im DOCTYPE steht). Was passiert hier? Das /-Zeichen beendet den <hr>-Tag im zweiten Beispiel, da das hr-Element in HTML leer ist, ist das auch sofort wieder zu. Damit bleibt ein > als Textknoten direkt innerhalb von <body> und das ist in HTML4 Strict nicht erlaubt.
Gut, die Entwickler vom Validator haben zusätzliche Informationen zu der Fehlermeldung hinzugefügt, dass man zumindest jetzt eine Ahnung hat, was diese Fehlermeldung verursacht, allerdings bleibt sie dennoch ziemlich obskur.
Andererseits erkennt ein Validator z.B.
<p>Hallo<br /
Test</p>
nicht als falsch an (er sieht <p>Hallo<br>Test</p>), ein Browser wird jedoch Probleme haben, das korrekt zu interpretieren.
"Die Schreibweise <p>ä</p> ist ebenso gültig wie <p>ä</p>"
Ist sie nicht. Die Browser sind zwar sehr fehlertolerant und verstehen das, aber dadurch wird es noch lange nicht gültiges HTML.
http://www.christian-seiler.de/temp/test-entity-inv.html ->
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.christian-seiler.de%2Ftemp%2Ftest-entity-inv.html&charset=(detect+automatically)&doctype=Inline&ss=1&group=0&verbose=1
Woher nimmst Du die Auffassung, dass das kein gültiges HTML sei?
Eben. IEs sind leider am meisten verbreitet, und genau diese können die Vorteile von XHTML nicht nutzen. Man muss ihnen txt/html anbieten, was sie angesichts XHTML-Syntax in den Quirks-Modus bringt und das XHTML somit wertlos macht.
Nein. XHTML ist nicht wertlos - auch wenn es als text/html ausgeliefert wird, sind zwar die Vorteile im Browser komplett verloren, jedoch gibt es diverse andere Vorteile, die bleiben:
* Validatoren können trotz des Content-Types einen XML-Parser statt eines
SGML-Parsers verwenden und somit viel mehr Syntaxfehler finden, als in
HTML.
* Man kann HTML-Seiten - wenn sie XHTML sind - viel leichter weiter-
verarbeiten. Zum Beispiel kann man ja innerhalb eines Scriptes durchaus
explizit sagen "hol Dir folgende Seite, speichere den Inhalt in einen
String und jage den durch einen XML-Parser" - die gibt's wie Sand am
Meer, dann kann man auch noch XSLT und Gedöns drüberjagen und hat eine
GANZE Menge Möglichkeiten - bei normalem HTML wird das dann schon etwas
schwieriger (wenn es auch inzwischen relativ viele HTML-Parser gibt, die
man einigermaßen brauchbar verwenden kann).
Viele Grüße,
Christian
Grütze .. äh ... Grüße!
Habe nicht alles gelesen, dieser Jendryschik z.B. behauptet
sagenhaften Blödsinn:
Ähnliches auch bei Schneegans. Ich hab schon befürchtet, mit meiner kritischen Haltung gegenüber der Machart dieser vielverlinkten Seiten ziemlich alleine zu sein, aber diese "XHTML ist so viel besser-Fanseiten" sind genau das, was sie andererseits der Kritikerseite vorwerfen: einseitig und irreführend.
Da wird, wie du schon richtig angemerkt hast, möglichst wirr konstruiertes und nicht gültiges HTML gegen sauberes XHTML gestellt. Ich behaupte: Der einzige (für mich) akzeptable Vergleich bezüglich der _Vorzüge_ *kann* nur zwischen HTML 4.01 strict und XHTML stattfinden. Aber damit würden schon die meisten der angeblichen Vorteile wegfallen und recht wenig Substanzielles übrigbleiben.
Und solange es nicht möglich ist, XHTML korrekt auszuliefern (das heißt für mich *sowohl* Prolog wie auch application/xhtml+xml) ... welche Vorteile, die nicht rein akademischer Natur sind, bleiben da effektiv noch?
Ich habe vor einiger Zeit angefangen, meine Seiten auf XHTML umzustellen, habe das aber aufgrund der Problematik IE schnell wieder fallenlassen, weil man sich einfach einige gravierende Nachteile einhandelt, was die XHTML-Fanseiten in der Regel verschweigen oder nur in Nebensätzen anklingen lassen. Also habe ich HTML 4.01 Strict gewählt, das tut es genauso.
Mir wäre es allerdings schon lieber, wenn möglichst viele (und wichtige) Webseiten XHTML benutzen würden, und zwar *ausschließlich* korrekt ausgeliefert. Denn dann müßte der IE irgendwann angepasst werden, eine andere Sprache verstehen die Ignoranten einer gewissen Softwarefirma anscheinend nicht.
Cü
Kai
Yerf!
Und solange es nicht möglich ist, XHTML korrekt auszuliefern (das heißt für mich *sowohl* Prolog wie auch application/xhtml+xml) ... welche Vorteile, die nicht rein akademischer Natur sind, bleiben da effektiv noch?
Die serverseitige Verarbeitung als XML? Oder kannst du mir entsprechende Tools und Bibliotheken nennen, die auf Basis von SGML/HTML das gleiche leisten wie für XML? Wozu wurden denn dann XML überhaupt erfunden?
Ich habe vor einiger Zeit angefangen, meine Seiten auf XHTML umzustellen, habe das aber aufgrund der Problematik IE schnell wieder fallenlassen, weil man sich einfach einige gravierende Nachteile einhandelt, was die XHTML-Fanseiten in der Regel verschweigen oder nur in Nebensätzen anklingen lassen. Also habe ich HTML 4.01 Strict gewählt, das tut es genauso.
Wenn man als text/html ausliefert und den eh optionalen Prolog weglässt spielt auch der IE mit, oder übersehe ich etwas?
Andersrum gefragt, was kann HTML4, was mit XHTML nicht geht? Was verliere ich, wenn ich auf den Komfort von XML nicht verzichten will?
Gruß,
Harlequin
Grütze .. äh ... Grüße!
Yerf!
Ganz meine Meinung ;)
... welche Vorteile, die nicht rein akademischer Natur sind, bleiben da effektiv noch?
Die serverseitige Verarbeitung als XML? [..]
Ok, das ist durchaus einleuchtend.
Wenn man als text/html ausliefert und den eh optionalen Prolog weglässt spielt auch der IE mit, oder übersehe ich etwas?
Das habe ich auch nicht bestritten. Nur fällt dann für die Nutzer der Vorteil des XML-Parsers weg, wenn man nicht, wie inzwischen in einem Beitrag genannt vorgeht und auf dem Server die Akzeptanz von application/xhtml+xml abfragt und dementsprechend ausliefert. *Das* ist eine schöne saubere Lösung für eines der beiden IE-Probleme.
Andersrum gefragt, was kann HTML4, was mit XHTML nicht geht? Was verliere ich, wenn ich auf den Komfort von XML nicht verzichten will?
Wie gesagt .. ich habe nichts gegen XHTML. Mir ging es bei meinem Beitrag auch weniger um XHTML vs. HTML, sondern eher um die argumentative "Bauernfängermethode" der genannten Seiten, nur nöglichst unsauberes HTML gegen wohlgeformtes XTHML zu zeigen, um damit zu zugunsten von XHTML zu argumentieren. *Das* regt mich auf, weil es dem Leser vorgaukelt, daß man ohne XHTML nicht sauber auszeichen kann.
Cü
Kai
Grüssitsch!
Mir ging es [...] eher um die argumentative "Bauernfängermethode" der genannten Seiten, nur nöglichst unsauberes HTML gegen wohlgeformtes XTHML zu zeigen, um damit zu zugunsten von XHTML zu argumentieren. *Das* regt mich auf, weil es dem Leser vorgaukelt, daß man ohne XHTML nicht sauber auszeichen kann.
Genau. Es gibt natürlich auch gute Gründe für XHTML, aber die relativieren sich eben sehr, wenn man es dem "dummen" IE als text/html anwerfen muss.
Sicher kann man in HTML auch sauber auszeichnen. Genau wie in JavaScript, wo man eigentlich nicht jede Anweisung mit Semikolon abschließen muss oder jeden if-else-Zweig als Block notieren muss, aber es ist eben grundsätzlich besser, wenn man es macht. Auch JavaScript ann man durch einen geeigneten Validierer schicken, der solche Unsauberkaiten dann aufzeigt.
Don P
Hallo,
Es gibt natürlich auch gute Gründe für XHTML, aber die relativieren sich eben sehr, wenn man es dem "dummen" IE als text/html anwerfen muss.
Halte ich für absoluten Unsinn. Ob irgendein Browser application/xhtml+xml versteht oder nicht, das ist für mich kein letztlicher Grund für oder gegen XHTML.
Ich würd immer XHTML schreiben und nie XHTML als solches ausliefern, wenn ich hundertprozentig durch irgendwelche Frameworks, die gar nichts anderes können, als gültiges XML auszugeben, garantieren könnte, dass es wohlgeformt ist.
Ich sehe auch nicht, warum das ein Problem ist. Ich verwende XHTML, weil ich auf Autoren- und Serverseite damit wunderbar arbeiten kann und es vieles vereinfacht. Dass das Dokument dann auch im Browser als XHTML verarbeitet wird und nicht als Tag-Soup, ist für mich relativ unbedeutend. Es bringt sogar eher Probleme mit sich, weil z.B. im CSS- und JavaScript-Bereich vieles anders läuft.
Mathias
Yerf!
Wie gesagt .. ich habe nichts gegen XHTML. Mir ging es bei meinem Beitrag auch weniger um XHTML vs. HTML, sondern eher um die argumentative "Bauernfängermethode" der genannten Seiten, nur nöglichst unsauberes HTML gegen wohlgeformtes XTHML zu zeigen, um damit zu zugunsten von XHTML zu argumentieren. *Das* regt mich auf, weil es dem Leser vorgaukelt, daß man ohne XHTML nicht sauber auszeichen kann.
Wobei der Artikel von Ian Hickson da auch nicht besser ist. Der führt z.B. die Verrenkungen für JavaScript an, die eh komplett überflüssig sind, da Scripte in externen Dateien besser aufgehoben sind.
Bei nüchterner Betrachtung kommt für mich heraus, dass der Author diejenige Sprache wählen sollte, die ihm mehr Vorteile bringt. Wer seit jeher mit HTML umgeht und keine Vroteile aus XML ziehen kann soll ruhig dabei bleiben. Aber gerade die Verarbeitung als XML bietet einige interessante Perspektiven (für mich z.B. den serverseitigen Aufbau des Dokumentes als DOM-Tree). Für den User kann es *momentan* noch egal sein, da der IE das eh nicht kann. Aber eine zunehmnde Verbreitung von XHTML könnte auch da etwas bewegen, weshalb ich abschließen bemerken will: ein Umstieg kann nicht schaden, denn irgendwann werden wir uns fragen, wie man ohne eine direkte Einbettung von SVG in XHTML überhaupt je Webseiten erstellen konnte ;-)
Gruß,
Harlequin
Grütze .. äh ... Grüße!
Bei nüchterner Betrachtung kommt für mich heraus, dass der Author diejenige Sprache wählen sollte, die ihm mehr Vorteile bringt. Wer seit jeher mit HTML umgeht und keine Vroteile aus XML ziehen kann soll ruhig dabei bleiben.
Für Viele ist es auch völlig unerheblich, da soll nur $Inhalt dargestellt werden und fertig. Ich wäre schon froh, wenn ein signifikanter Anteil Sites überhaupt validen Code vorweisen könnten.
Leider ist wiederum XHTML für Seiten, die auf Servern ohne Eingriffsmöglichkeit [1] des Nutzers liegen, nur "bedingt" geeignet, da man dort eine entsprechende Auslieferung nicht realisieren kann und fest an text/html gebunden ist. Und das ist im privaten Bereich sicherlich nicht selten, wie bei mir auch [2].
weshalb ich abschließen bemerken will: ein Umstieg kann nicht schaden, denn irgendwann werden wir uns fragen, wie man ohne eine direkte Einbettung von SVG in XHTML überhaupt je Webseiten erstellen konnte ;-)
So wie vor 10 Jahren noch kaum jemand gedacht hat, daß man Webseiten ganz ohne <font>, align=, <center> usw. erstellen kann ;)
Wenn man seine Webseiten sauber ausgezeichnet hat (HTML 4.01 strict und sauberer Aufbau) sollte der Aufwand einer Umstellung auch nicht sonderlich hoch sein. Neuer Doctype, inhaltsleere Elemente schließen und ein paar andere Anpassungen (namespace usw) sollten
schon das meiste erschlagen. Und zur Not gibt es ja noch tidy ;)
Cü
Kai
[1] Serverkonfiguration und z.B. eigene PHP_Scripte
[2] Natürlich könnte ich das ändern, aber für eine Zielgruppe von vielleicht 5-10 Personen, die auch nur ab und zu mal reinschauen, das 3-4fache monatlich zahlen lohnt sich für mich nicht.
Hello out there!
Da wird, wie du schon richtig angemerkt hast, möglichst wirr konstruiertes und nicht gültiges HTML gegen sauberes XHTML gestellt.
Nein, wie ich schon angemerkt hatte, ist das alles valides HTML.
Darum geht es ja gerade: dass eigentlich syntaktisch korrektes HTML von Browsern nicht richtig interpretiert wird. Oder richtig interpretiert wird, aber halt völlig anders als vom Webseitenautor beabsichtigt. Und kein Validator meckert ... Fehlersuche schwierig.
(*) Ein Problem, dass bei Verwendung von XHTML nicht auftritt – Vorteil für den Autor.
Ich behaupte: Der einzige (für mich) akzeptable Vergleich bezüglich der _Vorzüge_ *kann* nur zwischen HTML 4.01 strict und XHTML stattfinden.
Das ist Unsinn. Man kann XHTML 1.0 Transitional ebenso mit HTML 4.01 Transitional vergleichen wie XHTML 1.0 Strict mit HTML 4.01 Strict.
(Und die Frameset-Variante gibt’s auch für beides. Das aber nur der Vollständigkeit halber, weil man die ja eigentlich nicht braucht. >;-))
Und solange es nicht möglich ist, XHTML korrekt auszuliefern (das heißt für mich *sowohl* Prolog
Natürlich mit Prolog [XML §2.8]: die DOCTYPE-Angabe sollte ja nicht fehlen. Die XML-Deklaration ist optional.
wie auch application/xhtml+xml
HTML-kompatibles XHTML [XHTML1 §C] als 'text/html' auszuliefern, ist auch korrekt.
... welche Vorteile, die nicht rein akademischer Natur sind, bleiben da effektiv noch?
(*)
XHTML ist einfacher als HTML, bietet daher weniger Möglichkeiten, Fehler zu machen.
Mal andersrum nachgefragt: Welche Nachteile siehst du denn in XHTML 1.0?
See ya up the road,
Gunnar
Grütze .. äh ... Grüße!
Da wird, wie du schon richtig angemerkt hast, möglichst wirr konstruiertes und nicht gültiges HTML gegen sauberes XHTML gestellt.
Nein, wie ich schon angemerkt hatte, ist das alles valides HTML.
Als ich den Beitrag schrieb, hatte ich den deinigen noch nicht.
Ich behaupte: Der einzige (für mich) akzeptable Vergleich bezüglich der _Vorzüge_ *kann* nur zwischen HTML 4.01 strict und XHTML stattfinden.
Das ist Unsinn. Man kann XHTML 1.0 Transitional ebenso mit HTML 4.01 Transitional vergleichen wie XHTML 1.0 Strict mit HTML 4.01 Strict.
Ich meinte das schon genau so, hab es nur irgendwie nicht geschrieben. Also jeweils HTML mit der entsprechenden XHTML-Variante vergleichen.
(Und die Frameset-Variante gibt’s auch für beides. Das aber nur der Vollständigkeit halber, weil man die ja eigentlich nicht braucht. >;-))
Frames sind eval() ähem ... so ähnlich jedenfalls :)
Transitional braucht man -meiner Meinung nach- allerdings auch nur in bestimmten Sonderfällen, ansonsten sollte man direkt "strict" auszeichnen.
wie auch application/xhtml+xml
HTML-kompatibles XHTML [XHTML1 §C] als 'text/html' auszuliefern, ist auch korrekt.
Es mag korrekt sein, aber erstens ist irgendwie ein Kniefall vor dem IE (was mich schon mal _grundsätzlich_ unheimlich stört [1], besonders da es unvermeidlich ist) und zweitens ist es irgendwie einfach meine Grund-Einstellung: wenn schon XHTML, dann auch so ausliefern. Bin da wohl ziemlich stur, genauso wie bei meiner Einstellung "nur strict ist wirklich gut". Man kann diese Haltung zwar leider nicht immer durchziehen, aber mich ärgert es dann halt jedes Mal.
Cü
Kai
[1] Ich hasse das Teil einfach nur
Das ist Unsinn. Man kann XHTML 1.0 Transitional ebenso mit HTML 4.01 Transitional vergleichen wie XHTML 1.0 Strict mit HTML 4.01 Strict.
Ich meinte das schon genau so, hab es nur irgendwie nicht geschrieben. Also jeweils HTML mit der entsprechenden XHTML-Variante vergleichen.
sorry wenn ich mich jetzt einfach so einmische, aber ist das nicht irgendwie grütze?
sollte man nicht html 4.01 strict mit xhtml 1.0 transitional vergleichen? ansich ist xhtml 1.0 trans doch die an xml genäherte variante von html 4.01 strict
in xhtml 1.0 strict hab ich wesentlich weniger markup zur verfügung als in html 4.01 strict, da ist einiges rausgefallen
prinzipiell sind für mich die vor und nachteile einerlei, ich schreibe die seiten in xhtml 1.0 transitional und schicks als text/html raus, es hat für mich keine nachteile und auch keine vorteile
die bekannten probleme mit inline stylesheets oder scripten hab ich nicht, da ich keine verwende ;)
Hello out there!
sorry wenn ich mich jetzt einfach so einmische, aber ist das nicht irgendwie grütze?
Dass du dich einmischst? Naja, pflücken wir das mal auseinander:
sollte man nicht html 4.01 strict mit xhtml 1.0 transitional vergleichen?
Nein.
ansich ist xhtml 1.0 trans doch die an xml genäherte variante von html 4.01 strict
Nein. XHTML 1.0 Transitional ist die Neuformulierung von HTML 4.01 Transitional in XML; XHTML 1.0 Strict ist die Neuformulierung von HTML 4.01 Strict in XML. [XHTML1 §1]
in xhtml 1.0 strict hab ich wesentlich weniger markup zur verfügung als in html 4.01 strict,
Nicht dass ich wüsste.
da ist einiges rausgefallen
Was da wäre?
See ya up the road,
Gunnar
sollte man nicht html 4.01 strict mit xhtml 1.0 transitional vergleichen?
Nein.
ansich ist xhtml 1.0 trans doch die an xml genäherte variante von html 4.01 strict
Nein. XHTML 1.0 Transitional ist die Neuformulierung von HTML 4.01 Transitional in XML; XHTML 1.0 Strict ist die Neuformulierung von HTML 4.01 Strict in XML. [XHTML1 §1]
wieder was gelernt, xhtml 1.0 transitional ist in der tat zur übersetzung von html 3.2 in xhtml gedacht
in xhtml 1.0 strict hab ich wesentlich weniger markup zur verfügung als in html 4.01 strict,
Nicht dass ich wüsste.
da ist einiges rausgefallen
Was da wäre?
mit "rausgefallen" meinte ich die xml-näherung - da man in html noch "weite teile" von sgml zur verfügung hatte, war markup wie
<ul>
<li>blah blah
<li>blah
</ul>
noch völlig korrekt
da xml ja ansich nur eine teilmenge von sgml darstellt, ist die syntax viel strenger geworden und man darf sich derartige konstrukte nicht mehr erlauben
hat wohl den vorteil, dass der xml-parser hier wesentlich schneller werkeln kann und man mit einem validator einfacher fehler finden kann, da man sich ja nie drauf verlassen konnte, dass ein browser valides html (bzw sgml) wirklich korrekt interpretiert (und dann noch darstellt), das problem hat man mit xml bzw xhtml nicht mehr so arg denke ich
Hallo,
IEs sind leider am meisten verbreitet, und genau diese können die Vorteile von XHTML nicht nutzen. Man muss ihnen txt/html anbieten, was sie angesichts XHTML-Syntax in den Quirks-Modus bringt und das XHTML somit wertlos macht.
Wenn XHTML als text/html wertlos ist, welche echten Werte brächte denn XHTML mit application/xhtml+xml deiner Meinung nach?
Hickson räumt ja ein, dass XHTML Vorteile gegenüber HTML hat, die aber eben sämtlich verloren gehen, wenn es als txt/html ausgeliefert wird.
Hickson was gegen XHTML als text/html, weil dabei Dokumente herauskommen, die weder richtiges XHTML noch richtiges HTML sind. Das ist auch teilweise richtig, denn die wenigsten XHTML-Dokumente da draußen werden tatsächlich und könnten nie als XHTML verarbeitet werden:
»If you ever switch your documents that claim to be XHTML from text/html to application/xhtml+xml, then you will in all likelyhood end up with a considerable number of XML errors, meaning your content won't be readable by users. (See above: most of these documents do not validate.)«
Insofern war text/html ein Reinfall hinsichtlich der Verbreitung von XML. Das hindert aber niemand, den Fehler nicht selbst zu wiederholen.
Mathias
Hello out there!
Und wenn schon XHTML, warum dann als Mime-Type text/html parsen lassen?
Weil IEs zu blöd für 'application/xhtml+xml' sind und M$ nicht daran denkt, das zu ändern.
Die hohe Schule wäre es, XHTML für Gourmets, die 'application/xhtml+xml' zu schätzen wissen (akzeptieren), mit ebendiesem Typen auszuliefern. Gourmands wie IEs bekommen 'text/html' zum Fraß. (content negotiation) [Meiert, Schneegans]
See ya up the road,
Gunnar
Moin.
Und wenn schon XHTML, warum dann als Mime-Type text/html parsen lassen?
Weil IEs zu blöd für 'application/xhtml+xml' sind und M$ nicht daran denkt, das zu ändern.
Aber 'application/xml' versteht der IE durchaus. Und wenn man ihm einen leicht modifizierten Doctype
Kai345
suit
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd" [
<!ENTITY % xhtml-prefw-redecl.mod "" >
<!ENTITY % xhtml-postfw-redecl.mod "" >
]>
vorsetzt, kann er es sogar parsen - was aber leider eine halbe Ewigkeit dauert :(
Stylesheets kann man über <?xml-stylesheet ... ?> einfügen.
Mit Firefox' 'html.css' sieht das Ergebnis schon ziemlich nach HTML aus (Tabellen z.B. werden fehlerhaft angezeigt).
Dass Hyperlinks und :hover nicht mehr funktionieren, lässt sich per Behaviors beheben.
Jemandem, der sich etwas mit dem IE auskennt, sollte es durchaus möglich sein, einen XHTML Patch im Stil von Dean Edwards' IE7 zu erstellen - ich frage mich, warum das noch niemand getan hat (oder habe ich das nur nicht mitbekommen?)...
Christoph