nicht angemeldet
Gunnar BittersmannHello out there!
Das ist schon richtig, dennoch machen es viele Autoren nicht. genauso wie alle anderen wichtigen Punkte, dei bei XHTML beachtet werden müssen (z.B. Wohlgeformtheit).
Für Autoren, die keinen Wert auf validen, ja nicht einmal wohlgeformten Quelltext Wert legen, ist XHTML sicher nicht das richtige. Die sollen Tagsoup schreiben (ich sagte bewusst nicht „HTML 4“) oder besser noch die Finger von Quelltext lassen und einen wysiwYg-Editor nutzen.
Autoren, die jedoch sauberen Quelltext möchten, bietet XHTML 1.0 gegenüber HTML 4.01 Vorteile: eben die sauberere XML-Syntax gegenüber SGML. Solche Autoren sollten dann auch in der Lage sein, den Viewport mittels 'html' zu selektieren – falls überhaupt gewünscht ist, dass das XHTML-Dokument jemals als 'application/xhtml+xml' von einem Browser verarbeitet wird.
Die Vorteile von XHTML sehe ich – wie schon oft gesagt – nicht beim Browser, sondern bspw. bei der XML-Verarbeitung durch einen Validator.
Wirkliche Nachteile sehe ich nur einen: die Dopplung von 'xml:lang' und 'lang'. Dieselben Daten doppelt anzulegen, ist für einen Informatiker ein Albtraum. (Sollte es jedenfalls sein.)
Gerade das ist ja das Problem. In XHTML ist <[CDATA[ nötig, in HTML verursacht es Fehler. Natürlich kann man es auskommentieren, macht aber niemand.
Natürlich macht man das. Und natürlich nicht so bescheuert, wie es Hickson propagiert. [</archiv/2007/11/t162468/#m1058660>]
Also rate ich von vornherein zur Aulagerung.
Ich auch – aber aus anderen Gründen: der Trennung von Inhaltsstruktur, Präsentation und Verhalten [molily] – das auch bei HTML 4.01 (wenn ich sowas denn schreiben würde).
Abhilfe könnte geschaffen werden, indem man im XHTML-Quelltext nur 'xml:lang' schreibt und diesen als 'application/xhtml+xml' an verständnisvolle Clients ausliefert; für andere Clients diese Quelle mit XSLT transformiert in HTML oder kompatibles XHTML ('text/html'). Die Transformation kann dann auch PIs in 'link'-Elemente umsetzen.
Diese Methode hab ich bereits vorgeschlagen, wurde aber von dir nicht ernst genommen.
Ich hatte dich so verstanden, du wolltest die Seiten in irgendwelchem XML pflegen und für alle Clients nach HTML transformieren. Ich meine, die Seiten in XHTML zu pflegen und dieses auch genauso auszuliefern, aber für unfähige Browser nach HTML zu transformieren.
Ist aber noch nicht ganz durchdacht, was für Vorteile hätte das gegenüber HTML-kompatiblem XHTML als 'text/html' für alle?
Woher willst du wissen, dass im Stylesheet oder im JavaScript keine < oder & vorkommen? Autoren sind diesbezüglich nicht vertrauenswürdig.
'<' und '&' können in JavaScript natürlich durchaus vorkommen. Am besten doch alle Scripte in XHTML als CDATA markieren.
Cybaer würde raten, Scripte so zu schreiben, dass sie weder '<' noch '&' enthalten, aber der tut ja einige komische Dinge. >;->
Stylesheets – naja. Im Wert der 'content'-Eigenschaft könnten solche vorkommen, sonst wüsste ich nicht wo. Da hilft auch kontextspezifische Codierung. Der Kontext ist nicht HTML, sondern CSS; also nicht '<' und '&', sondern '\3C ' und '\26 '.
Aber wir raten ja sowieso zur Trennung von Inhaltsstruktur, Präsentation und Verhalten.
Es ist ein Punkt der wegen Browserkompatibilität beachtet werden muss, daher hab ich ihn genannt.
Kannst du gerne tun, aber bitte nicht als falsches Argument zu einer Sache, wo der Punkt keinerlei Relvanz hat.
Nein ist es nicht. Schneegans sag hierzu:
„Vermeiden sollte man [...] den ganzen Rest wie ä oder , denn diese sind in der DTD deklariert.“
Wer einen XHTML-Client baut, der die in XHTML definierten Entities nicht kennt, der produziert Schrott. Dann schon lieber so ehrlich sein wie Microsoft und sagen: Wir unterstützen 'application/xhtml+xml' nicht.
Ein XHTML-Client MUSS 'ä' und ' ' kennen, sonst ist er keiner.
table > tr geht auch nicht.
Na und? Der Selektor sollte wozu nütze sein?
Wo steht eigentlich geschrieben, dass bei XML-Verarbeitung createElement() nicht verwendet werden darf?
Dort lese ich: „Note: DOM Level 1 methods are namespace ignorant. Therefore, while it is safe to use these methods when not dealing with namespaces […]“
„Safe“ klingt für mich anders als „darf nicht verwendet werden“. Wo steht, dass DOM Level 1 nicht mit XHTML als 'application/xhtml+xml' verwendet werden darf?
Im Gegensatz zur verarbeitung als HTML wird das dadurch erzeugte Element in XHTML-Dokumenten nicht angezeigt (bzw. verhalten sich die Browser hier sehr unterschiedlich).
Dann sag bitte statt „kann in XHTML nicht verwendet werden“ besser „ist in einigen Browsern falsch implementiert“, sonst klingt das wie „gibt es in XHTML nicht“, besonders wenn du das in einem Atemzug mit anderen Dingen nennst, die es angeblich in XHTML nicht gäbe.
See ya up the road,
Gunnar
„Und [dieses Forum] soll […] auch ein Fachforum bleiben und kein Psychologieforum werden.“ (Kirsten Evers)