(x)html / auslieferung dergleichen nachhilfe :-)

Hi,
ist sowas okay?

[quote]

[/quote] Dabei habe ich als Doctype also xhtml, liefere es aber als text/html statt application/xhtml+xml aus. ist dies ein fehler? oder kann man es so machen?

XHTML immer als text/html auszuliefern, ist komplett unsinnig.
Wenn man immer text/html ausliefern läßt, nimmt man einfach
HTML4 und kein XHTML.

Wenn man XHTML immer als application/xhtml+xml ausliefern
läßt, sollte oben jedenfalls noch eine XML-Verarbeitungsanweisung
rein, mit Angabe zum encoding - dies meta-Element ist dann nicht
relevant und kann/sollte weg, insbsondere auch weil die Angabe
content=“text/html; charset=utf-8” für XHTML mit Sicherheit
falsch ist.

Welche Kodierung der browser wirklich annimmt, hängt
entscheidend davon ab, ob der server dazu Informationen
sendet (dann wird das verwendet, nicht Angaben im Dokument).
Wenn der nichts angibt, ist bei XHTML relevant, was in der
Verarbeitungsanweisung in der ersten Zeile für ein encoding
steht (gegebenenfalls vorhandene meta-Elemente werden dann
ignoriert). Bei HTML kann man entsprechend eine Angabe mit
dem meta-Element machen, formal geht das auch bei XHTML,
kommt dann aber eigentlich zu spät für den XML-parser, der
die Verarbeitungsanweisung selbst verstehen kann, während die
Bedeutung beliebiger Elemente im Dokument erst auf einer
anderen Abstraktionsstufe analysiert wird - die Zugehörigkeit
zum Namensraum von XHTML muß dann schon bekannt sein und
eine entsoprechende Interpretation vorliegen.
Sind keine Angaben im Dokument vorhanden oder vom browser
nicht zu identifizieren (es ist nicht genau definiert, bis wohin nach
meta-Elementen zur Kodierung gesucht werden soll, so weit
drinnen im Dokument ist eine Kodierungsangabe sowieso
problematisch, weil der browser das Dokument bis dahin ja schon
dekodiert haben muß, um die Angabe zu lesen und wenn er dies
mit der bis dahin geratenen/voreingestellten Dekodierung
hinbekommen hat, muß er dann mit der Dekodierung
von vorne beginnen), wird für XHTML automatisch utf-8
angenommen.
Bei text/html ist die Angelegenheit knifflig, dort ist es eher eine
ascii-Kodierung oder das allseits beliebte iso-8859-1 oder
neuerdings auch eine proprietäre Pessimierung von microsoft
davon (windows-1252 genannt). Gibt wohl auch browser, die bei
HTML versuchen zu raten, was aber wohl nach den offiziellen
Empfehlungen ein Fehler ist.

Knifflig wird die Angelegenheit, wenn man die Auslieferung davon
abhängig macht, was man herausfinden kann, was der anfragende
browser kann.
Der Purist würde da XHTML als application/xhtml+xml ausliefern,
wenn der browser vorgibt, das zu kennen und HTML alt text/html
nur dann, wenn der browser XHTML vermutlich nicht kennt, aber
vorgibt, HTML zu kennen. Der braucht also zwei Dokumente oder
ein Skript, welches etwa das XHTML in HTML konvertiert.
Der Pragmatiker weiß in etwa, wie er XHTML-Dokumente
schreiben muß, damit er sie auch notfalls (!) als text/html an die
browser ausliefern kann, die kein XHTML können, aber HTML
mit einer bekannten Fehlerbehandlung, die dazu führt, daß das
XHTML-Dokument auch mit dem HTML-Markierungssuppen-parser
darstellbar ist. Das Dokument dafür zu formulieren, ist aber nicht
so trivial, insbesondere nicht, wenn man es auch noch einheitlich
mit CSS verzieren will, was bei XHTML leicht anders aussehen kann
als bei (fehlerhaftem) HTML mit einigen Sonderregeln für HTML
und CSS.

okay, das war jetzt ne menge info…

mein problem etwas konkreter ist (was sonst) der internet explorer, sobalds um xhtml geht.
der erste gedanke war natürlich einfach html 4.01 zu nehmen, allerdings finde ich es wirklich nervtötend und schwierig, mich nicht an die xml-regeln halten zu dürfen - bspw werden metatags nicht geschlossen, etcetc…

zusammengefasst meine frage - habe ich irgendeine möglichkeit, meine dokumente in xhtml zu verfassen, und sie so auszuliefern, dass sie von allen gängigen (nicht guten! also meine ich damit auch den IE :wink: ) browsern korrekt interpretiert werden? ich hatte auch schon das problem, dass der ie mir nur den tag-tree angezeigt hat, wohl offenbar, weil er einfach kein xhtml kann… andererseits sehe ich dann im internet immer wieder seiten mit einem xhtml-doctype, also muss das doch iwie machbar sein! ich verzweifle hier ehrlichgesagt langsam :ps:

danke für die ausführliche antwort,
emil

Der MSIE bis Version 8 kann/kennt kein XHTML.
Dem Gerücht nach kann der zwar in gewissem Umfange XML,
wenn der aber XHTML als XML interpretiert, dürften die
Funktionalitäten von XHTML wegfallen, der versteht also nicht
worum es geht. Eventuell kann der auch gar keine
XML-Stilvorlagenverarbeitungsanweisungen interpretieren, folglich
kann er dann auch kein mit CSS dekoriertes XHTML wie
gewünscht darstellen.
Ich meine, die in Arbeit befindliche Version 9 soll eingeschränkt
XHTML interpretieren können, hat vor allem aber wohl Probleme
mit Namensräumen und damit mit eingebetteten anderen
XML-Formaten, wenn man das braucht.

Der MSIE kann hingegen (zumeist) XHTML-Dokumente als
fehlerhaftes HTML interpretieren, weswegen man dem meist
XHTML als fehlerhaftes HTML unterschiebt. Dabei beachtet man
die (nicht normativen) Vorschläge in einem Anhang zu XHTML1.0
transitional. Wenn man sich an die Tips hält, ist mehr oder weniger
sichergestellt, daß der HTML-Markierungssuppen-parser im MSIE
und auch der der allermeisten anderen browser in der Lage ist,
das XHTML ausreichend gut als HTML zu interpretieren.
Genau das ist passiert, wenn man mit dem MSIE bis Version 8
etwas interpretiert sieht, was auf einem XHTML-Dokument
basiert. Für den MSIE kann das sinnvoll sein, weil es Arbeit spart,
bei den meisten anderen browsern, die XHTML interpretieren
können, ist es natürlich nicht sinnvoll, daß diese XHTML als
fehlerhaftes HTML interpretieren. Auch nutzt man dabei nicht
die zahlreichen Vorteile von XHTML, sondern allenfalls Fehler der
HTML-Markierungssuppen-parser, die bei sowas abschmieren täten,
wenn sie nicht die allseits bekannten Fehler hätten, die es
ermöglichen, geeignet notiertes korrektes XHTML als fehlerhaftes
HTML zu interpretieren.

[quote]Ich meine, die in Arbeit befindliche Version 9 soll eingeschränkt
XHTML interpretieren können[/quote]
irrelevant, da immer noch n haufen leute mit dem 7er oder gar dem 6er rumgurken - vom 8er ganz zu schweigen…

[quote]Wenn man sich an die Tips hält, ist mehr oder weniger
sichergestellt, daß der HTML-Markierungssuppen-parser im MSIE
und auch der der allermeisten anderen browser in der Lage ist,
das XHTML ausreichend gut als HTML zu interpretieren.[/quote]
Wie sähe das aus? Ich glaube ich habe schonmal von solchen Dingen gehört, das hatte doch z.B. was damit zu tun, wie man Tags schließt oder? also
oder
und solche sachen?
hast du da vielleicht einen weiterführenden Link oder ähnliches, oder einfach nur ein paar “Grundregeln”, damit die Browser (so wie ich das jetzt verstanden habe) das XHTML als fehlerhaftes HTML interpretieren?

Der entsprechende Anhang C an die Empfehlung von XHTML 1.0:
w3.org/TR/xhtml1/#guidelines

Heutzutage ist das ja eigentlich bei den gängigen browsern nur
noch für den MSIE relevant, die anderen können ja XHTML,
also sendet man denen das nicht als text/html ;o)

Wichtige Sachen für den MSIE:
a) Wissen, was in HTML inhaltsleere Elemente sind wie img, br, link
etc und für diese in XHTML immer die Kurznotation verwenden,
und zwar so
und nicht so
und das geht demzufolge
gar nicht:
. Alles an sich korrektes XHTML, nur das
erste führt erfahrungsgemäß bei gängigen browsern nicht zu
Poblemen, wenn als HTML interpretiert. Bei korrekt arbeitenden
browsern täte das was anderes bedeuten, was etwa ein
HTML-Validator daher anders interpretiert als die fehlerhaften
browser.
Andersherum, alles was in HTML keine inhaltsleeren Elemente
sind, nicht in der Kurznotation verwenden, also nicht


sondern nur
- albern aber notwendig, sonst kann
der browser da ins Schleudern geraten, sowohl ein korrekt
interpretierender als auch ein fehlerhaft interpretierender.

b) Stilvorlagen und Skripte in externe Dateien verlagern, nicht
im Dokument selbst notieren - Interpretation ist in XHTML und
HTML anders, was je nachdem, was man reinschreibt problematisch
sein kann.

c) Korrekte Angaben zur Kodierung vom server senden lassen,
allenfalls zur eigenen Information zusätzlich in der Datei notieren.

d) Elemente, die in HTML impliziert werden, explizit hinschreiben
(kommt etwa bei Tabellen vor)

e) Verarbeitungsanweisungen machen dem MSIE Probleme, da ist
es besser, die etwa per PHP-Skript nur auszugeben, wenn man
das Dokument an andere browser als XHTML ausliefert, da sollte
man das dann aber tun.
Also die XML-Anweisung lasse ich eigentlich meistens drinstehen,
hat dann aber zur Folge, daß der MSIE auch in aktuellen Versionen
die Fehler alter Versionen simuliert - allerdings auch nicht exakt.
Stört mich aber nicht weiter, weil ich davon ausgehe, daß Leute,
die den benutzen, ohnehin nicht sonderlich dran interssiert sind,
etwas wie vom Autor vorgesehen dargestellt zu bekommen ;o)
XML-Stilvorlagenverarbeitungsanweisungen habe ich hingegen
bei einem Projekt für den MSIE ausgespart und ein paar andere
Details, um den nicht mit etwas zu belästigen, was er ohnehin
nicht versteht - die Dekoration ist bei dem dann eben sehr
minimalistisch, Inhalt wird aber sinnvoll dargestellt, nur eben nicht
mehr dekoriert.

Da obige nicht normative Tips inzwischen auch schon recht alt sind,
muß nicht alles auf den MSIE zutreffen, empfiehlt sich also, einige
speziellere Dinge, die dort erwähnt sind, zu testen, ob die wirklich
Probleme bereiten, wenn nicht, kann man den jeweiligen Tip
vergessen.

Okay, zu a) - lässt sich doch relativ leicht umsetzten, denke ich, gut.
b) mache ich sowieso standartmäßig so - auslagern, was man auslagern kann
c) lass ich mal eben aus, ich komm später drauf
d) meinst du damit, dass man alle „zwischenelemente“ wie tbody, thead bei ner tabelle mit schreiben muss?
e) inwiefern? also ich meine was meinst du mit verarbeitungsanweisungen? sowas? [quote]<?xml-stylesheet type="text/css" href="fahrplan.css" ?>[/quote]

okay, jetz zu c)…
Wenn ich jetzt den Quellcode in xhtml schreib - aber eben diese tipps einhalte, und ich will dasser vom IE als fehlerhaftes HTML interpretiert wird, wäre mein erster gedanke, mit zb php abzufragen, ob der client (vorgibt) xhtml zu können, und dann entsprechend nur doctype und mime-type „browser-spezifisch“ auszugeben - mit entsprechenden header()n natürlich…
sprich, entsprechend als text/html bei doctype html 4.01 oder bei jedem anderen browser application/xhtml+xml bei doctype xhtml 1.0 auszuliefern. - oder hab ich das jetzt wieder falsch verstanden?
// Sry wenn ich hier etwas dämlich frag, aber ich will das jetzt endlich mal kapieren ;o)

meine güte, is ja ne philosophie für sich :wink: ich erinnere mich noch an die 7. Klasse, als der Lehrer sagte „Soo, jetz lernen wir HTML, das is ganz ganz einfach, keine Angst…“ :ps:

zu d) genau die schreibt man explizit auf, was speziell dann relevant
wird, wenn man in CSS etwas mit Selektoren auswählt, denn da
zählen in HTML die implizierten Elemente mit, XHTML nur die
wirklich explizit hingeschriebenen.
e) ja genau, bei XHTML wird man Stilvorlagen ja ohnehin gerne
mit dem Element link referenzieren, ist also nicht wirklich ein
Problem - link geht bei HTML und XHTML, nicht aber allgemein bei
beliebigen XML-Formaten.

zu c) es geht da eher um die Kodierung, also etwa ob UTF oder ISO
oder windows etc.

Zu dem, was du meinst:
Die doctype-Angabe gehört ja zum Dokument, die sollte also
zu dem passen, was das Dokument ist (XHTML), nicht unbedingt
zu dem, als was der browser es dann interpretiert, als HTML, wenn
man es ihm als text/html sendet.
Einen anderen doctype für HTML würde man nur reinschreiben,
wenn man wirklich das gesamten Dokumente vor der Ausgabe
einen parser schickt, der dann auch dem korrekten XHTML ein
korrektes HTML-Dokument produziert. Wenn man den Tips
folgt, erhält man zwar immer noch ein gültiges XHTML-Dokument,
aber noch lange kein korrektes HTML-Dokument.
Was sich also ändert, ist die Interpretation durch den browser,
nicht das eigentliche Dokument.

Hinsichtlich des Tests mache ich das bei meinen Skripten, daß ich
per PHP gucke, ob der browser application/xhtml+xml explizit
kennt, oder zumindest application/xml oder auch text/xml, dann
bekommt er das entsprechend serviert. Kennt der all das nicht,
aber text/html, bekommt er es als text/html serviert.
De Haken ist, daß die meisten browser behaupten, sie könnten
mit / also allem umgehen, was sicherlich übertrieben ist, daher
ignoriere ich diese Angabe.
Wenn man das macht, stellt man fest, daß man beim MSIE immer
noch nicht weiß, was der kann oder nicht, weil er keine der vier
Möglichkeiten explizit angibt ;o) Ähnliches gilt wohl auch für den
ähnlich problematischen Google-Bot.
An der Stelle, also nur wenn die anderen Zuordnungen nicht
klappen, lasse ich anhand der Angaben zum user-agent raten, ob
es ein MSIE oder Google-Bot ist oder etwa ein antiker netscape.
Von denen weiß ich ja, daß sie kein XHTML mögen, deswegen
bekommen die dann text/html serviert.
Weil der user-agent gefälscht sein kann, wäre es nicht schlau,
das als erstes zu testen. Weil die browser zum Inhaltstyp
ehrlichere Angaben machen als zum user-agent, weswegen der
Inhaltstyp für mich wichtiger ist als der user-agent.
Jedenfalls bleiben dann noch browser übrig, die keines der vier
Formate als bekannt angeben und auch nicht zu Google gehören
oder ein netscape oder MSIE sind. Weil ich von denen nichts
weiß und keine sinnvolle Information bekommen, bekommen die
den Kram als application/xhtml+xml serviert und müssen sehen,
wie sie damit zurechtkommen ;o) Letztere Gruppe kann man
natürlich noch reduzieren, indem man weitere spezielle Regeln
aufstellt, entsprechend denen zu netscape, MSIE und Google, wenn
man von einigen von ihnen genau herausgefunden hat, was die
können und was nicht.

Zur Frage, ob HTML einfach ist - ich meine eher, das XHTML1.1
deutlich einfacher ist. Nur darf man sich da eben keinen groben
Fehler erlauben, sonst wird im browser nichts angezeigt außer
einer Fehlermeldung - davor haben viele Leute Angst.
Ob insgesamt einfach oder nicht - nunja, nach einer Untersuchung
von Google sind meine ich über 95% aller denen bekannten Seiten
grob fehlerhaft (einschließlich vieler von Google selbst) - insofern
kann man zumindest behaupten, daß (X)HTML zu schwierig für die
allermeisten Autoren ist ;o) Und bei der Untersuchung geht es
nur um mit einem Validator einfach festzustellende Fehler, das
bezieht nicht ein, daß viele Autoren die inhaltliche Bedeutung von
Elementen nicht verstehen und sie falsch verwenden.

Jedenfalls hat die Hirnwichserei, die man veranstaltet, wenn man
XHTML als HTML ausliefert, nichts mit der eigentlichen Sprache
zu tun, das ist mehr ein Problem, wie man mit fehlerhaften oder
antiken browsern so geschickt umgeht, daß die immer noch etwas
anzeigen, was halbwegs lesbar ist - das ist ein ganz anderes
Kaliber als XHTML oder HTML selbst korrekt zu verwenden, was
einfacher ist.

Das habe ich jetzt schon relativ oft gelesen - nicht nur hier im forum, auch wenn ich mal was gegooglet habe. Aber ein Browser wird doch sicher nicht einfach von sich aus anfangen, seinen user-agent zu manipulieren oder? denn wenn der user selbst das machen kann, dann muss er auch wissen, was es damit auf sich hat und welche probleme daraus für ihn resultieren könnten, und ich müsste keine rücksicht darauf nehmen - oder ist es tatsächlich so, dass die browser “von sich aus” da manchmal müll reinschreiben?

[quote]Die doctype-Angabe gehört ja zum Dokument, die sollte also
zu dem passen, was das Dokument ist (XHTML), nicht unbedingt
zu dem, als was der browser es dann interpretiert, als HTML, wenn
man es ihm als text/html sendet.[/quote]
Ahja, okay, das macht sinn. Das heißt also, ich muss nachdem ich herausgefunden habe mit was der browser zurecht kommt, nur den header ändern, mit dem ich das dokument ausliefere, also

$mime_type = "application/xhtml+xml"; $charset = "utf-8"; //Hier entsprechend dem Browser anpassen, zb $mime_type = "text/html"; header("Content-type: $mime_type; charset=$charset");
Und nach einhaltung der vorhin genannten tipps sollte der browser es dann in diesem bsp als fehlerhaftes text/html interpretieren können.

[quote]sonst wird im browser nichts angezeigt außer
einer Fehlermeldung[/quote]
yo, hat ich auch schon des öfteren :wink: andererseits sieht man dann ja sofort, dass man nen fehler hat (syntax-fehler zumindest)… ich meinte nicht die sprache an sich, weder syntax noch semantik - inzwischen hab ich verstanden, dass html zur strukturierung dient und man passende elemente wie eine liste für die navi nehmen soll… ich meinte viel mehr das alles so auszuliefern, dass auch das leider mit am meisten verbreitetste und mieseste produkt (ich denke es ist klar von wem ich rede :stuck_out_tongue:) damit klar kommt.
Das traurige ist, dass die homepage, die ich verwalte, an einen relativ alten kreis gerichtet ist, wo man froh sein kann, dass sie einen pc besitzen, ihn dann auch noch benutzen und dann auch noch auf die seite zu gehen - da kann man echt nicht auch noch erwarten, dass die chrome oder foxy benutzen, der IE is halt nun mal standartmäßig…

Das Fälschen der Angaben zum user-agent hat eine alte Tradition,
die es schon im letzten Jahrtausend gab.
Es begab sich zu der Zeit, daß kaum jemand etwas anderes
benutzte als den browser netscape (der sich mit dem Spitznamen
mozilla zu erkennen gab). Anbieter exotischerer browser wie
etwa microsoft mit dem MSIE hatten dann ein Problem, daß ihr
Teil deutlich anders funktionierte als der Mehrheits-browser, war
fehlerhafter oder stellte fehlerhafte Seiten anders dar als netscape,
was nicht unbedingt selbst ein Fehler sein muß. Jedenfalls wurden
Autoren darauf aufmerksam und begannen, die Angaben zum
user-agent auszulesen und den ausgegebenen Inhalt davon
abhängig zu machen. Darauf reagierend hat der MSIE begonnen,
sich einfach als mozilla auszugeben (tut er heute noch - ohne
Wahlmöglichkeit durch den Nutzer).
Das nächste wichtigere Kapitel hat sich ergeben, als microsoft
begonnen hat, auf eigenen Seiten den browser Opera zu
boykottieren, indem diesem teils unsinnig aufbereiteter Inhalt
ausgeliefert wurde, während etwa MSIE und mozilla-artige
anderen, anzeigbaren Inhalt bekommen haben. Daraufhin hat
Opera systematisch angefangen, die Angaben im user-agent
zu fälschen, hat sich als der MSIE ausgegeben, der sich als
mozilla tarnt. Zudem hat Opera microsoft verklagt und gewonnen
und dafür eine Menge Geld bekommen (andere Geschichte).
Andere browser, die nicht so häufig benutzt wurden, hatten auf
einigen Seiten ähnliche Probleme mit absichtlich oder versehentlich
pessimiertem Inhalt, weswegen man etwa bei Konqueror frei
wählen konnte. Auch Opera hat dann alternativ zur Maskierung
auch noch eine Methode angeboten, wo man bei bestimmten
Seiten die Angaben zum user-agent identisch zu einem anderen
browser senden konnte, um solchen Unfug zu umgehen.

Der Ursprung der Fälschung liegt also gerade darin, daß Autoren
mangelhafte Skripte nutzen, um browser zu identifizieren und
dann jeweils andersartigen Inhalt zu senden. Wären die Skripte
immer gut durchdacht und sinnvoll angewendet, hätte da
niemand was dagegen, aber meist sind sie schlecht und
unvollständig, so daß man oft mit browsern, die dem Autor
nicht bekannt sind, mangelhaften Inhalt serviert bekommt,
was eine Gegenwehr provoziert. Alternativ kann es auch passieren,
daß der Autor irgendein Problem mit einem bestimmten browser
hat (etwa microsoft mit Opera) und deshalb Blödsinn an den
browser ausgibt - was letztlich nur die Dummheit und soziale
Inkompetenz des Autors offenlegt, was dem Nutzer aber nichts
hilft, wenn der am Inhalt der Seite interessiert ist und nicht am
Autor oder Herausgeber.
Also nein, die Nutzer wehren sich nur gegen Unfug.

In dem XHTML/HTML Beispiel wäre es etwa unsinnig, das
XHTML an unbekannte browser pauschal als HTML zu senden.
Und es wäre auch unsinnig, das XHTML an einen MSIE 9 als
HTML zu senden, wenn der XHTML interpretieren kann - für
Sonderregeln muß man als Autor also genau wissen, welche
Version die normale Ausgabe nicht interpretieren kann, um dafür
eine Extrawurst anzubieten. Und dann muß man die Situation im
Auge behalten, ob sich da was ändert, was dann dazu führt, daß
man sein Skript anpassen muß.
Deswegen ist es immer besser, soweit möglich, sich auf das zu
beziehen, was die browser von sich behaupten, was sie können,
statt pauschal über noch unbekannte Versionen Hypothesen
aufzustellen, die dann wenn sie verwendet werden, zu
suboptimalen Ergebnissen führen.
Wenn ein browser wie im Falle des MSIE keine konkreten Angaben
über sein Können macht, ist die Situation nochmal problematischer,
Fehleinschätzungen sind da dann teilweise natürlich auch vom
browser-Anbieter verschuldet, was aber auch dem Nutzer nichts
hilft, der nur die jeweilige Seite lesbar angezeigt haben will.

Wie man am Beispiel microsoft/Opera sieht, kann ein Mißbrauch
durch den Autor auch sehr teuer werden.

[quote]Das Fälschen der Angaben zum user-agent hat eine alte Tradition,
die es schon im letzten Jahrtausend gab.
Es begab sich zu der Zeit, daß kaum jemand etwas anderes
benutzte als den browser netscape (der sich mit dem Spitznamen
mozilla zu erkennen gab). Anbieter exotischerer browser wie
etwa microsoft mit dem MSIE hatten dann ein Problem, daß ihr
Teil deutlich anders funktionierte als der Mehrheits-browser, war
fehlerhafter oder stellte fehlerhafte Seiten anders dar als netscape,
was nicht unbedingt selbst ein Fehler sein muß. Jedenfalls wurden
Autoren darauf aufmerksam und begannen, die Angaben zum
user-agent auszulesen und den ausgegebenen Inhalt davon
abhängig zu machen. Darauf reagierend hat der MSIE begonnen,
sich einfach als mozilla auszugeben (tut er heute noch - ohne
Wahlmöglichkeit durch den Nutzer).[/quote]
rofl :smiley: :ps: !haue

[quote]Ahja, okay, das macht sinn. Das heißt also, ich muss nachdem ich herausgefunden habe mit was der browser zurecht kommt, nur den header ändern, mit dem ich das dokument ausliefere, also
Code:
$mime_type = „application/xhtml+xml“;
$charset = „utf-8“;
//Hier entsprechend dem Browser anpassen, zb $mime_type = „text/html“;
header(„Content-type: $mime_type; charset=$charset“);

Und nach einhaltung der vorhin genannten tipps sollte der browser es dann in diesem bsp als fehlerhaftes text/html interpretieren können.[/quote]
aber vom prinzip her haut das jetz hin oder? auf der frage beharr
ich muss nur den header anpassen, da der doctype sich auf das dokument bezieht und immer gleich bleiben muss… ja/nein? grins

Klar, sinngemäß macht man das so.
Da du die Kodierung (charset hier) wohl nicht browser-abhängig
gestalten wirst, brauchst du dafür auch keine Variable und kannst
das immer gleichlassen ;o)

Doctype bleibt auch derselbe, solange du das Dokument nicht auf
dem server transformierst. Theoretisch könntest du auf dem server
natürlich auch die Kodierung transformieren, dann wäre da auch
eine Variable sinnvoll. Weil du aber beides nicht tun wirst, ist
also nur die Angabe zu $mime_type variabel vom browser
abhängig.

wow, ich glaub ich hab in den letzten 2 tagen ne menge über html gelernt :slight_smile:
charset würde ich auch immer gleich lassen, das ist nur von nem code kopiert, den ich schonmal verwendet hatte, also nich wundern…

also danke nochmal für alles!
mfg
emil