Hallo Forum,

wie wirkt es sich eigentlich aus, wenn ich eine (valide) XHTML-Seite mit dem DOCTYPE für HTML Transitional versehe?

Mal abgesehen davon, dass der Validator Fehler anzeigt - kann es Probleme mit der Barrierefreiheit geben, wenn unter HTML Transitional (oder Quirks-Mode) Befehle wie oder <hr noshade="noshade" /> auftauchen?

Gruß
Andy

Meinst du nicht, ein Beitrag reicht?

Im Normalfall passiert nichts, die Browser ignorieren den Slash / einfach.

__________________
“My software never has bugs. It just develops random features ...”

» DevShack - die Website des freien Webentwicklers Boris Bojic

Wie schon gesagt wurde, den zusätzlichen "/" ignorieren die Browser.

Problematisch kann/wird der XML-Prolog werden, sofern verwendet. Der gehört nämlich nicht ins HTML(deutet ja XML an) und versetzt den IE in den Quirks-Modus.

Nein, aber man sollte im Bezug "Barrierefreiheit" ein valides Markup verwenden. Damit ist gemeint, das es egal ist, ob man HTML, XHTML oder XML verwendet, es sollte nur valide sein.

Ein weiterer Punkt hierzu ist, das es zwei Arten von Barrierefreiheit gibt. Eine deutschsprachige die sich an der BITV orientiert, sowie eine internationale, die sich an der WCAG des W3C orientiert. Die BITV hat als Grundlage die WCAG, ist aber eher als Vorschrift anzusehen. Die WCAG dagegen enthält nur Empfehlungen, ist aber richtungsweisend und bindend.

Somit ist Barrierefreiheit ein weiter Begriff, so wie die unendlichen Weiten des WWWs

Das Forum grüßt freundlich zurück.

Probleme gibt es nicht, solange du dein XHTML HTML-kompatibel schreibst (also Leerzeichen vor den Slashs einfügst, keine Dinge wie <script ... /> verwendest usw., siehe Appendix C).

Allerdings frage ich mich, wo der Sinn darin liegt. Wieso willst du unbedingt die XHTML-Syntax verwenden? - Oder andersrum: Wieso möchtest du einen HTML-Doctype einsetzen?

Wenn es dir nur darum geht, im IE6 den Quirks-Modus anzuschalten (was ich vollkommen unverständlich fände), kannst du genausogut, wie Cyberman schon sagte, eine XML-Deklaration vor den (XHTML-)Doctype einfügen. Ein Kommentar tuts übrigens auch.

Ein Freund von mir wollte letztens XHTML-konformes HTML schreiben, weil er nirgends gelesen hatte, dass man nicht gleichzeitig XHTML- und HTML-konform sein kann. Zur Verwirrung trug dann auch bei, dass Dinge wie
und <img /> nicht mal invalides HTML sind - sie werden nur vom Validator anders (richtig) interpretiert als vom Browser.

Ach, zu den Beispielen, die du gebracht hast (
und <hr noshade="noshade" />):
Wo Zeilenumbrüche gewollt sind, ist meistens ein p-Element (Absatz) angebrachter. Der Semantik-Gott möchte ja gerne wissen, aus welchem inhaltlichen Grund du gerne einen Zeilenumbruch hättest.
Und eine horizontale Linie lässt sich sehr schön mit den CSS-Eigenschaften border-top bzw. border-bottom erreichen.

Hm. Meinst du, man kann mit XML barrierefreie Seiten erstellen? Ich wüsste jetzt auf Anhieb nicht, wie das gehen könnte. Ist aber ein interessanter Gedanke.

Viel Spaß noch
Markus

XML, was ist/soll das?

- XML ist/soll die Grundlage für XHTML (sein)
- XML trennt explizit Inhalt vom Design, somit der Idealfall für Barrierefreiheit

XML ist für viele Browser ein Problem, wenn explizit nur reine XML-Syntax verwendet wird (XLINK, XPATH, XPointer, XFORMS). Der riesen Nachteil von XML ist es mit CSS-Design zu kombinieren. Einer der Gründe warum HTML, XHTML weiterentwickelt wird (siehe HTML 4.02/5.0 und XHTML 2.0)

Im Grundstock ist XML erstklassig, der Inhalt wird einfach als Text geschrieben. Das Ziel hierbei ist, das jeder sein eigenes Design dazu selber erstellen kann, ohne den Inhalt zu berühren. Was leider nicht sauber funktioniert

So wie SVG? ;)

Im Übrigen verläuft die »ideale« Trennung zwischen Struktur und Präsentation – das ist etwas ganz anderes.


Gruß
Thomas, der nicht widerstehen konnte

__________________
toscho.de

Das Problem ist folgendes: Einige unserer Autoren arbeiten im CMS mit HTML (die Mehrheit mit XHTML) an verschiedenen Websites, versteht sich. Unser in das CMS integrierbare Editor schreibt eben XHTML, also Ich habe meine Skrupel, diesen dann für HTML zu empfehlen ...

Andreas

(Entschuldigung für den "doppelten" Beitrag ganz oben - das kam durchs "Rückwärtsblättern" im Browser...)

Das ist das Problem, was ich bei der Überlegung hatte, XML als Barrierefreiheitsgrundlage einzusetzen. Das Hauptmerkmal von barrierefreihen Seiten ist ja, dass sie möglichst überall nutzbar sind; davon kann aber aufgrund der mangelnden Unterstützung nicht die Rede sein.

Volltreffer!