nicht angemeldet
Hallo,
Achso, das meinst du. Was hindert einen Stylesheetautor daran, Angaben für den Viewport nicht für den Selektor 'body', sondern für 'html' zu machen? Das funktioniert in Tagsoup-Parsern als 'text/html' genauso wie bei XML-Verarbeitung als 'application/xhtml+xml' gleichermaßen. Kein Mehraufwand.
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).
?? Müssen doch gar nicht. Für Tagsoup-Parser sind Inhalte von 'script'- und 'style'-Elementen doch vom Typ CDATA, wie es HTML 4 spezifiziert ist.
(Ebendeshalb müssen ja (einige!) Scripte in XHTML als CDATA gekennzeichnet werden, damit sie als 'text/html' wie als 'application/xhtml+xml' gleichermaßen verarbeitet werden.
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. Also rate ich von vornherein zur Aulagerung.
Was ist daran nachteilig? Es spricht eigentlich nichts dafür, eine andere Codierung als UTF-8 einzusetzen (bei Alphabeten, deren Buchstaben UTF-8-codiert 3 oder 4 Oktetts benötigen, evtl. UTF-16).
Ich sage nicht, dass es nachteilig ist. Ich sage es sei nachteilig, wenn man es nicht einsetzt (wans genug angeblche XHTML-Seiten machen).
Best practice jedoch: UTF-8, keine XML-Deklaration, keine Probleme.
Da sind wir uns einig.
* XML-Features dürfen nicht genutzt werden: Beispielsweise CDATA-Bereiche, […]
Wofür willst du die brauchen?
Die Frage hast du dir weiter oben selbst beantwortet.
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.
Nebenbei zeigt Schneegans' Schema Validator den Hinweis an, man solle doch das lang-Attribut auch einfügen.
?? Verstehe hier nicht ganz, worauf du hinauswillst.
Woher willst du wissen, dass im Stylesheet oder im JavaScript keine < oder & vorkommen? Autoren sind diesbezüglich nicht vertrauenswürdig.
Das tut hier nichts zur Sache. Du sprachst von Mehraufwand des Schreibens von XHTML gegenüber dem Schreiben von HTML; dafür ist das kein Argument.
Es ist ein Punkt der wegen Browserkompatibilität beachtet werden muss, daher hab ich ihn genannt.
Das tut hier nichts zur Sache. Du sprachst von Mehraufwand des Schreibens von XHTML gegenüber dem Schreiben von HTML; dafür ist das kein Argument.
Wo doch die XML-Schreibweise weniger Zeichen verbraucht ;)
Dieses Märchen hattest du schon in [</archiv/2007/11/t162468/#m1057290>] erzählt. Spätestens seit meiner Antwort [</archiv/2007/11/t162468/#m1060568>] sollte klar sein, dass dies falsch ist.
Nein ist es nicht. Schneegans sag hierzu:
Vermeiden sollte man [...] den ganzen Rest wie ä oder , denn diese sind in der DTD deklariert.
Danach weist er noch darauf hin, dass man die Referenzen im Mozilla nur ausnahmsweise verwenden kann, obwohl kein validierender Parser vorhanden ist. Ansonnsten führt & in einem nicht validierendem Parser zu Fehlern.
Entschuldige, dass ich diese Antwort nicht mehr gelesen habe, ich war die Woche darauf nicht zu Hause und habe später nicht mehr daran gedacht.
Wofür sollte man das brauchen?
Wofür sollte man das brauchen?
Ich brauche beides nicht, aber wenn ich suche finde ich bestimmt eine Webseite die beide trotz XHTML-Quelltext verwendet.
Wozu willst du das Zeichen brauchen? Außerdem tut das hier nichts zur Sache. Du sprachst von Mehraufwand des Schreibens von XHTML gegenüber dem Schreiben von HTML; dafür ist das kein Argument.
Nun, das Zeichen ist nur ein Beispiel, das ich aus Anhang C geklaut habe. Ich spreche allgemein von den Unterschieden zwischen HTML und XHTML als text/html.
Damit ein XHTML-Dokument als Tagsoup denselben Elementbaum erzeugt wie bei Verarbeitung als XML muss also 'tbody' explizit vorhanden sein. Geringer Mehraufwand.
Dennoch wichtig.
Aber nur nötig, wenn über JavaScript/DOM auf Tabellen zugegriffen wird oder im Stylesheet Selektoren stehen, die 'tbody' enthalten, was sich aber stets vermeiden lässt.
table > tr geht auch nicht.
Ebenso Level-1-Methoden des DOM wie createElement. Hier müssen die Namensraumfähigen Varianten dieser Methoden verwendet werden.
Nein, sie können nicht so ohne weiteres verwendet werden, wenn’s HTML-kompatibel sein soll.
Nun, im Gegensatz zu createElement in XHTML verhält sich createElementNS in HTML in den Browsern überall gleich.
Wo steht eigentlich geschrieben, dass bei XML-Verarbeitung createElement() nicht verwendet werden darf?
DOM-2-Core, 1.1.8 XML Namespaces. Daraus folgere ich, dass createElement in XHTML nichts zu suchen hat. Mozilla scheint mir hier zuzustimmen.
Noch so ’ne Kamelle! Auch dieses Märchen hattest du schon in [</archiv/2007/11/t162468/#m1057290>] erzählt. Spätestens seit meiner Antwort [</archiv/2007/11/t162468/#m1060568>] sollte klar sein, dass auch dies falsch ist.
Im Gegensatz zur verarbeitung als HTML wird das dadurch erzeugte Element in XHTML-Dokumenten nicht angezeigt (bzw. verhalten sich die Browser hier sehr unterschiedlich).
Namensräume haben damit gar nichts zu tun. Die beinhalten lediglich Elemente (Attribute). Ob und wie alle diese in einem Namensraum vorhandenen Elemente auch tatsächlich in einer diesen Namensraum verwendenden Sprache vorkommen dürfen, regelt die DTD (bzw. XML Schema). Bedenke, dass auch XHTML 1.0 Strict, XHTML 1.0 Transitional und XHTML 1.0 Frameset denselben Namenraum verwenden, aber unterschiedliche DTDs, also unterschiedliche Regeln haben.
Da muss ich dir zustimmen, da habe ich nicht ganz so weit gedacht.
Gruß;
Gunnar Bittersmann