Strict wann immer es geht. Ein wesentlicher Unterschied ist wohl das target-Attribut. Aber der Doctype macht eine Seite nicht gleich barrierefrei.Strict stellt erstmal sicher, daß die Struktur von Präsentation und auch Verhalten getrennt ist. Das ist ein wichtiges Qualitätskriterium (allerdings nur wenn der Code auch validiert).

Bevorzuge auch die Strict definition. Mann muss zwar ein paar Abstriche hinnehmen, wie besagtes "target" Attribut in Links oder etwa dem "width" Attribut in <td>'s, aber das zwingt einen auch auf eine saubere Trennung zwischen Ausgabe(HTML / XHTML / etc.) und Layout( CSS / XSLT / etc. ) zu achten. Mann muss jedoch abwägen welches DOCTYPE man wählt, den oft gibt es ja User die einfach zu faul sind Links über die rechte Maustaste zu öffnen um Sie in einem extra Tab oder Fenster zu bekommen.

Und sicherlich sollte das was man Programmiert auch am ende eine validen Ausgabe erzeugen, das gilt natürlich nicht nur dann wenn du die "Hardcore" version Strict benutzt.

Danke für Eure Beiträge.

Ich habe selbst noch ein wenig recherchiert und komme zu dem Schluss, dass ein verantwortungsvoller HTML-Coder mit Blick in die Zukunft eigentlich nur strict verwenden kann.

Die DTD für transitional taugt nur für Leute, die sich nicht vollends davon überzeugen lassen, dass man tatsächlich Struktur (HTML) und Optik (CSS) komplett voneinander trennen kann. Wenn ich schon CSS verwende, wozu dann noch so etwas schreiben, wie:


Gegenreden?

beste.grüße:maak.

Ich verwende nur transitional.

1. Bin ich doch noch nicht sooo lange mit CSS beschäftigt um wirklich komplett darauf einzusteigen.
2. Versuche ich dem Kunden das zu verkaufen was er braucht und das lässt sich bis jetzt immer gut mit transitional lösen. Der Blick in die Zukunft ist hier glaub ich eher zweitrangig, da ich, sollte ich unbedingt nach strict programmieren, wohl doppelt so viel kosten würde ;-)

Dafür sind meine Seiten aber wenigstens nach transitional validiert und selbstverständlich auf die gängigen Browser optimiert.

Meines Wissens liegt der entscheidende Unterschied zwischen strict und transitional darin, das bei transitional-gecodeten Seiten auch ältere HTML-Tags verwendet werden dürfen, als die im Doctype deklarierte (X)HTML-Version eigentlich zulässt.
Korrigiert mich wenn ich da falsch liege...

Im übrigen stellt eine strict-validierte Seite leider auch nur einen Anfang in Sachen Barrierefreiheit dar. Je nachdem, an welchem Standard man sich da orientiert, gehören da teilweise noch eine ganze Menge anderer Dinge hinzu...was die Sache dann aber auch meistens sehr aufwendig (und teuer) macht.

Prinzipiell kann ich aber nur zustimmen, wann immer es möglich, ist seine Seiten strict-konform runterzutippeln (einige CMS- und Shop-Systeme lassen das ja leider nicht zu) um die vielbeschworene Trennung von Layout und Content jederzeit zu gewährleisten.

Beste Grüße
Jens

P.S.: Mal ne andere Frage: Wie steht ihr denn zur Verwendung von JavaScripten in euren Seiten? Nützlich? Überflüssig? Hübsch? Sicherheitsrisiko? Würd mich mal interessieren...bei Kunden kommt das ja immer ganz gut an, die Seiten optisch bissl mit JavaScripten zu pimpen. Persönlich verweigere ich mich aber immer gerne, da ich auch nur mit deaktivierten JS surfe...

Also ich versuche meine Seiten immer auf Basis von XHTML Strict und CSS2 zu gestalten. Grundsätzlich gehe ich immer von der höchsten gültigen Norm aus.

Viel Abstriche muss man dabei eigentlich nicht in Kauf nehmen, da ich sehr selten Websites mit mehreren einzelnen Seiten (HTML-Seiten) erstelle. Zu 98% sind es nur Inhalte die in eine bestehende index Datei eingebunden werden. Meist via PHP / ASP / SSI. Daher spielt das Target Attribut für mich weniger eine Rolle. Die optimale Trennung von Inhalt von Gestaltung steht hierbei im Vordergrund, welches auch die Basis zur Erstellung für barrierefreie Websites darstellt. Auf dieser Grundlage und mit dem korrekten Einsatz der jeweiligen HTML-Tags kommt man so zu sehr guten Ergebnissen.

Die Zeiten in denen man die HTML-Tags an einer Hand abzählen konnte sind längst vorbei. Vor einigen Jahren genügte es, sich mit Tabellen, Frames und einigen Textformatierungen wie bold, italic etc. auszukennen. Wie gesagt die Zeiten haben sich geändert.

CSS3 ist dabei der nächste Schritt der Evolution, da es unglaubliche und längst überfällige Optionen bietet welches das Webdesigner Herz höher schlagen lässt. Also ich freue mich darauf, das Web in einer neuen Form erleben zu dürfen - Form kann man sogar wörtlich nehmen ;).

Hi All,
tach Jens,

auch ich würde gerne wissen, wie der Einsatz von JavaScript von Euch bewertet wird. Gerade im Hinblick auf:
- Sicherheit
- Browser-Unabhängigkeit
- Standard-Konformität

Es heißt immer, man soll den Standards folgen. In Ordnung, aber was genau heißt das - bzgl. JavaScript? Gibt es einen speziellen JavaScript-Dialekt, den man einsetzen kann und der quasi überall funktioniert? Z.B. ECMAScript?

Oder kann man hier auch nur wieder raten, welcher Browser welchen Sprachumfang unterstützt? Eine nicht unerhebliche Frage in Zeiten von AJAX und Web 2.0.

Und schließlich die Frage, ob alle JavaScript-Implementierungen gleich sicher bzw. unsicher sind.

Wer weiß Rat?

bye:maak.

Grundsätzlich gilt beim Einsatz von Scriptsprachen wie Javascript, äquivalente Alternativen bereitzustellen.

Dies erfolgt bei Javascript z.B. durch den <noscript> Tag. Dieser kann genauso wie gewohnt gestaltet werden, wird aber nur bei Browsern mit ausgeschaltetem Javascript präsentiert.

Der Besucher einer Homepage muss also diese ohne Einsatz von Zusätzen wie Javascript, Java, ActiveX etc. benutzen können. Hierbei darf der Zugang zu Informationen und Inhalten einer Website nicht durch das fehlende Scripting eingeschränkt werden.

Vor allem sollte man immer im Hinterkopf behalten, dass nicht jeder Internetnutzer mit einem Webbrowser wie dem Firefox oder dem IE unterwegs ist. Oft kommen auch Screenreader, textbasierte Browser wie Lynx oder auch mobile Browser zum Einsatz.

Zuletzt bearbeitet am 08.02.2009 18:05

Nun im Hinblick auf die Barrierefreiheit wird es wohl kaum einen Unterschied zwischen strict und taditional geben. Hier ist eher darauf zu achten, dass der Benutzer, besonders solche mit Einschränkungen (Seheinschränkung etc.) die Seite ebenso kompfortabel nutzen können wie "normale" Nutzer. Schlimm wird es dann, wenn ich auf Seiten lesen muss: "Optimiert für XYZ in der Auflösung 3333x33333 Pixel". Mit ein wenig Mühe kann man heutzutage echt gute Seiten bauen die in allem Browsern, bei allen auflösungen gut aussehen.

Ich tendiere eher dazu, Technologien zu verwenden, die keine Einschränkungen erzeugen. Von daher lass ich JavaScript, AJAX & Co. eher Aussen vor. Mit HTML und CSS in Verbindung mit dem YAML-Framework ist schon einiges möglich, selbst Dropdownmenüs rein aus HTML und CSS ohne JavaScript. Wer auf Effekte dennoch nicht verzichten will, sollte dann Flash nutzen. Die aktuelle flashverison ist auf nahezu 98% aller internetfähigen Rechner installiert.

Auch mit einem Yaml Framework kann man vieles falsch machen ;) Das Thema der Barrierefreiheit ist sehr umfangreich und sehr tiefgründig. Klar, ein valides HTML Dokument ist eine der Voraussetzungen. Es spielt zwar keine Rolle, ob es sich hierbei um XHTML strict oder transitional handelt, der Code muss eben entsprechend ausgezeichnet sein. Wichtiger als die saubere Umsetzung und Programmierung ist immernoch der Inhalt. Ist dieser nicht aussagekräftig und verständlich hilft auch das kontrastreichste, screenreader tauglichste Layout nichts.

Heute Hilfsmittel kommen schon mit vielen Seiten zurecht. Auch mit älteren Seiten.

Genug von Thema abgeschweift ;) zurück zu HTML. Wer die aktuellen Diskusionen im Web etwas mit verfolgt hat, steht wohl bald nicht mehr vor der Frage ob strict oder transitional. Da das W3C die XHTML2 Workgroup nun dicht gemacht hat, geht es irgendwann in Richtung HTML5 und CSS3 (siehe z.B. Google Wave).

Leider ist ein Ende der Entwicklung von HTML5 noch nicht abzusehen. Vor allem im Bereich der Accessibility gibt es noch einige Probleme (z.B. Canvas ...). Die mangelnde Webstandards Unterstützung des IE macht es auch nicht gerade einfacher HTML5 und CSS3 heute produktiv schon einzusetzen (bis auf wenige Ausnahmen).

Wer mehr über das Thema und vor allem auch über Barrierefreiheit erfahren möchte, kann mir ja auf Twitter folgen :) www.twitter.com/marlonboehland.

Zuletzt bearbeitet am 04.08.2009 03:51