nicht angemeldet Tobias Kloth
molily
Felix Riesterer
molily
Felix Riesterer
Tim Tepaße
Henryk Plötz
molily
Hallo,
seit einiger Zeit beschäftige ich mit HTML und CSS.
Kann mir jemand mit einfachen Worten den Unterschied zwischen HTML und XHTML erklären.
Danke im voraus für jede verwertbare Antwort.
Ahoi.
Hallo,
Kann mir jemand mit einfachen Worten den Unterschied zwischen HTML und XHTML erklären.
was hast du an http://de.selfhtml.org/html/xhtml/unterschiede.htm nicht verstanden?
Grüße aus Nürnberg
Tobias
Danke für den Link.
puts "Hallo " + gets.chomp + "."
?> HerrKaleu
=> Hallo HerrKaleu.
seit einiger Zeit beschäftige ich mit HTML und CSS.
Sehr gut.
Kann mir jemand mit einfachen Worten den Unterschied zwischen HTML und XHTML erklären.
HTML ist herkömmlich und wird von so gut wie allen UserAgents verstanden.
XHTML ist komplett in XML neu formuliertes HTML und kann dementsprechend auch mit XML-Tools verarbeitet werden, der Vorteil von XML ist die enorme Interoperabilität.
Einen schönen Dienstag noch.
Gruß, Ashura
Hallo HerrKaleu
seit einiger Zeit beschäftige ich mit HTML und CSS.
Das ist hier bekannt.
Kann mir jemand mit einfachen Worten den Unterschied zwischen HTML und XHTML erklären.
Gute Links hast Du bereits bekommen. Schreibe valides sauberes XHTML 1.1 mit validem CSS und die Beförderung zum Korvettenkapitän rückt in Reichweite.
Freundliche Grüße
Vinzenz
Schreibe valides sauberes XHTML 1.1
Das ist Unsinn. Keep it simple, stupid.
Wer in keinster Weise von XHTML wirklich handfest profitiert, soll HTML schreiben, weil XHTML einen Rattenschwanz an Themen nach sich zieht, in die man sich einarbeiten muss, um XHTML zu verstehen und kompetent gebrauchen zu können. Die meisten XHTML-Dokumente im Web sind z.B. kein gültiges XML und niemand macht von den potenziellen Vorteilen Gebrauch. Es ist unnötig, sich dieses Spezzialwissen anzueignen, wenn die Ausbeute gegen Null geht. Deshalb: Don’t call XHTML, XHTML calls you!
Wer in keinster Weise von der XHTML-Modularisierung Gebrauch macht, wer keine Ruby-Annotations braucht, wer Webseiten für HTML-Browser schreibt, den braucht insbesondere XHTML 1.1 nicht zu interessieren, da es momentan nur Probleme nach sich zieht. (Mit meinen Auslassungen zu dem Thema im Archiv könnte man Bände füllen.)
Man schreibe meinetwegen HTML 2.0, wenn man damit zurechtkommst und es den Anforderungen gerecht wird.
Mathias
Hallo molily,
Das ist Unsinn. Keep it simple, stupid.
[...]
Man schreibe meinetwegen HTML 2.0, wenn man damit zurechtkommst und es den Anforderungen gerecht wird.
Du hast sicherlich recht, aber ...
... ich hatte nicht umsonst den Themenbereich auf "Menschelei" geändert.
Freundliche Grüße
Vinzenz, dessen Postingqualität heute Abend sehr zu wünschen übrig lässt.
Das war eben meine Frage.
Ich habe zwei Internetseiten in HTML 4.01 geschrieben.
Einige Element auch mit CSS formatiert.
(Bin ja noch Anfänger)
Nun habe ich mir überlegt, was der Unterschied zwischen HTML und XHTML ist, und ob es sich lohnt meine Site in XHTML umzuschreiben.
Da ich aber, was HTML angeht, noch Anfänger bin, wollte ich wissen was halt "anders" ist, wenn die Site in XHTML geschrieben ist.
Welche Vorteile hätte XHTML???
Wird sie auch von allen Browsern gleich dargestellt etc.?
Deswegen nochmal die Frage:
Kann mir jemand mit "einfachen" Worten den Unterschied zwischen HTML und XHTML erklären.
Habe keine Ahnung was XML, oder Parser sind, sorry.
Ahoi.
puts "Hallo " + gets.chomp + "."
?> HerrKaleu
=> Hallo HerrKaleu.
Deswegen nochmal die Frage:
Kann mir jemand mit "einfachen" Worten den Unterschied zwischen HTML und XHTML erklären.
Einfacher als im entsprechenden Kapitel in SelfHTML geht es kaum zu erklären.
Wenn du dich wirklich mit HTML befassen möchtest, solltest du dir ein Grundwissen erarbeiten, worauf Verständnis und Auffassungsgabe gründen können.
Einen schönen Mittwoch noch.
Gruß, Ashura
Hallo Ashura,
Einfacher als im entsprechenden Kapitel in SelfHTML geht es kaum zu erklären.
Habe das Kapitel gelesen, mir fehlt anscheinend noch eine Menge Grundwissen um alles zu verstehen.
Wenn du dich wirklich mit HTML befassen möchtest,
mache ich bereits, bin aber noch ganz am Anfang.
solltest du dir ein Grundwissen erarbeiten, worauf Verständnis und >>Auffassungsgabe gründen können.
Daran arbeite ich weiterhin.
Bis dahin ertsnal danke.
Ahoi.
Lieber Mathias,
Die meisten XHTML-Dokumente im Web sind z.B. kein gültiges XML und niemand macht von den potenziellen Vorteilen Gebrauch. Es ist unnötig, sich dieses Spezzialwissen anzueignen, wenn die Ausbeute gegen Null geht. Deshalb: Don’t call XHTML, XHTML calls you!
Hat XHTML1.x im Gegensatz zu HTML4.01 irgendwelche Vorteile in Sachen Maschinenlesbarkeit, SuMa-Optimierung, etc? Wenn ich valides XHTML1.0 strict schreibe, dann ist es doch auch korrektes XML, oder habe ich da etwas falsch verstanden?
Liebe Grüße aus Ellwangen,
Felix Riesterer.
Hallo,
Hat XHTML1.x im Gegensatz zu HTML4.01 irgendwelche Vorteile in Sachen Maschinenlesbarkeit, SuMa-Optimierung, etc?
Maschinenlesbarkeit insofern, dass man aus einer Fülle von Software, die XML verarbeiten kann, auswählen kann, um irgendwelche Operationen mit dem XTML-Dokument vorzunehmen. Dagegen kann man einwenden, dass auch SGML ein alter Hut ist und seit Jahrzehnten Software existiert, aber den XML-Boom, durch den sich XML zum zentralen Datenformat gemausert hat, kann man nicht leugnen. Im Hinblick auf Suchmaschinenoptimierung sehe ich keine Vorteile.
Wenn ich valides XHTML1.0 strict schreibe, dann ist es doch auch korrektes XML
Ja.
Mathias
puts "Hallo " + gets.chomp + "."
?> molily
=> Hallo molily.
Wenn ich valides XHTML1.0 strict schreibe, dann ist es doch auch korrektes XML
Ja.
Noch nicht ganz.
Valide bedeutet noch nicht, dass es auch korrekt ausgeliefert wird. Ohne application/xhtml+xml (o. Ä.) ist es kein echtes XML.
Es steht euch wie immer frei, mich zu korrigieren, wenn ich mich irre.
Einen schönen Donnerstag noch.
Gruß, Ashura
Hi,
Valide bedeutet noch nicht, dass es auch korrekt ausgeliefert wird. Ohne application/xhtml+xml (o. Ä.) ist es kein echtes XML.
Es steht euch wie immer frei, mich zu korrigieren, wenn ich mich irre.
was ich hiermit mache. Deine Aussage trifft nur für XHTML 1.1 zu - XHTML 1.0 ist ganz bewußt abwärtskompatibel und darf sowohl als text/html ausgeliefert werden als auch auf den xml-Prolog verzichtet werden.
freundliche Grüße
Ingo
puts "Hallo " + gets.chomp + "."
?> Ingo
=> Hallo Ingo.
was ich hiermit mache. Deine Aussage trifft nur für XHTML 1.1 zu - XHTML 1.0 ist ganz bewußt abwärtskompatibel und darf sowohl als text/html ausgeliefert werden als auch auf den xml-Prolog verzichtet werden.
Das ist mir bewusst. Doch wird es in diesem Falle eben--wie du schon sagtest--als text/html und nicht als „echtes“ xml ausgeliefert.
Einen schönen Donnerstag noch.
Gruß, Ashura
你好 Ashura,
was ich hiermit mache. Deine Aussage trifft nur für XHTML 1.1 zu - XHTML
1.0 ist ganz bewußt abwärtskompatibel und darf sowohl als text/html
ausgeliefert werden als auch auf den xml-Prolog verzichtet werden.Das ist mir bewusst. Doch wird es in diesem Falle eben--wie du schon
sagtest--als text/html und nicht als „echtes“ xml ausgeliefert.
Wie es ausgeliefert wird bezeichnet nicht, was es ist. Ich kann ein
XML-Dokument auch als text/plain ausliefern, es ist trotzdem noch valides
XML.
再见,
克里斯蒂安
puts "Hallo " + gets.chomp + "."
?> Christian
=> Hallo Christian.
Wie es ausgeliefert wird bezeichnet nicht, was es ist. Ich kann ein
XML-Dokument auch als text/plain ausliefern, es ist trotzdem noch valides
XML.
Wenn du--wie ich--valide mit „gegenüber der angefügten DTD gültig“ definierst, dann ja.
Einen schönen Donnerstag noch.
Gruß, Ashura
Hi,
Wenn du--wie ich--valide mit „gegenüber der angefügten DTD gültig“ definierst, dann ja.
Um valides XML geht es bei XHTML 1.0 doch nicht ausschließlich. Da es abwärtskompatibel ausgelegt ist, ist es auch als text/html ausgeliefert und ohne xml-Prolog völlig korrektes XHTML.
freundliche Grüße
Ingo
puts "Hallo " + gets.chomp + "."
?> Ingo
=> Hallo Ingo.
Um valides XML geht es bei XHTML 1.0 doch nicht ausschließlich. Da es abwärtskompatibel ausgelegt ist, ist es auch als text/html ausgeliefert und ohne xml-Prolog völlig korrektes XHTML.
Ähm... Warum sagst du mir das? Ich rede die ganze Zeit davon, dass es kein gültiges XML ist, wenn es nicht als application/xhtml+xml ausgeliefert wird. Dass es vollwertig valides XHTML ist, habe ich in keinster Weise angezweifelt.
Ich beziehe mich die ganze Zeit auf Felix' Frage:
Wenn ich valides XHTML1.0 strict schreibe, dann ist es doch auch korrektes XML, oder habe ich da etwas falsch verstanden?
Valides XHTML muss nicht bedeuten, dass auch vollwertiges XML ausgeliefert wird, was man z.B. daran merken kann, dass es durch den strengeren XML-Parser läuft.
Ich hoffe, dass du mich nun verstehst.
Einen schönen Freitag noch.
Gruß, Ashura
你好 Ashura,
Um valides XML geht es bei XHTML 1.0 doch nicht ausschließlich. Da es
abwärtskompatibel ausgelegt ist, ist es auch als text/html ausgeliefert
und ohne xml-Prolog völlig korrektes XHTML.Ähm... Warum sagst du mir das? Ich rede die ganze Zeit davon, dass es
kein gültiges XML ist, wenn es nicht als application/xhtml+xml
ausgeliefert wird. Dass es vollwertig valides XHTML ist, habe ich in
keinster Weise angezweifelt.
Ich glaube, Ingo meinte, es sei dann immer noch gültiges XML. Was auch so
ist. Auch, wenn man es als text/plain ausliefert bleibt es gültiges XML.
再见,
克里斯蒂安
puts "Hallo " + gets.chomp + "."
?> Christian
=> Hallo Christian.
Ich glaube, Ingo meinte, es sei dann immer noch gültiges XML. Was auch so
ist. Auch, wenn man es als text/plain ausliefert bleibt es gültiges XML.
Definiere bitte einmal „gültig“.
Einen schönen Freitag noch.
Gruß, Ashura
你好 Ashura,
Ich glaube, Ingo meinte, es sei dann immer noch gültiges XML. Was auch so
ist. Auch, wenn man es als text/plain ausliefert bleibt es gültiges XML.Definiere bitte einmal „gültig“.
Das ist bereits definiert ;-)
In diesem Fall meinte ich, es ist well-formed und valide. Wie es ausgeliefert
wird, bestimmt nur, wie es verarbeitet wird, nicht, was es ist. Ich kann auch
Exe-Dateien als text/plain ausliefern (wird häufig genug auch gemacht, immer
dann, wenn da einer sitzt, der wenig Ahnung von sowas hat *g*). Sie bleiben
trotzdem Exe-Files :)
再见,
克里斯蒂安
puts "Hallo " + gets.chomp + "."
?> Christian
=> Hallo Christian.
Das ist bereits definiert ;-)
*g* Ja, ich weiß.
In diesem Fall meinte ich, es ist well-formed und valide. Wie es ausgeliefert
wird, bestimmt nur, wie es verarbeitet wird, nicht, was es ist.
Gut, ich habe mich (mal wieder) etwas undeutlich ausgedrückt. Ich wollte auf die Verarbeitung anspielen, was man eben durch den Einsatz eines XML-Parsers bemerkt, der nur anspringt, wenn einer der dafür erforderlichen MIME-Typen vom Browser erkannt wurde.
Ich kann auch
Exe-Dateien als text/plain ausliefern (wird häufig genug auch gemacht, immer
dann, wenn da einer sitzt, der wenig Ahnung von sowas hat *g*). Sie bleiben
trotzdem Exe-Files :)
Naja, dann führe die mal aus. ;-) (Umbenennen gilt nicht.)
Einen schönen Freitag noch.
Gruß, Ashura
你好 Ashura,
In diesem Fall meinte ich, es ist well-formed und valide. Wie es
ausgeliefert wird, bestimmt nur, wie es verarbeitet wird, nicht, was es
ist.Gut, ich habe mich (mal wieder) etwas undeutlich ausgedrückt. Ich wollte
auf die Verarbeitung anspielen, was man eben durch den Einsatz eines
XML-Parsers bemerkt, der nur anspringt, wenn einer der dafür
erforderlichen MIME-Typen vom Browser erkannt wurde.
Das Browser zwei unterschiedliche Parser haben ist ein weiteres
Ammenmärchen. Das ist Humbug, das wäre ja bescheuert. Nein, es gibt einen
Parser, der nur unterschiedlich reagiert; bei Auslieferung als
application/xhtml+xml dann strenger als bei text/html. Aber zwei Parser gibt
es nicht.
Ich kann auch
Exe-Dateien als text/plain ausliefern (wird häufig genug auch gemacht,
immer dann, wenn da einer sitzt, der wenig Ahnung von sowas hat *g*).
Sie bleiben trotzdem Exe-Files :)Naja, dann führe die mal aus. ;-) (Umbenennen gilt nicht.)
Scheitert am falschen Betriebssystem. Aber nichts desto trotz früher schon
öfter geschehen (Rechte Maustaste, Speichern unter, Doppelklick).
再见,
克里斯蒂安
Hallo.
Naja, dann führe die mal aus. ;-) (Umbenennen gilt nicht.)
Scheitert am falschen Betriebssystem.
Nein, am richtigen Betriebssystem.
MfG, at
puts "Hallo " + gets.chomp + "."
?> Christian
=> Hallo Christian.
Nein, es gibt einen
Parser, der nur unterschiedlich reagiert; bei Auslieferung als
application/xhtml+xml dann strenger als bei text/html. Aber zwei Parser gibt
es nicht.
Achso? Wäre mir neu, würde aber durchaus Sinn ergeben.
Einen schönen Freitag noch.
Gruß, Ashura
你好 Ashura,
Nein, es gibt einen Parser, der nur unterschiedlich reagiert; bei
Auslieferung als application/xhtml+xml dann strenger als bei text/html.
Aber zwei Parser gibt es nicht.Achso? Wäre mir neu, würde aber durchaus Sinn ergeben.
Beim IE mag das anders sein, weil die ja den XML-Parser als extra Produkt
vertreiben (MSXML-Gedöns). Kann man ja leider auch nicht nachprüfen. Aber bei
der Mozilla-Familie durchläuft beides einen Parser, der nur unterschiedlich
reagiert. Und mich würde stark wundern, wenn das bei Opera anders wäre. Das
wäre architektonischer Unfug.
再见,
克里斯蒂安
puts "Hallo " + gets.chomp + "."
?> Christian
=> Hallo Christian.
Beim IE mag das anders sein, weil die ja den XML-Parser als extra Produkt
vertreiben (MSXML-Gedöns). Kann man ja leider auch nicht nachprüfen. Aber bei
der Mozilla-Familie durchläuft beides einen Parser, der nur unterschiedlich
reagiert.
Aha, danke.
Und mich würde stark wundern, wenn das bei Opera anders wäre. Das
wäre architektonischer Unfug.
Es ist sehr wahrscheinlich ein Parser mit 2 versch. Modi:
„There are two "modes" of XHTML support, one where the document has the text/html content type and the other where it has one of text/xml, application/xml or application/xhtml+xml.“
Zu XML steht auch nicht viel mehr:
„Opera 8 can parse and display XML documents.“
(http://www.opera.com/docs/specs/#html)
Ich denke aber, dass du Recht hast.
Einen schönen Freitag noch.
Gruß, Ashura
Tag Christian.
Beim IE mag das anders sein, weil die ja den XML-Parser als extra Produkt vertreiben (MSXML-Gedöns).
Bist du dir da sicher? Der IE ist m.E. in Bezug auf das Parsen von XML-Daten besser als sein Ruf und wesentlich konsequenter in Bezug auf Wohlgeformtheit als bspw. der Mozilla - und das ganz ohne extra Modul. MSXML ist nur die Schnittstelle zwischen JScript, VBScript u.a. MS-Produkten und XML. Oder meintest du was komplett anderes?
Siechfred
你好 Siechfred,
Beim IE mag das anders sein, weil die ja den XML-Parser als extra Produkt
vertreiben (MSXML-Gedöns).Bist du dir da sicher? Der IE ist m.E. in Bezug auf das Parsen von
XML-Daten besser als sein Ruf und wesentlich konsequenter in Bezug auf
Wohlgeformtheit als bspw. der Mozilla
Da gibts nichts, wo man konsequenter sein könnte ;-) Bei XML ist genau
definiert, was wohlgeformt ist und was valide ist. Alles, was sich
XML-Parser nennt, hat sich dran zu halten, da kann der eine nicht
Konsequenter sein als der andere ;-)
und das ganz ohne extra Modul. MSXML ist nur die Schnittstelle zwischen
JScript, VBScript u.a. MS-Produkten und XML. Oder meintest du was komplett
anderes?
Das Modul wird nur schon beigeliefert. Und MSXML ist eindeutig ein eigenes
Produkt, man kann es ja sogar getrennt herunterladen ;-)
再见,
克里斯蒂安
Tag Christian.
Da gibts nichts, wo man konsequenter sein könnte ;-) Bei XML ist genau definiert, was wohlgeformt ist und was valide ist. Alles, was sich XML-Parser nennt, hat sich dran zu halten, da kann der eine nicht Konsequenter sein als der andere ;-)
Hm, also den XML-Parser des Mozilla insbesondere mit seinen Warnungen und Fehlermeldungen habe ich nicht in besonders guter Erinnerung, den IE 6 da schon :-)
MSXML ist nur die Schnittstelle zwischen JScript, VBScript u.a. MS-Produkten und XML.
[...] MSXML ist eindeutig ein eigenes Produkt
Ja, aber MSXML ist genauso wenig XML wie ASP Perl ist. Es bietet dir nur die Möglichkeit, dass die genannten proprietären Techniken mit XML 1.0-konformen Anwendungen interagieren können. Um XML mit dem IE 6 darstellen zu können, brauchst du kein bisschen MSXML.
man kann es ja sogar getrennt herunterladen ;-)
Gehen dir etwa die Argumente aus? *fg*
Siechfred
你好 Siechfred,
Da gibts nichts, wo man konsequenter sein könnte ;-) Bei XML ist genau
definiert, was wohlgeformt ist und was valide ist. Alles, was sich
XML-Parser nennt, hat sich dran zu halten, da kann der eine nicht
Konsequenter sein als der andere ;-)Hm, also den XML-Parser des Mozilla insbesondere mit seinen Warnungen und
Fehlermeldungen habe ich nicht in besonders guter Erinnerung, den IE 6 da
schon :-)
Ich weiss nicht so recht, was du meinst. Mach mal Beispiele!
MSXML ist nur die Schnittstelle zwischen JScript, VBScript u.a.
MS-Produkten und XML.
[...] MSXML ist eindeutig ein eigenes ProduktJa, aber MSXML ist genauso wenig XML wie ASP Perl ist. Es bietet dir nur
die Möglichkeit, dass die genannten proprietären Techniken mit XML
1.0-konformen Anwendungen interagieren können. Um XML mit dem IE 6
darstellen zu können, brauchst du kein bisschen MSXML.
Also, soweit ich weiss hat das MSXML-Paket unter anderem einen XML-Parser
(DOM und SAX) dabei (neben einem XSLT-Prozessor und noch ein paar Dingen).
Wird ja auch so vertrieben: “The Microsoft® XML Parser (MSXML) 3.0”,
“With Microsoft XML Core Services (MSXML), formerly known as the Microsoft
XML Parser, ...”, “NOTE: MSXML is a COM-based parser...”, und, etwas länger:
================
Among the core services MSXML provides is developer support for the following:
The Document Object Model (DOM), a standard library of application programming interfaces (APIs) for accessing XML documents.
Helper APIs to assist with programming for XML namespace or the HyperText Transfer Protocol (HTTP) when it is used to send data directly between Web servers.
The XML Data Reduced schema definition language (XDR), which Microsoft introduced support for top assist with XML schema working needs while awaiting the now final W3C standard XML Schema Definition (XSD) language.
The Simple API for XML (SAX), a programmatic alternative to DOM-based processing.
The Schema Object Model (SOM), an additional set of APIs for accessing XML Schema documents programmatically that was introduced in MSXML 4.0 and later.
man kann es ja sogar getrennt herunterladen ;-)
Gehen dir etwa die Argumente aus? *fg*
Ne, war völlig ernst gemeint.
再见,
克里斯蒂安
Tag Christian.
Hm, also den XML-Parser des Mozilla insbesondere mit seinen Warnungen und Fehlermeldungen habe ich nicht in besonders guter Erinnerung, den IE 6 da schon :-)
Ich weiss nicht so recht, was du meinst. Mach mal Beispiele!
Fehler im XML, XSL und in der DTD. Die Warnungen und Fehlermeldungen des IE 6 waren für mich als Anfänger aussagekräftiger als die des Mozilla.
Also, soweit ich weiss hat das MSXML-Paket unter anderem einen XML-Parser (DOM und SAX) dabei (neben einem XSLT-Prozessor und noch ein paar Dingen).
Ja, da hast du zweifelsohne Recht. Allerdings kommt der IE mindestens seit Version 4 mit einem XML-Parser nebst XSL-Prozessor, die beide (soweit mir bekannt) konform zu XML 1.0 arbeiten.
man kann es ja sogar getrennt herunterladen ;-)
Gehen dir etwa die Argumente aus? *fg*
Ne, war völlig ernst gemeint.
Jaja, red' dich nur raus ;-))
Siechfred
你好 Siechfred,
Hm, also den XML-Parser des Mozilla insbesondere mit seinen Warnungen
und Fehlermeldungen habe ich nicht in besonders guter Erinnerung, den
IE 6 da schon :-)
Ich weiss nicht so recht, was du meinst. Mach mal Beispiele!Fehler im XML, XSL und in der DTD. Die Warnungen und Fehlermeldungen des
IE 6 waren für mich als Anfänger aussagekräftiger als die des Mozilla.
Das hat doch nichts damit zu tun, ob ein Parser konsequent ist oder nicht ;)
Nur, ob er nutzerfreundlich ist oder nicht.
Also, soweit ich weiss hat das MSXML-Paket unter anderem einen
XML-Parser (DOM und SAX) dabei (neben einem XSLT-Prozessor und noch ein
paar Dingen).Ja, da hast du zweifelsohne Recht. Allerdings kommt der IE mindestens
seit Version 4 mit einem XML-Parser nebst XSL-Prozessor, die beide
(soweit mir bekannt) konform zu XML 1.0 arbeiten.
Soweit _ich_ weiss nutzt der MSIE MSXML. Aber wie gesagt, bin mir da auch
nicht sicher und leider kann man es auch nicht nachprüfen.
再见,
克里斯蒂安
Tag Christian.
Fehler im XML, XSL und in der DTD. Die Warnungen und Fehlermeldungen des
IE 6 waren für mich als Anfänger aussagekräftiger als die des Mozilla.
Das hat doch nichts damit zu tun, ob ein Parser konsequent ist oder nicht ;)
Nur, ob er nutzerfreundlich ist oder nicht.
Jaja, Kümmelspalter ;-)
Soweit _ich_ weiss nutzt der MSIE MSXML. Aber wie gesagt, bin mir da auch nicht sicher und leider kann man es auch nicht nachprüfen.
M.E. (ich wiederhole mich:) ist MSXML eine Schnittstelle zwischen XML 1.0 und diversen proprietären Techniken. Dass der Parser auch MSXML beherrscht, liegt nahe und wird auch der Wirklichkeit entsprechen, aber um standardkonformes XML im IE darstellen zu können, brauchst du kein Stück MSXML. Erst, wenn du aus einer Datenbasis mit Hilfe von JScript, VB oder VBScript XML generieren oder XML-basierte Daten mittels der genannten Techniken verarbeiten möchtest, kommt m.W.n. MSXML ins Spiel.
Siechfred
Tag Christian.
Kleiner Nachtrag:
Soweit _ich_ weiss nutzt der MSIE MSXML. Aber wie gesagt, bin mir da auch
nicht sicher und leider kann man es auch nicht nachprüfen.
Du scheinst insoweit Recht zu haben, dass der XML-Parser des IE auch MSXML verarbeitet, zu testen, indem man ein via Office erzeugtes XML-Dokument im IE betrachtet.
So, ich fahre jetzt zum Grillen nach Oberwiesenthal *lechz*
Siechfred
puts "Hallo " + gets.chomp + "."
?> Siechfred
=> Hallo Siechfred.
So, ich fahre jetzt zum Grillen nach Oberwiesenthal *lechz*
Hö? Da kannst du ja mal bei mir vorbeischauen. *g*
Einen schönen Freitag noch.
Gruß, Ashura
Hallo,
Fehler im XML, XSL und in der DTD. Die Warnungen und Fehlermeldungen des IE 6 waren für mich als Anfänger aussagekräftiger als die des Mozilla.
Das hat doch nichts damit zu tun, ob ein Parser konsequent ist oder nicht ;)
Klar, Mozilla hat einen nicht-validierenden XML-Parser, MSXML kuckt sich auf die DTD an. Was XSL angeht, so weiß ich nur, dass sich Thomas J.S. ständig über Mozilla im Gegensatz zu MSXML aufregt. ;)
Mathias
Nein, es gibt einen Parser, der nur unterschiedlich reagiert; bei Auslieferung als application/xhtml+xml dann strenger als bei text/html. Aber zwei Parser gibt es nicht.
Achso? Wäre mir neu, würde aber durchaus Sinn ergeben.
Niemand, der z.B. sagt »Browser haben einen Parser zum Parsen von Tag Soup und einen zum Parsen von XML« will Aussagen darüber machen, ob es zwei eigenständige, komplett getrennte Programmodule sind, die den Code jeweils gänzlich unterschiedlich verarbeiten. Es sind einfach zwei Parsing-Modi gemeint.
Sich darüber zu streiten, ob diesen Parsing-Modi eine Trennung im Code entspricht, ist höchstens relevant für Programmierer von Parsern, aber nicht für XHTML-Autoren.
Mathias
Das Browser zwei unterschiedliche Parser haben ist ein weiteres Ammenmärchen. Das ist Humbug, das wäre ja bescheuert. Nein, es gibt einen Parser, der nur unterschiedlich reagiert; bei Auslieferung als application/xhtml+xml dann strenger als bei text/html. Aber zwei Parser gibt es nicht.
Einsatz eines XML-Parsers = Einsatz eines XML-konformen Parsers
Da widersprichst du einer Aussage, die gar nicht gemacht wurde. »Parser« war nicht als selbstständiges Programmmodul gemeint, sondern als Methodik des Parsens. Wie die Trennung verschiedener Parser-Regelwerken programmintern gelöst ist, ist vollkommen nebensächlich für diese Ebene der Betrachtung. Wenn man auf dieser Ebene zwischen dem HTML-Parser und dem XML-Parser eines Browsers begrifflich unterscheidet, will man gar keine Aussagen über die interne Umsetzung machen. (Im Übrigen binden Opera und Firefox meines Wissens expat ein, wieso eigentlich, doch sicher nicht, um damit Tag Soup zu parsen?)
Mathias
你好 molily,
Da widersprichst du einer Aussage, die gar nicht gemacht wurde. »Parser«
war nicht als selbstständiges Programmmodul gemeint, sondern als Methodik
des Parsens.
Hörte sich für mich anders an. Deshalb wollte ich es auch nur klarstellen.
(Im Übrigen binden Opera und Firefox meines Wissens expat ein, wieso
eigentlich, doch sicher nicht, um damit Tag Soup zu parsen?)
Muss dich enttäuschen, mir sagt ldd was anderes.
再见,
克里斯蒂安
Hallo,
(Im Übrigen binden Opera und Firefox meines Wissens expat ein, wieso
eigentlich, doch sicher nicht, um damit Tag Soup zu parsen?)Muss dich enttäuschen, mir sagt ldd was anderes.
Was sagt dir denn ldd? Lese ich das falsch?
ldd /usr/lib/MozillaFirefox/firefox-bin | grep expat
libexpat.so.0 => /usr/lib/libexpat.so.0 (0xb75a2000)
ldd /opt/opera/lib/opera/8.01-20050615.5/opera | grep expat
libexpat.so.0 => /usr/lib/libexpat.so.0 (0xb743b000)
Ich habe übrigens aus Help -> About Opera geschlossen, dass Opera mit expat verknüpft ist, außerdem gibt's beim Windows-Opera eine entsprechende dll, soweit ich mich erinnere.
Mathias
你好 molily,
(Im Übrigen binden Opera und Firefox meines Wissens expat ein, wieso
eigentlich, doch sicher nicht, um damit Tag Soup zu parsen?)Muss dich enttäuschen, mir sagt ldd was anderes.
Was sagt dir denn ldd?
Bei mir sagt der ldd mir nichts in der Richtung ;-) Kann er auch
zugegebenermassen schwerlich, ich habe eine statisch gelinkte Opera-Binary.
Aber mein Firefox ist dynamisch gelinkt, da gibts auch kein expat,
irgendwie.
Whatever, kann ja sein, dass sie Expat einbinden (wobei mich schon wundert,
dass mein Firefox kein Expat nutzt), bezweifle aber, dass sie es zum
Verarbeiten für das HTML (egal ob als text/html oder application/xhtml+xml
ausgeliefert) genutzt wird. Bei Mozilla habe ich das irgendwann auch mal
nachvollzogen, habe aber jetzt gerade keine Lust mehr, das nocheinmal zu
tun.
Lese ich das falsch?
ldd /usr/lib/MozillaFirefox/firefox-bin | grep expat
libexpat.so.0 => /usr/lib/libexpat.so.0 (0xb75a2000)
ldd /opt/opera/lib/opera/8.01-20050615.5/opera | grep expat
libexpat.so.0 => /usr/lib/libexpat.so.0 (0xb743b000)
Nee, das liest du richtig, da wird gegen libexpat gelinkt :)
再见,
克里斯蒂安
Hej,
Schreibe valides sauberes XHTML 1.1
Das ist Unsinn. Keep it simple, stupid.
Würdest du diese Aussage auch auf xhtml 1.0 beziehen? Ich verstehe schlicht nicht, was xhtml komplizierter macht als html? Im Gegenteil. Dadurch, dass xhrml dem Textauszeichner einer engeres Korsett auferlegt, wird die Anzahl der möglichen Fehlerquellen drastisch verringert und man gewöhnt sich von vornherein an, weniger schlampig zu arbeiten. Außerdem: Warum soll ich jetzt erstmal html lernen, um mich dann später, wenn ich die Vorteile von xml erkannt habe und nutzen möchte, wieder umgewöhnen zu müssen?
Wer in keinster Weise von XHTML wirklich handfest profitiert, soll HTML schreiben, weil XHTML einen Rattenschwanz an Themen nach sich zieht, in die man sich einarbeiten muss, um XHTML zu verstehen und kompetent gebrauchen zu können.
Das versteh ich nicht. Könntest du mir das vielleicht etwas genauer erklären?
Es ist unnötig, sich dieses Spezzialwissen anzueignen,
Mit Spezialwissen meinst du:
* Alle geöffneten Tags zu schließen und allein stehende Tags mit einem '/>' zu beenden.
* Elementnamen klein zu schreiben.
* Anker auf id's anstatt auf names zu verweisen.
* Auf Zeilenumbrüchen in Attributen zu verzichten.
* Eine etwas sinnreichere Schachtelungen.
* Bestimmt wenige Kleinigkeiten die ich jetzt vergessen habe.
Ich habe von anfang an nur als xhtml 1.0 strict ausgezeichnet und glaube dadurch eher eine Ersparniss, wenn auch keine bemerkenswerte, erfahren zu haben.
Beste Grüße
Biesterfeld
Hallo,
Schreibe valides sauberes XHTML 1.1
Das ist Unsinn. Keep it simple, stupid.
Würdest du diese Aussage auch auf xhtml 1.0 beziehen? Ich verstehe schlicht nicht, was xhtml komplizierter macht als html? Im Gegenteil.
HTML (Strict) verlangt tatsächlich nicht den konsequenten und logischen Code, den XHTML »verlangt«. Trotzdem wird ein halbwegs kompetenter HTML-Autor trotzdem quasi-wohlgeformten Code schreiben, die Möglichkeiten der Minimierung nicht verwenden usw. Einem Anfänger verschweigt man am besten die ganzen HTML-Perversitäten und vermittelt ihm HTML fast wie XHTML. Daher finde ich dieses Argument vorgeschoben:
Dadurch, dass xhrml dem Textauszeichner einer engeres Korsett auferlegt, wird die Anzahl der möglichen Fehlerquellen drastisch verringert und man gewöhnt sich von vornherein an, weniger schlampig zu arbeiten.
Da bin ich skeptisch, weil sich meiner Erfahrung nach, vor allem hier im Forum, immer wieder zeigt, dass die Beschäftigung mit XHTML so oberflächlich ist, dass letztlich (genau wie bei HTML) eben nicht valider und stilistisch einwandfreier Code herauskommt. Auch XHTML »zwingt« niemanden zu gutem Code, denn die einzige faktische Instanz, die Validität und Wohlgeformtheit prüft, ist der Validator. In dem Punkt unterscheiden sich HTML und XHTML in der Anwendung nicht. Der Zwang bei XHTML fällt in der Praxis weg, weil die wenigsten XHTML wirklich als XML verarbeiten. Außer eben, wenn sie ab und zu validieren - und selbst der W3C-Validator ist kein richtiger XML-Parser.
Außerdem: Warum soll ich jetzt erstmal html lernen, um mich dann später, wenn ich die Vorteile von xml erkannt habe und nutzen möchte, wieder umgewöhnen zu müssen?
Ich habe nichts dagegen einzuwenden, von Anfang an XHTML zu lernen. Man sollte nur nicht der Illusion verfallen, dass man sich auf diese Weise nur mit dem Wahren, Schönen und Guten beschäftigen müsse. Man muss in jedem Fall auch in das Thema HTML einsteigen und eben die Unterschiede zwischen HTML und XHTML kennen, um kompatibles XHTML schreiben zu können.
Wer heute XHTML einsetzen will, muss sich zwangsläufig mit dem Thema HTML-Kompatibilität auseinandersetzen. Wer heute XHTML im WWW benutzt, liefert das XHTML in den meisten Fällen sowieso als HTML (text/html) aus. Die meisten Autoren wissen meiner Erfahrung nach gar nicht von der Verarbeitungsproblematik. Auch Einführungen, die von vornherein auf XHTML setzen (z.B. Michaels) gehen von HTML-kompatiblem XHTML als text/html aus. Bekommt man also irgendwann Wind von der Möglichkeit der Verarbeitung als XML seitens der Browser, muss man trotzdem auf die HTML-Kompatibilität setzen. Sprich, text/html für veraltete Browser, application/xhtml+xml für diejenigen, die echtes XHTML ausreichend verarbeiten können.
Das heißt, wenn ich XHTML verwenden will, muss ich den gedanklichen Schritt von HTML zu XHTML vollzogen haben und in beiden Welten kompetent sein. »Soll ich jetzt erst einmal HTML lernen?« - Nein, aber hinterrücks bleibt mir nichts anderes übrig.
Es ist unnötig, sich dieses Spezzialwissen anzueignen,
Mit Spezialwissen meinst du:
Nein, mit Spezialwissen meine ich nicht die trivialen, naheliegenden Syntax-Unterschiede, sondern die vielen Unterschiede zwischen HTML und XHTML (als echtes XHTML verarbeitet!), die man für gewöhnlich übersieht, weil man momentan nie XHTML als XML verarbeitet.
Das sind so Sachen, wie hier schon genannt wurden: CSS wird in (echtem) XHTML anders angewandt als bei HTML. Genauso gibt es einige JavaScript-Fallstricke, document.write geht z.B. nicht mehr, viele DOM-Methoden funktionieren im Detail anders. script- und style-Elemente werden anders geparst. Die Kodierung eines Dokuments wird von XML-Pasern ganz anders herausgefunden. Und so weiter. Die gängigen XHTML-Dokumente im WWW ignorieren diese Umstände. Würde man sie als application/xhtml+xml ausliefern und würden korrekte XML-Parser sie verarbeiten, würden sie in vielerlei Hinsicht nicht funktionieren.
Meine Webseite http://molily.de/ z.B. ist kein gültiges XHTML. Der W3C Validator behauptet, die Seite sei valide. Pustekuchen, gültiges XHTML ist es trotzdem nicht. Ein echter XML-Parser muss, sofern er dem XML-Standard folgt, die Verarbeitung abbrechen. Findest du den Fehler? Würde ihn ein beliebiger XHTML-Autor finden? Meiner Erfahrung nach nicht.
Mathias
Lieber Mathias,
Meine Webseite http://molily.de/ z.B. ist kein gültiges XHTML. Der W3C Validator behauptet, die Seite sei valide. Pustekuchen, gültiges XHTML ist es trotzdem nicht. Ein echter XML-Parser muss, sofern er dem XML-Standard folgt, die Verarbeitung abbrechen. Findest du den Fehler? Würde ihn ein beliebiger XHTML-Autor finden? Meiner Erfahrung nach nicht.
Ich habe mal gesucht...
Ist das der (sind das die) Fehler?
Liebe Grüße aus Ellwangen,
Felix Riesterer.
puts "Hallo " + gets.chomp + "."
?> Felix
=> Hallo Felix.
- es "fehlt" ein XML-Prolog wie <?xml version="1.0"?>
Deklaration ist das richtige Wort.
- es sind lang-Attribute enthalten, die in xml meines Wissens nach xml:lang heißen müssen (ist parallel bei Dir auch vorhanden)
Solange er nicht >= XHTML 1.1 verwendet, ist das lang-Attribut kein Problem.
Ist das der (sind das die) Fehler?
Die XML-Parser geben sich zufrieden, wenn die XML-Deklaration hinzugefügt wird (Ausgabe als application/xhtml+xml).
Einen schönen Donnerstag noch.
Gruß, Ashura
Hi,
Die XML-Parser geben sich zufrieden, wenn die XML-Deklaration hinzugefügt wird (Ausgabe als application/xhtml+xml).
aber nicht ohne Kodierungsangabe - denn die wird hier nicht vom Server ausgegeben und da kein UTF-8 verwendet wird und ein XML-Parser sich nicht für Meta-Angaben interessieren sollte...
freundliche Grüße
Ingo
Hallo,
aber nicht ohne Kodierungsangabe - denn die wird hier nicht vom Server ausgegeben (..)
Wobei laut HTTP-Standard dann per default Latin1 angenommen werden soll.
Tim
Hi,
aber nicht ohne Kodierungsangabe - denn die wird hier nicht vom Server ausgegeben (..)
Wobei laut HTTP-Standard dann per default Latin1 angenommen werden soll.
nein, es handelt sich um XHTML. Und was hat HTTP in dieser Beziehung überhaupt mit XHTML und der Kodierungsempfehlung für den Fall, daß im HTTP-Header keine angegeben wird, zu tun?
freundliche Grüße
Ingo
Moin,
nein, es handelt sich um XHTML. Und was hat HTTP in dieser Beziehung überhaupt mit XHTML und der Kodierungsempfehlung für den Fall, daß im HTTP-Header keine angegeben wird, zu tun?
Erstmal handelt es sich um Daten die per HTTP übermittelt wurden, einen text/*-Content-Type haben und für die kein charset im HTTP-Header gesetzt wurde. HTTP _definiert_ dann ganz klar, dass die Daten dann ISO-8859-1-kodiert sind:
| The "charset" parameter is used with some media types to define the
| character set (section 3.4) of the data. When no explicit charset
| parameter is provided by the sender, media subtypes of the "text"
| type are defined to have a default charset value of "ISO-8859-1" when
| received via HTTP. Data in character sets other than "ISO-8859-1" or
| its subsets MUST be labeled with an appropriate charset value.
-- RFC 2616, Abschnitt 3.7.1
Das gilt solange wie molily seinen Inhalt als text/html ausliefert, und daran würde sich erst etwas ändern wenn er application/xml oder so nehmen würde.
你好 Henryk,
Erstmal handelt es sich um Daten die per HTTP übermittelt wurden, einen
text/*-Content-Type haben und für die kein charset im HTTP-Header gesetzt
wurde. HTTP _definiert_ dann ganz klar, dass die Daten dann
ISO-8859-1-kodiert sind:
[...]Das gilt solange wie molily seinen Inhalt als text/html ausliefert, und
daran würde sich erst etwas ändern wenn er application/xml oder so nehmen
würde.
Interessant ist, dass bei Auslieferung mit Content-Type text/xml sich dann
zwei Standards widersprechen. Übrigens nehmen sowohl Firefox als auch Opera
in dem Fall UTF-8 als Default-Charset an.
再见,
克里斯蒂安
Hi,
nein, es handelt sich um XHTML. Und was hat HTTP in dieser Beziehung überhaupt mit XHTML und der Kodierungsempfehlung für den Fall, daß im HTTP-Header keine angegeben wird, zu tun?
Erstmal handelt es sich um Daten die per HTTP übermittelt wurden, einen text/*-Content-Type haben und für die kein charset im HTTP-Header gesetzt wurde. HTTP _definiert_ dann ganz klar, dass die Daten dann ISO-8859-1-kodiert sind:
[...]
Das gilt solange wie molily seinen Inhalt als text/html ausliefert, und daran würde sich erst etwas ändern wenn er application/xml oder so nehmen würde.
Und wie soll ich dann http://www.w3.org/TR/xhtml1/#strict:
» An XML declaration is not required in all XML documents; however XHTML document authors are strongly encouraged to use XML declarations in all their documents. Such a declaration is required when the character encoding of the document is other than the default UTF-8 or UTF-16 and no encoding was determined by a higher-level protocol. «
verstehen? XHTML 1.0 darf als text/html ausgeliefert werden und für XHTML ist UTF-8 als default festgelegt. Zumindest mein Firefox stellt mir bei XHTML-Dokumenten ohne jegliche Kodierungsangabe nur Fragezeichen dar, wenn Sonderzeichen nicht UTF-8-kodiert sind - auch wenn sie als text/html ausgeliefert werden.
freundliche Grüße
Ingo
Hallo Ingo,
such a declaration is required when the character encoding of the document is other than the default UTF-8 or UTF-16 and no encoding was determined by a higher-level protocol. «
XHTML 1.0 darf als text/html ausgeliefert werden und für XHTML ist UTF-8 als default festgelegt.
Der Knackpunkt hier ist der Begriff „higher-level protocol“ - in diesem Fall ist damit HTTP gemeint. Und das sagt etwas anderes, als die XML Spezifikation für sich alleine stehende XML Dokumente. Es ist einfach so, dass hier verschiedene Spezifikationen in sich nicht wirklich schlüssig sind.
Vergleiche auch die Notiz der W3C HTML Working Group zum Thema XHTML Media Types zu text/html:
„Authors should also be careful about character encoding issues. A typical
misunderstanding is that since an XHTML document is an XML document, the
character encoding of an XHTML document should be treated as UTF-8 or
UTF-16 in the absence of an explicit character encoding information. This
is NOT the case when an XHTML document is served as 'text/html'.“
...
„Therefore, authors SHOULD NOT assume any default value for an XHTML
document served as 'text/html', and as mentioned in [RFC2854], the use of
an explicit charset parameter is STRONGLY RECOMMENDED. When it is difficult
to specify an explicit charset parameter through a higher-level protocol,
authors SHOULD include the XML declaration ...“
(Nebenbei: Das ist nur eine Notiz der W3C HTML Working Group, wie man das machen sollte. Wenn man wirklich genau rauskriegen will, welche Zeichenkodierung bei über text/html ohne charset-Angabe versandtem XHTML 1.0 angenommen werden soll, muss man haufenweise Spezifikationen miteinander in Harmonie bringen. MIME sagt dieses, HTTP jenes, HTML wiederum was anderes, XHTML 1.0 noch was anderes, etc. Ich bin langsam so weit, eine Seite zu erstellen, auf der ich all die in sich widersprüchlichen Aussagen dazu sammele.)
Tim
Hi Tim,
Der Knackpunkt hier ist der Begriff „higher-level protocol“ - in diesem Fall ist damit HTTP gemeint.
Vergleiche auch die Notiz der W3C HTML Working Group zum Thema XHTML Media Types zu text/html:
„Authors should also be careful about character encoding issues. A typical
misunderstanding is that since an XHTML document is an XML document, the
character encoding of an XHTML document should be treated as UTF-8 or
UTF-16 in the absence of an explicit character encoding information. This
is NOT the case when an XHTML document is served as 'text/html'.“...
danke für diese Info. Schade, daß die Firefox-Entwickler diese Notiz offenbar noch nicht gelesen haben, denn dann würden mir so manche Fragezeichen erspart bleiben. ;-)
Ich bin langsam so weit, eine Seite zu erstellen, auf der ich all die in sich widersprüchlichen Aussagen dazu sammele.)
Mach das doch. Ich fände das sehr sinnvoll - am besten auch noch in einer englischen Übersetzung, falls von W3C mal jemand draufgeht. ;-)
Also wäre die Quintessenz bei als text/html ohne Kodierungsangabe ausgeliefertes XHTML 1.0 dann wohl, daß eine XML-Deklaration auch hier streng genommen unverzichtbar ist.
freundliche Grüße
Ingo
puts "Hallo " + gets.chomp + "."
?> Ingo
=> Hallo Ingo.
aber nicht ohne Kodierungsangabe - denn die wird hier nicht vom Server ausgegeben und da kein UTF-8 verwendet wird und ein XML-Parser sich nicht für Meta-Angaben interessieren sollte...
OK, ich bin den Anfang meines Testdokumentes schuldig:
<?php
header('Content-type: application/xhtml+xml; charset=utf-8');
?>
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
So habe ich es getestet. Ich habe aber molily's Seite nicht einfach gespeichert, sondern den Quelltext kopiert und in meinen Editor eingefügt, der standardmäßig mit UTF-8 speichert.
Unklarheiten beseitigt? ;-)
Einen schönen Freitag noch.
Gruß, Ashura
Hallo,
Findest du den Fehler? Würde ihn ein beliebiger XHTML-Autor finden? Meiner Erfahrung nach nicht.
Ich habe mal gesucht...
- es "fehlt" ein XML-Prolog wie <?xml version="1.0"?>
Jein.
Eine solche XML-Deklaration ist nicht zwingend nötig, das XHTML-Dokument wäre auch gültig ohne diese Angabe.
Ist das der (sind das die) Fehler?
Nein. Der Fehler ist, wie Ingo herausfand, die fehlende Kodierungsangabe. Ein echter XML-Parser muss in diesem Falle a) UTF-8 voraussetzen und b) die Verarbeitung abbrechen, sobald er auf den ersten gemäß UTF-8 kaputt kodierten Umlaut trifft. Christophs Schema-Validator macht es im Gegensatz zum W3C-Validator, der nicht einmal einen richtigen XML-Parser verwendet, richtig: http://schneegans.de/sv/?url=http%3A%2F%2Fmolily.de%2F&schema=auto&htmlcomp=yes
Die Kodierungsangabe kann natürlich in der XML-Deklaration erfolgen. Und sollte sie auch. Ich kann sie zwar per HTTP senden, wenn ich das Dokument als application/xhtml+xml ausliefern würde, aber wenn der Benutzer das Dokument lokal speichert, muss ich mich darauf verlassen, dass der Browser die Kodierungsangabe aus dem HTTP-Header ins Dokument übernimmt. Das lokal gespeicherte Dokument würde nämlich nicht angezeigt werden, wenn es in Latin1 geschrieben ist und der XML-Parser des Browsers UTF-9 annimmt.
Aber wir wissen, die XML-Deklaration bringt den MSIE in den Quirks-Modus, deshalb fehlt sie auf molily.de. Also müsste ich sie nur im Falle von application/xhtml+xml anhängen. Das zeigt vor allem: Nur in der Theorie ist ein XHTML-Dokument gleichsam problemlos als HTML und als »echtes« XHTML verarbeitbar, in der Praxis ergeben sich Probleme über Probleme, die keiner, der heutzutage frank und frei XHTML schreibt, erahnt.
Mathias
Hej,
vielen Dank für deinen sehr ausführlichen Beitrag.
Eine Passage würde ich dennoch gerne hervorheben:
Ich habe nichts dagegen einzuwenden, von Anfang an XHTML zu lernen. Man sollte nur nicht der Illusion verfallen, dass man sich auf diese Weise nur mit dem Wahren, Schönen und Guten beschäftigen müsse. Man muss in jedem Fall auch in das Thema HTML einsteigen und eben die Unterschiede zwischen HTML und XHTML kennen, um kompatibles XHTML schreiben zu können.
Full Ack! ;)
Beste Grüße
Biesterfeld