Tabellen nicht per se verteufeln

Ganz meiner Meinung bloss schwierig zu erkennen, was ist eine Datendarstellung und was gehört zum Template.

Ich selbst scheue mich keineswegs Tabellen für einen Datagrid einzusetzen.

Ich sage mir - alles was valide ist darf man einsetzen und gut ist.

Hallo,

dem kann ich mich nur anschließen. Bei einer sinnvollen Verwendung von Tabellen sollte auch die Ladezeit nicht besonders leiden.

Gruß

SGS

Ja, diese Diskussion wurde z.B. von gérard bereits einmal intensiv angestoßen. Insbesondere für Screen-Reader/Vorleseprogramme scheint es aufgrund der Semantik Sinn zu machen Datentabellen zu verwenden, da diese DIV-Container (noch) nicht richtig interpretieren können.

Die Frage wäre hier allerdings, wie der Seitenreport automatisiert unterscheiden soll, ob es sich um Design-Tabellen oder Daten-Tabellen handelt. Hier bin ich derzeit noch am grübeln.

Naja, Tabellen kann man aber auch mit CSS Technik (modernere) erstellen.
Und um das geht es hier denke mal - auf dem neuerem Stand Punkt zu sein. Es ist nirgendwo gesagt das die "Grosse Site" machen immer am bestens.

Aber dieses Thema war auch schon hier beim Seitenreport behandelt.

Schau mal hier: www.seitenreport.de/forum/beitraege/ideen_verbesserungsvorschlaege/bewertung_von_tabellen.html

Also da ich nun gerade auch die Frameworksite von mir auf BF gesetzt habe kann ich behaupten, das Tabellen problemlos als barrierefrei akzeptiert werden, wenn summary und th wie von einem Vorposter erwähnt vorhanden sind.

Also was solls.

Da ich meine Templates in der Basis alle auf DIV mache und das vorzugsweise mit Grid-systemem und Tabellen nur für bestimmte Dinge einsetzte und mich auch nicht dazu bringen lasse mich von Tabellen zu verabschieden nur weil man bei der Analyse meint holla - Tabelle - und jetzt ansagen muss das man ein Problem mit der Erkennung hat - lasse ich mich nicht beirren.

Wenn Tabellen Scheisse sind wird die w3.org das raus nehmen, hat sie aber nicht , auch nicht bei XHTML 1.1 und da kann man mittels Ruby noch mehr Schweinkram damit machen.

Also die Frage die dann kommen muss - wieso die Diskussion ???

Nur weil ein paar Leute festgestellt haben, das man das auch mit DIV\'s machen kann ?

Na klar ich kann auch mit links schreiben und spiegelverkehrt lesen , na und ?.

Gute Tabellenlaouts sind sehr viel schwieriger zu machen, als welche mit DIV, vielleicht ist das der Grund warum die "Welt" nach DIV Layouts schreit ??

Also mal ganz wertneutral, bei 10.000 fachem Aufruf einer Seite die mit Tabelle gemacht habe und bei einer identischer Seite mit DIV gemacht habe ich keinerlei Unterschied messen können.

Power kann es es heute also nicht mehr sein - was sonst ?

Die gängigste These ist:

Tabellen erzeugen einen größeren Overhead als DIV-Container.

Zur Leichtigkeit: da sind allerdings Tabellen leichter zu programmieren als DIV-Container. Da die float-Eigenschaft mit der gearbeitet werden muss, nicht unbedingt für jeden einfach zu verstehen ist. Und wenn man ihre Wirkungen nicht ganz genau kennt, manchmal recht komische Dinge tut. :P

Grundsätzlich könnte man eine Daten-Tabelle von einer Layout-Tabelle so unterscheiden, dass man auf den Inhalt schaut. Sprich wenn eine durchschnittliche Tabellen-Zelle mehr als 500 Zeichen (oder so) beinhaltet, wird es sich um eine Tabelle handeln, die fürs Layout gebraucht/missbraucht wird.

Vorschlag zur Unterscheidung von Daten-Tabellen und Layout-Tabellen:

Eine Tabelle wird als Daten-Tabelle angesehen, wenn entweder im table-Tag das

summary-Attribut

gesetzt ist oder das

caption-Element

vorhanden ist. Layout-Tabellen verwenden üblicherweise weder das eine noch das andere (zumindest hab ich noch keine Layouttabelle mit diesen Angaben gesehen. Aus Gründen der Barrierefreiheit sollte aber eine Tabelle ohnehin diese beiden Angaben enthalten.

Die Elemente thead, tfoot und tbody wird man zwar in Layout-Tabellen auch nicht finden, sie sind allerdings im Einzelfall auch in Daten-Tabellen nicht notwendig. Sie eignen sich also nicht für eine Prüfung.

Gérard

Gerard schrieb:

Aus Gründen der Barrierefreiheit sollte aber eine Tabelle ohnehin diese beiden Angaben enthalten.

Sollte aber in der Praxis denkt kaum jemand an BF, deswegen wird diese Erkennung in der Praxis glatt scheitern.

Summary ist ja optional und kaum jemand wird wegen eines Test\'s hier den extra setzen, wenn er Daten darstellt.

Und es gibt Leute die setzen Summary generell auch bei Layouts.

piratos schrieb:

Sollte aber in der Praxis denkt kaum jemand an BF, deswegen wird diese Erkennung in der Praxis glatt scheitern.

Summary ist ja optional und kaum jemand wird wegen eines Test\'s hier den extra setzen, wenn er Daten darstellt.

Und es gibt Leute die setzen Summary generell auch bei Layouts.

Käme ja mal auf den Versuch an. Und wer keine Layout-Tabellen nutzt, wird seinen Quelltext vielleicht ja ändern, wenn er denn Hinweis erhält - und schon wäre im Sinne BF was gewonnen.

Gérard