[Sammelthread] Layout vs. Struktur. Guter/Richtiger HTML Code

[Kasn]

nachdem die Debatte in FDSonnes Thread ein wenig vom Thema abgekommen ist, dachte ich wir ziehen diese doch nicht unwichtige Diskussion in ein eigenes Thema.

Der erste Punkt des es zu klaeren gibt ist die alte Frage Tabellen gegen Divs. hier gibt es primaer drei Fraktionen: "Tabellen sind ok fuer alles", "Um nichts in der Welt Tabellen" und "Je nachdem was man braucht. Divs fuer Layout, Tabellen fuer Daten".

Hier mal die aktuelle Diskussion bisher:

Das ganze soll in Tabellenform geschehen, in jeder Zelle der Tabelle liegt ein Bild, der User soll dann quasi auf das Bild klicken können und irgendwo hin verlinkt werden. Je nachdem wie die Verlinkung halt eingetragen ist...

Das gestalten der Tabelle geht soweit erstmal problemlos, die Bilder sind komplett eingefügt usw.
Mein Problem ist jetzt der Hyperlink.

Ich hoffe du verwendest DIV Layer und keine Tabelle. Tabellen sollte man vermeiden. Funktioniert zwar aber ist nicht Barierefrei und bringt auch einige andere Probleme mit sich.

Ja da hast du sicherlich recht. DIV Layer sind jetzt aber nicht so kompliziert. Das nötige Wissen kann man sich eigentlich recht schnell aneignen. Solange es nur eine kleine unbedeutende Seite ist, ist es sowieso egal. Sollte es aber eine etwas größere Firma sein, würde ich auch bei den Intranetseiten darauf achten. Man weiß ja nie welcher Chef die Seite ließt und was man damit für einen Eindruck hinterlässt. Eine gute Intranetseite ist doch schon fast einen halbe Beförderung. Ok das gilt nur wenn alle anderen unfähig sind eine solche Seite auf die Beine zu stellen.

Mir gehts aber nicht mal um die Barierefreiheit. DIV Layer bieten einfach mehr Gestaltungsmöglichkeiten als eine Tabelle.

Ich wollte es nur gesagt haben

naja, wenn Daten tabellarisch angeordnet sind, dann ist es voll und ganz korrekt dafuer Tabellen zu nehmen. das mit DIVs zu machen waere semantischer Schwachsinn...

Tabellarisch angeordnet heißt layout und da sollte man ganz klar DIVs verwenden. Eine richtige Tabelle im Sinne von Excel ist natürlich was anderes. Das ist aber sowieso ein Streitthema. DIVs sind denkbar einfach und da verstehe ich persönlich nicht, dass einige dazu nicht in der Lage sind und immernoch an dem Tabellenlayout festhalten. Einfach mal 1 Tag mit DIVs beschäftigen.

Ich will hier jetzt kein Streit losbrechen. Es darf jeder das verwenden was er will. Am Ende kommt es doch nur auf den Inhalt an. Ich will eben nur die Alternativen aufzeigen. Hier muss sich jetzt niemand rechtfertigen warum er trotzdem Tabellen verwendet. Das ist mir ziemlich egal. Wenn ihr unbedingt Tabellen verwenden wollt, dann kann ich euch sowieso nicht vom Gegenteil überzeugen. Ich geben einfach nur zu bedenken, dass DIVs nicht so schwer zu verstehen sind wie es auf den 1. Blick vieleicht den Anschein hat.

Tabellen zu Layoutzwecken sind ganz klar ein no-go, ich denke darueber muss man nicht streiten. Den Aussagen des TO nach handelt es sich aber um eine tabellarische Auflistung von Daten. Und dafuer sind Tabellen gemacht. DIVs geben Content keine semantische Struktur, diese Tabellen aber haben und brauchen (Ordnung in Reihen und Spalten zb).
Bau mal eine beliebige Datentabelle aus DIVs und schalt dann CSS ab. Das Ergebnis ist sicherlich nicht was man unter Barrierefrei versteht, denn es ist vollkommen unbrauchbar weil unlesbar. Barrierefrei im Wortsinne ist es den Content so zu strukturieren dass er fuer sich selbst sprechen kann, ohne dass Darstellungsregeln angewendet werden damit man ihn einfach auf verschiedenen Endgeraeten darstellen kann.

Noch viel schwerer zu verstehen als DIVs (was sie eigentlich garnicht sind) ist es aber wann man sie nicht einsetzen sollte. mit DIV-Wuesten ist auch keinem geholfen. Ausser ein paar groben Strukturdivs kann man IMHO recht gut drauf verzichten. Es gibt fuer jeden semantischen Zweck die richtigen Tags.
Eine Aufzaehlung wuerde ja auch niemand als Divs machen, sondern Listen verwenden.

Freu mich sehr auf rege Teilnahme!

 

[DEYS]

Barrierefrei im Wortsinne ist es den Content so zu strukturieren dass er fuer sich selbst sprechen kann, ohne dass Darstellungsregeln angewendet werden damit man ihn einfach auf verschiedenen Endgeraeten darstellen kann.

Damit haste eher semantisch korrekten statt barrierefreien Code erklärt. Der Begriff "barrierefrei" zielt v.a. Dingen darauf ab, dass der Code maschinenlesbar ist, dass Programme oder Skripte diesen Code interpretieren können, die keine Webbrowser sind. So sind sie in der Lage, diesen Code zu übersetzen und weiter zu verarbeiten. Damit sie "wissen", was sie da im Einzelnen vor sich haben, muss der Code klar und eindeutig ausgezeichnet sein. Ich glaub, dieses "barrierefrei" hat sich daraus entwickelt, dass man damit auch versuchen wollte, die Hürden für Sehbehinderte und alte Menschen (bzw. ihrer Hilfsprogramme) zu verringern.
Aber letztlich is das nur ein Nebeneffekt, denn die Grundlage dafür is die gleiche. Ein Bsp dafür, den Code maschinenlesbarer zu machen, sind Mikroformate. Damit exportiert man zB ordentlich ausgezeichnete Adressdaten in sein Mailprogramm - auf Grundlage von schlankem, semantisch korrektem Markup.

Markup soll so benutzt werden, dass damit es den Zweck erfüllt, für den es gedacht is. Eine Tabelle enthält eine Auflistung von Daten. Aber nicht wie eine Liste sondern nach verschiedenen Gesichtspunkten auf X- und Y-Achse. Da, wo sich die Achsen treffen, befindet sich ein Datum.
Wenn jemand also eine Tabelle dafür nutzt, um eine Gallerie zu gestalten, dann benutzt er diese Tabelle semantisch nicht korrekt. Denn die Tabelle enthält keine Daten, die anhand von Achsenschnittpunkten identifiziert werden, sondern eine bloße Ansammlung von Bildern.
Korrekt wäre es dagegen, eine ungeordnete Liste zu verwenden und ihre Listenelemente links umfließen zu lassen. So "weiß" das auslesende Programm, dass hier eine nicht geordnete Auflistung unbestimmter Inhalte kommt. Dennoch ist diese Auflistung als eigens deklarierter Block durch die UL-Tags eingeklammert. Eine Aneinanderreihung von A-IMG-(also pro IMG ein A) oder (noch "schlimmer") DIV-A-IMG(pro IMG ein A und DIV)-Konstruktionen würde zwar auch gehen, aber ohne weiteres umschließendes Element, wären das für ein Programm unzusammenhängende Blöcke mit Links drinnen, die Bilder umschließen.
Nicht nur Tabellen können den Code unnötig aufblähen, sondern auch falsch eingesetztes Markup.

 

[little_skunk]

Besser hätte ich es auch nicht ausdrücken können.

Wenn ich mich nicht ganz stark irre, ist eine Tabelle in jedem Fall nicht Barrierefrei. Das Problem ist, dass das Programm beim vorlesen als erstes die 1. Zeile (Spaltenüberschriften) und dann alle weiteren Zeilen nacheinander durchgeht. Irgendwann hat man dann schlichtweg die Spaltenüberschriften vergessen. Solange man also auf Tabellen verzichten kann, sollte man es auch machen. In einigen Fällen ist das sicherlich schwierig aber nicht unmöglich.

Barrierefreiheit bedeutet nicht, dass man auf CSS verzichten muss. Jeder Browser kann CSS. Die Programme zum Vorlesen können ebenfalls mit CSS arbeiten.

Tabellen werden von den Browsern unterschiedlich verarbeitet. Auf den 1. Blick sehen sie gleich aus aber es gibt Unterschiede. Solange man wie oben beschrieben wirklich nur Excel Daten anzeigt, merkt man die Unterschiede nicht. Ich habe mal versucht Links auf die Zeilen einer Tabelle zu legen. Sobald die Maus über eine Zeile kommt, sollte sich die Farbe der Zeile verändern. Das ganze hat im IE noch funktioniert aber FF oder Opera hatten damit Probleme. Bei einem von beiden stimmte was mit den Farben nicht. Es wurde nicht die komplette Zeile farbig. Wie genau es dargestellt wurde weiß ich jetzt nicht mehr.Außerdem wurde nicht die Zeile als Link angesehen sonder nur der Text in den Zelle der Zeile. Das gleiche Spiel mit DIVs hat dagegen weniger Probleme verursacht.

 

[Kasn]

Markup soll so benutzt werden, dass damit es den Zweck erfüllt, für den es gedacht is.

das ist die relevante richtige Aussage.

Und je korrekter ein Code semantisch ist, um so leichter ist er machinenlesbar und damit ist es leichter ihr mit anderen Endgeraeten zu parsen.

Little_Skunk: dein Beispiel ist ein reines Implementierungproblem, das klingt eher so als haettest du einfach was falsch gemacht. Das was du beschreibst hab ich schon oft richtig umgesetzt gesehen (Beispiel konkret: Magento Backend)

 

[little_skunk]

Richtig ich habe es falsch umgesetzt. Der 2. Versucht mit DIVs war dagegen der richtige Weg. Alle anderen Notlösungen mit einer Tabelle wären nur noch schlimmer geworden. Die nötige Funktionalität bietet eine Tabelle einfach nicht. DIVs sind da flexibler.

Der Code kann noch so semantisch sein. Barrierefrei ist es nur wenn die entsprechenden Programme die Seite vorlesen können und ein Blinder die Seite vorstellen kann. Ein semantisch korrekt eingebundendes Bild ohne entsprechenden alternativ Text ist nicht Barrierefrei. Eine Tabelle ist meines wissens auch nicht Barrierefrei.

Im vorliegenden Beispiel handelt es sich definitiv nicht um eine Tabelle sondern nur um die Anordnung von Bildern und das macht man ganz klar ohne Tabellen.

Edit: Ich muss mich korrigieren. Tabellen können Barierefrei sein. Wie das geht kann man hier nach:
http://www.pro-barrierefreiheit.de/entwickler/tabellen/

Da das aber selter der Fall ist sind Tabellen selten Barrierefrei. Mit etwas Aufwand kann man sie aber Barrierefrei gestalten. Die Bilder kann man mit einer Tabelle aber nicht Barrierefrei darstellen. Macht auch keinen Sinn. DEYS hat schon gut erklärt wann man eine Tabelle verwenden kann und wann eben nicht.

 

[Kasn]

semantisch korrekt ist ein Bild nur wenn es ein "alt" attribut hat.

 

[little_skunk]

semantisch korrekt ist ein Bild nur wenn es ein "alt" attribut hat.

Barrierefrei ist es dann nicht zwangsläufig.

 

[Kasn]

Barrierefrei ist es dann nicht zwangsläufig.

was muss ein Bild denn noch erfuellen?

edit:

DEYS hat schon gut erklärt wann man eine Tabelle verwenden kann und wann eben nicht.

hab ich je was anderes behauptet? Zur Darstellung von tabellarisch geordneten Daten.

 

[little_skunk]

Der Text muss einen Blinden in die Lage versetzen sich das Bild vorzustellen. Das vorhandensein eines alternativ Textes "Hier sehen sie mein Büro" reicht dafür nicht aus. Es müsste schon ein ganzer Absatz sein. Hier sehen sie ein 4 Mann Büro mit Pflanzen usw.

Das war übrings nur ein Beispiel. Wie sieht denn deiner Meinung nach eine semantisch korrekte Tabelle aus?

 

[DEYS]

Der Text muss einen Blinden in die Lage versetzen sich das Bild vorzustellen. Das vorhandensein eines alternativ Textes "Hier sehen sie mein Büro" reicht dafür nicht aus. Es müsste schon ein ganzer Absatz sein. Hier sehen sie ein 4 Mann Büro mit Pflanzen usw.

Dieses Problem wird übrigens mit der Spezifikation von XHTML 2.0 gelöst. Somit kann man Bilder in DIVs einbauen. Der Alternativ-Text is dann nix anderes als der Inhalt des DIVs.

Das war übrings nur ein Beispiel. Wie sieht denn deiner Meinung nach eine semantisch korrekte Tabelle aus?

Ich denke, hängt´s vom persönlichen Stil ab. Rein nach W3C-Spezifikation sind Caption, Summar, THEAD, TFOOT, TBODY, COLGROUP und COL freiwillig aber sie bringen "mehr Semantik" in die Tabelle, geben den Renderern mehr Informationen zum Verarbeiten. Und wie man sieht, erleichtert man ihnen dadurch sogar die Verarbeitung.

 

[pajaa]

Und was macht ein Screenreader oder ein Browser ohne CSS aus mit Hilfe von DIVs gebauten Pseudotabellen? Richtig: Datenkuddelmuddel.

Habe ich allerdings für meine Datenmatrix eine ordentlich ausgezeichnete Tabelle, weiß jeder Browser und jeder Screenreader, was Sache ist.

Tabellen zu Layoutzwecken zu missbrauchen, ist aber ein No-Go.

 

[hotracer]

Grundsätzlich zur Barrierefreiheit:
Wer ausschließlich darauf pocht, barrierefreier Code ist ein Muss in modernen Webanwendungen, der führt für seine Projekte keine [ordentliche] Bedarfs- und Zielgruppenanalyse durch.

Auch das Argument, dass auf vielen Div-Fanatiker-Seiten vorherrscht, eine ordentliche Seite müsse mit dem bloßen Austausch der CSS-Datei(ein) ihr komplettes Gesicht ändern können, ist völlig realitätsfremd.

Ich persönlich setze mit und nach bestem Gewissen die dem Inhalt entsprechenden Auszeichnungen. Aber auf HTML-Elemente zur Layout-Gestaltung zu verzichten ist bei komplexen Interfaces nunmal nicht möglich. It depends, wie man im Englischen so schön sagt...

Zum allgemeinen Container-Hype kann ich nur sagen: früher missbrauchte man Tabellen zur Layout-Umsetzungen, heute sind es eben div-Container - geht man davon aus, völlig korrekten und semantischen Quelltext produzieren zu wollen, so sind beide Wege schlicht weg falsch.

 

[little_skunk]

Was heißt hier auf Barrierefreihiet rumpochen? Warscheinlich bin ich vorgeschädigt aber bei meinem Arbeitgeber spielt Barrierefreiheit sehr wohl eine Rolle und das sowohl intern als auch extern. Wenn das hier nicht so gehandhabt werden würde, dann würden hier zusätzliche Kosten entstehen für die Beratung von entsprechend benachteiligten Personen. Außerdem müssten wir einige teilweise gute Angestellte entlassen. Hier kommt man definitiv nicht um Barrierefreheit rum.

Zum Thema CSS. Ich habe schon einige gute Seiten gesehen mit komplexen Interfaces. Ohne Divs hätten die das nicht so schön hinbekommen. Auf Knopfdruck konnte man das Layout komplett verändern. Da wurde nicht nur die Hintergrundfarbe verändert sonder die Menüstruktur war auf einmal eine ganz andere und war auch an anderer Stelle angeordnet. Mit Tabellen wäre das jedenfalls nicht möglich gewesen. Ich würde das aber nicht so wie die Div Fanatiker ausdrücken. Es bleibt jedem selbst überlassen ob er nun DIVs verwendet oder nicht. Komplexe Oberflächen lassen sich aber ohne Probleme damit realisieren und somit spricht nichts gegen die Verwendung von DIVs.

@pajaa
Es gibt Browser ohne CSS? Was macht denn ein Browser ohne Tabellen Tag? Beides wäre doch nicht W3C und somit ist der Browser einfach mal kein richtiger Browser.

Der Screenreader würde die Daten genauso falsch vorlesen wie in einer normalen Tabelle (ohne die für die Barrierefreiheit nötigen Tags). So oder ist das dann dumm gelaufen.

Es geht auch nicht darum die Tabellen komplett abzuschaffen. DEYS hats oben schon so schön beschrieben und ich denke zumindest in dem Punkt sind wir uns hier alle einig. Sobald die Tabelle keine Spalten und Zeilenüberschriften hat, ist es im eigentlichen Sinne keine Tabelle sondern dient nur der Anordnung von Objekten.

 

[hotracer]

Ich meinte mit meinem Post keine spezielle Person in diesem Thread - war ganz allgemein auf eher externe Resourcen bezogen.

Das ein Container-Layout letztlich moderner als ein Tabellen-Layout ist, steht außer Frage. Ich bin auch kein Befürworter von Tabellen - zumindest, wenn es nicht um das Auszeichnen von tabellarischen Daten geht.

Ich meine nur grundsätzlich: ein Layout benötigt nunmal für den Inhalt irrelevantes Markup. Wenn ganz pragmatisch die aktuellen Standards und das neue alte Konzept "Back to the roots" durchgesetzt werden sollen, dürfte aber nur Markup verwendet werden, welches den Inhalt vollständig beschreibt - nicht mehr, aber auch nicht weniger.

Unnützes Markup ist für ansprechende Interfaces aber unumgänglich - besser man benutzt Container. Sie ersetzen aber hier eben nur die Tabellen, die dafür aus vielerlei Hinsicht weniger geeignet sind.
Das meinte ich mit meinem Post.

Zum Thema Browser ohne CSS: Stichwort Textbrowser/Konsolen-Browser. Das W3C schreibt nicht vor, dass eine HTML-Seite zwangsläufig CSS-Anweisungen zum formatieren beeinhalten muss. Es definiert nur Standards, wie [optionaler] CSS-Quelltext aussehen sollte.

Edit: Zur Barrierefreiheit: ich sagte bereits - it depends.
Eine Fotografen-Seite benötigt keinen für Screenreader optimierten Quelltext. Eine Präsenz eines Augenzentrums hingegen sollte natürlich auch für Screenreader einfach zu interpretieren sein.

 

[DEYS]

Und was macht ein Screenreader oder ein Browser ohne CSS aus mit Hilfe von DIVs gebauten Pseudotabellen? Richtig: Datenkuddelmuddel.

Habe ich allerdings für meine Datenmatrix eine ordentlich ausgezeichnete Tabelle, weiß jeder Browser und jeder Screenreader, was Sache ist.

Eben nicht. Wenn du die Darstellung, die dann rauskommt siehst, denkst du, dass er weiß, was Sache is. Das stimmt aber nich. Denn durch die Auszeichnung als Tabelle hält der Browser die dort enthaltenen Daten für was anderes, als sie letztlich sind. Deshalb ja das Bsp einer Unsortierten Liste.
Dein Argument im ersten Absatz, würde eigtl zurück zu den Layouttabellen führen. Denn wenn man CSS im Browser abschaltet, sieht man immer subjektiv "Datenkuddelmuddel".

Grundsätzlich zur Barrierefreiheit:
Wer ausschließlich darauf pocht, barrierefreier Code ist ein Muss in modernen Webanwendungen, der führt für seine Projekte keine [ordentliche] Bedarfs- und Zielgruppenanalyse durch.

[...]

Ich persönlich setze mit und nach bestem Gewissen die dem Inhalt entsprechenden Auszeichnungen. Aber auf HTML-Elemente zur Layout-Gestaltung zu verzichten ist bei komplexen Interfaces nunmal nicht möglich. It depends, wie man im Englischen so schön sagt...

Den Punkten stimme ich zu.
Beispielsweise bei ´nem Projekt, an dem ich arbeite, schließen wir alle Nich-JavaScript-User aus. Normalerweise ein No-Go, aber wir wissen von unserer Zielgruppe, dass sie mit aktiviertem JS unterwegs is und unser Interface wird recht komplex, weshalb eine Non-JS-Alternative zu aufwändig zu bauen wäre. Es kommt auf die Zielgruppe an, das is die Grundlage aller weiteren Code-Enscheidungen.