HTML Warum Tabellen zum Layouten besser sind...

PW-toXic

Lieutenant
Registriert
Jan. 2005
Beiträge
966
Seit einigen Jahren kann man in fast allen Threads von Webdesign Neulingen immer wieder was Unwort "Table Layout" finden. Es wird den Leuten strengstens verboten unsichtbare Tabellen für das Layout zu verwenden, da diese nicht dafür konzipiert worden sind.

Die Organisation, die den Standard für die Web Sprachen wie (X)HTML und CSS definiert sieht das ähnlich:
w3.org
Tables should not be used purely as a means to layout document content as this may present problems when rendering to non-visual media. Additionally, when used with graphics, these tables may force users to scroll horizontally to view a table designed on a system with a larger display. To minimize these problems, authors should use style sheets to control layout rather than tables.
Man beachte jedoch, dass hier das Wort "should" steht.

Immerhin zieht w3.org in betracht, dass man Tables möglicherweise für das Layout benutzen muss:
w3.org
However, when it is necessary to use a table for layout, the table must linearize in a readable order.


1 Was ist "Table Layout"?
Sobald man ein Design für eine Webseite erstellt hat, muss man dieses in HTML umsetzen. Da die meisten Designer sehr in rechteckigen Bereichen denken, die nebeneinander liegen, und stark ineinander verschachtelt sind, haben sie in der Vergangenheit meistens auf in sich verschachtelte unsichtbare Tabellen zurückgegriffen, da man mit diesen das erstellte Design am einfachsten umsetzen kann. Ein sehr gutes Beispiel für diese Bauweise sieht man hier:
http://www1.opel.de/aktuell/news

2 Was ist die alternative Lösung?
Seitdem die Cascading Style Sheets (CSS) das Internet erobert haben, steigen nun mehr und mehr Webdesigner auf eine HTML bauweise mit möglichst wenig Elementen um, und schreiben die nötigen Layout Informationen in eine externe CSS Datei. Dies hat unter anderem zwei westenliche Vorteile:
1) Der Code für die Webseite wird deutlich kürzer
2) Der Code ist deutlich besser lesbar und somit wird die Wartbarkeit erhöht.

Mittlerweile hat sich eine große Hassgemeinschaft im Internet gebildet, die strikt die Benutzung von Tabellen für Layout Zwecke verbieten möchte. Es gibt zu Hauf Webseiten, die propagieren, wie man Webseiten aus technischer Sicht zu Gestalten hat, und erklärt den Leuten auf eine deutliche und einfache Weise, wie man sein gewünschtes Layout mit Hilfe der CSS Technik umsetzen kann. Da noch viele Leute entweder aus alter Gewohntheit oder des eigenes Verständis halber auf Tabellen fixiert sind, wird dort auch explizit erlkärt, wie man auf ein Layout rein auf CSS basierend umsetzen kann.
Ich nenne dies eine Hassgemeinschaft, weil diese Leute jede Webseite hassen, die auch nur eine einzige Tabelle für Layout Zwecke benutzt, und dem jeweiligen Webdesigner dazu zwingen möchte, gefälligst CSS zu lernen. Dafür geben diese Leute immer wieder die gleichen Gründe. Hier eine Auswahl:

1) Bei Tabellen für Layout Zwecke wir die Semantik verletzt
2) Tabellen benötigen deutlich mehr Code, und verursachen somit mehr Traffic
3) Die Wartbarkeit des Codes ist deutlich schlechter
4) Die Entwicklungszeit von Layouts mit Tabellen ist erheblich höher
5) Suchmaschinen unfreundlich
6) Längere Ladezeiten für den Benutzer
7) Vermischung von Inhalt und Präsentation
8) Barrierefreiheit: Tabellen können nicht richtig mit alternativen Anzeigegeräten angezeigt werden
9) Tabellen sind nicht zum Layouten da, sondern nur für Daten. (Im allgemein weltlich-menschlichen Sinne)

http://phrogz.net/CSS/WhyTablesAreBadForLayout.html
http://webdesign.about.com/od/layout/a/aa111102a.htm
http://www.workingwith.me.uk/table_free/seven_reasons_to_go_table_free

Das stimmt im Groben und Ganzen. Daher sehen die meisten Webdesigner den Vorteil, und haben bereits ihre Layout Gewohnheiten umgestellt, und setzen ihre präsentations spezifischen Eigenschaften mit CSS um. Jedoch sind mittlerweile sehr viele so stark von der Einfachheit von CSS begeistert, dass sie jeglichen Gebrauch von Tabellen für Layout Zwecke misbilligen, und mit der Holzhammer Methode alles mit dem HTML Element div und den CSS Eigenschaften umsetzen.

Daher rufe ich auf:


3 Die Tabelle hat weiterhin ihr Existenzrecht bei Layouts

Aber bevor ich hier genau erkläre warum und wieso, möchte ich vorher ganz klar festhalten:
Ein reines Table Layout wie z.B. die Opel Seite ist Müll, da die sinnvolle Nutzung der HTML Elemente wie Paragraphen, Listen, Headings usw. in Verbindung mit stylesheets in jeder Hinsicht die bessere Lösung sind, solange das was man umsetzen möchte mit dieser Technik auf direktem Wege möglich ist!
Nicht nur die Wartbarkeit des Codes wird dadurch erheblich verbessert, sondern man ist auch deutlich schneller mit der Erstellung des HTML/CSS Quellcodes fertig!


3.1 Warum verteidige ich die Tabelle?
Es gibt sicher mehrere Gründe, die an bestimmten Stellen für die Tabelle sprechen, aber ich beschränke mich auf ein einziges Beispiel, da dieses Beispiel vollkommen ausreicht um die Existenzberechtigung von Tabellen aufrecht zu erhalten. Das Grundproblem ist einfach: Die Mittel von CSS sind stark begrenzt. Sie reichen zwar für die meisten Sachen aus, jedoch nicht immer. Mit CSS hat man wenig Möglichkeiten sich auf andere Elemente zu beziehen, wenn man das Stylesheet für ein Element definiert. So kommt es, dass die Eigenschaften der Tabelle mit CSS nicht vollständig umsetzbar sind. Wenn man diese Eigenschaften aber dringend benötigt (Der Designer gibt das Layout vor!), dann sollte man nicht, wie es derzeit oft der gemacht wird, durch Tricks mit CSS/Javascript/Hacks diese Eigenschaften zu simulieren.
Eine direkte Umsetzung mit reinem CSS für die Anforderung, dass sich zwei oder mehr Elemente direkt von der Eigenschaft Höhe beinflussen, ist nicht möglich!
Hierfür ist in CSS nichts vorgesehen. Bei Tabellen ist dies aber allein aufgrund der Idee und Struktur jedoch bereits gegeben. Befindet man sich in einem solchen Fall, ist allermeistens die Tabelle die bessere Lösung!

Drei Spalten Layout mit einer Tabelle
HTML:
<table id="colmask">
	<tr>
		<td id="colLeft">Spalte 1</td>
		<td id="colMid">Spalte 2</td>
		<td id="colRight">Spalte 3</td>
	</tr>
</table>
HTML:
#colmask {
	width: 100%;
	border-collapse: collapse;
}

#colLeft {
	width: 20%;
	background: red;
	vertical-align: top;
}

#colmid {
	width: 60%;
	background: green;
	vertical-align: top;
}

#colRight {
	width: 20%
	background: blue;
	vertical-align: top;
}
http://pw-toxic.de/blog/80

Bis auf die <tr> Tags ist der Aufbau extrem einfach, und spiegelt genau das wieder was man machen möchte. Wichtig ist hierbei die Eigenschaft, dass alle drei Spalten gleich hoch sind! Ich habe der einfacheit halber eine Hintergrundfarbe gewählt, aber es ist auch denkbar, dass man mit borders oder auch Grafiken arbeitet.

Wenn man das ganze nun ohne Tabellen umsetzen möchte, wird es kompliziert, aber es geht! Da es sehr viele CSS Dogmatiker gibt, haben sich einige Leute viele Gedanken gemacht, wie man diese spezielle Anforderung nur mit CSS mitteln umsetzen kann. Ich muss zugeben, dass die Lösungen teilweise richtig genial und kreativ sind, aber darum geht es hier ja nicht.
Die beste Lösung die ich finden konnte, kommt von dieser Seite:
http://matthewjamestaylor.com/blog/perfect-3-column.htm

Ich habe den Code auf das nötigste heruntergebrochen:
Drei Spalten Layout mit DIVs
HTML:
<div id="colmask">
	<div id="colmid">
		<div id="colleft">
			<div id="col1">Spalte 2</div>
			<div id="col2">Spalte 1 <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br />  langer text</div>
			<div id="col3">Spalte 3</div>
		</div>
	</div>
</div>
HTML:
#colmask, #colleft, #colmid {
	float: left;
	position: relative;
}

#colmask {
	background: #9a9a9a;
	overflow:  hidden;
	width: 100%;
	clear: both;
}

#colleft {
	background: #dbdbdb;
	right: 60%;
	width: 100%;
}
	
#colmid {
	background: #abd6f4;
	right: 20%;
	width: 100%;
}

#col1, #col2, #col3 {
	float: left;
	position: relative;
	overflow: hidden;
}

#col1 {
	width: 60%;
	left: 100%;
}
	
#col2 {
	width: 20%;
	left: 20%;
}
	
#col3 {
	width: 20%;
	left: 80%;
}
http://pw-toxic.de/index/threeColLayout

Ich denke jedem leuchtet folgendes ein:
1) Das ist mehr code
2) Der code ist absolut unverständlich. Man muss sich eingehend damit im speziellen beschäftigen, um es zu verstehn
3) Der logische Aufbau widerspricht der Intuition, da die mittlere Spalte zuerst kommt (Anm. Ja ich weiss: SEO..)
4) Man hat hier eine böse div-Suppe, die mit Semantik rein garnichtsmehr am Hut hat.
Es ist pragmatischer Sicht einfach schlecht, wenn man diesen "CSS Hack" anstelle von einer einfachen Tabelle benutzt, wenn man einfach stur ein Layout umsetzen möchte.
(Ich bezeichne das im Gegensatz zum Author als CSS Hack, da hier CSS Eigenschaften benutzt werden, die für etwas anderes gedacht sind, nur um das gewünschte Verhalten herbeizuführen (right: xx%))


Ich gehe nur ausgehend von diesem Beispiel detailliert auf die oben genannten Gründe für reine CSS basierende Layouts ein: (teilweise umformuliert)

3.2 Warum die Argumente gegen Tabellen nichtmehr wirken

3.2.1 Bei Tabellen für Layout Zwecke wir die Semantik verletzt
Hier muss ich leider etwas weiter ausholen, da die Semantik ein sehr tiefgreifender und schwieriger Begriff ist. Ich gebe selbst zu, dass ich das ganze nicht vollständig durchblicke, jedoch wage ich zu Behaupten, dass ich von diesem Thema mehr Ahnung habe, als die allermeisten CSS Dogmatiker.

Arten der Semantik
Ich unterscheide im Bereich von HTML drei Arten von Semantik (geordnet nach Wichtigkeit)
1) Bedeutung des Inhalts
2) Strukturierung / Aufbau des Dokuments
3) Layout Semantik

Bedeutung des Inhalts:
Ich denke wir sind uns alle einig, dass dies mit HTML nicht möglich ist. Der vollständigkeit halber muss ich jedoch erwähnen, dass unter anderem folgende Tags genau dieser Semantik entsprechen:
<address></address>
w3schools.com
Defines contact information for the author/owner of a document
<title></title>
w3schools.com
Defines the document title
Das ist jedoch sehr rudimentär!
Jedoch ist genau dies die Semantik, die im Web interessant ist, denn somit könnte man voralem über Suchmaschinen richtige Informations Netzwerke aufbauen! Dies entspricht dem Begriff des Semantik Web
wikipedia.org/Semantisches_Web
Ziel des Semantischen Webs ist es, die Bedeutung von Informationen für Computer verwertbar zu machen. Informationen sollen dadurch nicht nur von Menschen verstanden werden können, sondern auch von Maschinen interpretiert und weiterverarbeitet werden können. Informationen sollen maschinell ausgelesen werden können, beispielsweise der Sachverhalt: dies ist ein Vorname, ein Nachname, ein Autor, ein Buchtitel, der Name einer Stadt oder eines Unternehmens.
Es gibt auch bereits einen guten Standard der genau dafür da ist: Resource Description Framework
Wenn man also Semantik haben möchte, dann doch bitte auf diese Weise!

Strukturierung / Aufbau des Dokuments
Dies ist die Semantik, mit der die CSS Dogmatiker immer argumentieren - Bewusst oder unbewusst, das konnte ich noch nicht herausfinden. Es geht darum, dass der Inhalt der Webseite strukturiert wird. Hierfür sind exemplarisch folgende Elemente sehr wichtig:
- p (Paragraph)
- hx; x € {1; ...; 6} (Heading)
- list (Liste)
Diese Elemente sollten so oft wie möglich an den Stellen wo sie Sinn machen verwendet werden, da man dadurch klar erkennen kann, wofür bestimmte Teile des Inhalts da sind. Die Verwendung hat nur Vorteile!
Wenn man diese Thematik jedoch auf das Beispiel oben bezieht, dann wird es eng! Wenn man das ganze sinnvoll aufbauen würde, dann müsste man es wie folgt machen:
HTML:
<div id="menu"></div>
<div id="content"></div>
<div id="shortInfo"></div>
Die Namen der divs sollte man natürlich so verwenden, wie sie dem Aufbau der Webseite entsprechen würde. Hier kommt eine gewisse intuitiv verständliche Semantik rein, die jedoch nirgendwo exakt definiert ist -> gefährlich!

Noch besser wäre:
HTML:
<menu></menu>
<content></content>
<sidebar></sidebar>
Das ist jedoch eine fiktive Syntax, die so nicht existiert. wünschenwert wäre es so jedoch.
Klar wird jedoch, dass die div-Suppe von oben rein garnichtsmehr mit einer strukturellen Semantik zu tun hat, da die div-verschachtelung rein dem Layout dient, und nicht der Struktur des Dokuments, welche (möglicherweise) in drei Bereich aufgeteilt werden kann: Menü, Inhalt, und Sidebar (diese könnte man ggf. noch präziser benennen).

Layout Semantik
Das was ich oben gemacht habe hat mit einer strukturellen Semantik für das Dokument selbst, welches Informationen tragen soll, nichtsmehr zu tun, sondern hat etwas mit dem Aufbau und dem Layout der Webseite etwas zu tun. Ob ich das ganze nun mit divs oder Tabellen umsetze spielt in diesem Sinne keine Rolle, denn eine ordentliche Unterstützung der Layout Semantik gibt ebenfalls in HTML nicht.

Fazit
Das Argument der Semantik zieht hier nicht. Im besten Falle kann man hier der Tabelle mehr Semantik zuweisen, da das Layout schliesslich dem intuitiven Verhalten einer Tabelle entspricht. Wer hier also mit der Semantik argumentiert, hat sie nicht verstanden.


3.2.2 Tabellen benötigen deutlich mehr Code, und verursachen somit mehr Traffic
Darauf bin ich oben bereits eingangen. Offensichtlich ist das in diesem Fall ein Argument für die Tabelle, da mit weniger Code das gewünschte umgesetzt werden kann.


3.2.3 Die Wartbarkeit des Codes ist deutlich schlechter
Auch hierzu bin ich oben bereits eingangen. Ich denke ist ist vollkommen klar, dass auch hier dieses Argument wieder für die Tabelle spricht. Sollte das nicht sofort einleuchten, dann besteht hier sicherlich die Möglichkeit zur Diskussion.. Ich denke aber das ist nicht nötig, da es offensichtlich ist.

3.2.4 Die Entwicklungszeit von Layouts mit Tabellen ist erheblich höher
Der nächste Punkt, wo der Profitierende die Seiten wechselt. Um das obige reine CSS Layout ohne Tabellen umzusetzen, benötigt man deutlich mehr Zeit, selbst wenn man die Lösung bereits kennt! Dies wird vorallem dann deutlich, wenn man noch zusätzlich wie auf dem Beispiel des Authors dieses Layouts selbst, noch paddings zu den Spalten hinzufügt.
http://matthewjamestaylor.com/blog/perfect-3-column.htm
Den Quellcode kann man sich gerne einmal ansehen. Das wird dann noch eine ganzes Stück komplizierter! Wenn man die Lösung vorher nicht kennt, dann Schätze ich für die Erstellung dieses Layouts einen Zeitaufwand von einigen Stunden, obwohl man bereits umfangreiche Erfahrungen mit CSS hat, die hierfür zwingend erforderlich sind.


3.2.5 Suchmaschinen unfreundlich (SEO)
Dies habe ich nicht so genau untersucht, da ich mich damit nicht allzusehr beschäftigt habe. Jedoch möchte ich kurz festhalten:
1) Das ist nicht mein Problem, sondern das der Suchmaschine.
Und ich bin davon überzeugt, dass google damit sehr gut umgehen kann!
2) Trotz alledem ist die Tabelle aufgrund der Definition des W3C hier schlechter als die reine CSS basierte Lösung
3) Suchmaschinenfreundlichkeit ist eine nicht-funktionale Anforderung, die erstmal bei der Entwicklung einer Webseite definiert werden muss
Man kann zwar davon ausgehen, dass dies bei den meisten Webseiten eine wichtige Rolle spielt, aber man kann in der Allgemeinheit eben nicht davon ausgehn! Letzendlich muss man auch hier das magische Dreieck erwähnen: Kosten - Qualität - Zeit


3.2.6 Längere Ladezeiten für den Benutzer
Table wins.


3.2.7 Vermischung von Inhalt und Präsentation
Table wins. Siehe Semantik oben.
Eine Tabelle ist ein Mittel um ein Layout zu erstellen! Auch wenn die CSS Dogmatiker das nicht einsehen wollen. Fakt ist jedoch, dass eine solche Tabelle in HTML nicht existiert. Die Tabelle die ich oben verwende ist für die Darstellung und Strukturierung von Inhalten gedacht. Dies ist jedoch ein Problem von HTML und nicht von mir. Durch die div-Suppe wird wie oben schon erwähnt ebenfalls die Präsentation mit dem Inhalt vermischt, nur mit dem Unterschied, dass bei der Lösung mit der Tabelle dieser Teil deutlich kleiner ist, also mit der Lösung ohne Tabelle.


3.2.8 Barrierefreiheit: Tabellen können nicht richtig mit alternativen Anzeigegeräten angezeigt werden
Dies ist ebenfalls wieder eine nicht-funktionale Anforderung, die aber im Gegensaz zur Suchmaschinen-freundlichkeit deutlich seltener von Belang ist! Man kann nicht einfach allgemein mit diesem Argument angerannt kommen, wenn dies einfach keine Rolle bei dem System das man baut spielt.
Noch schlimmer wird es, wenn das Argument daraufhin verschärft wird, dass Leute mit Behinderungen Webseiten mit Tabellen schlechter lesen können. Dies ist ein Irrglaube! Davon abgesehn macht es kein Sinn mit dem Holzhammer zu versuchen ein Bildergallerie für Bilde zugänglich zu machen. (Ich wüsste garnicht wie das überhaupt funktionieren soll, aber es gibt sicher Möglichkeiten auch das zu schaffen ;))

Bitte hört mir mit diesem Argument auf - Ich kann es nichtmehr ertragen!
(Anm. Bei meiner Webseite ist mir dieser Punkt jedoch nicht unwichtig! Das gilt aber halt nur im speziellen für meine Webseite(n)..)


3.2.9 Tabellen sind nicht zum Layouten da, sondern nur für Daten. (Im allgemein weltlich-menschlichen Sinne)
Falsch. (siehe oben)
Wer hat das eigentlich definiert? Wenn jemand bei der Gestaltung mit einem tabellarischem Aufbau arbeitet, dann kann man da argumentieren wie man will. Wofür etwas gut ist, definiert derjenige, der es benutzt!.
Wichtig: Ich spreche hier nicht von der HTML Tabelle, sondern von dem allgemeinen Begriff der Tabelle. Es reicht schon, wenn ich bei der Gestaltung einer Webseite im Kopf rein als Idee für die Strukturierung eine Tabelle benutze!



4 Fazit
Da die Kombination aus HTML und CSS nicht ausreicht um die praktischen Anforderungen an die Gestaltung von Webseiten umzusetzen, muss man hier pragmatisch denken, und der Tabelle ihr Existenzrecht für Layoutzwecke einräumen. Das Problem liegt nicht bei den Designern, sondern bei der Definition des HTML Standards. Desweiteren ist man auch stark and die Beschränkungen des Browsers gebunden. (IE 6!) Natürlich ist das der Fehler von dem Browser Hersteller, aber in der Praxis hilft dir diese Tatsache nicht - du musst deine Webseite trotzdem auf diesen Browsern zum laufen bekommen, wenn die nicht-funktionale Anforderung dies vorschreibt.
Die eigentliche Problem liegt ganz woanders: Es fehlen Abstraktionsschichten beim Aufbau von Webseiten. Man bräuchte prinzipiell eigentlich folgende Schichten:
1) Inhalt der Webseite (Semantik!) --> RDF
2) Aufbau und Struktur des Layouts
3) Stylesheets
Derzeit wird strukturierter Inhalt, (Bedeutungs-)Semantik und Präsentation miteinander vermischt (DIV oder Table Lösung). Das ist nicht gut!



5 Persönliche Einstellung
Ich selbst habe schon lange keine Tabellen mehr verwendet, da ich meine Webseiten selbst designe, oder meine Designs von Desgiern bekomme, die in einem Bereich arbeiten, wo z.B. 3-spaltige Layouts nicht nötig sind, bzw die schlechtere Wahl im Sinne des Designs sind. Dennoch bin ich immer wieder frustriert, wenn ich mit ansehen muss, wie überall im Internet Neulingen und halb-profis eine falsche praktische Grundlage für die Gestaltung einer Webseite gegeben wird. Das geht mittlerweile so weit, dass Designs, die ein drei-spalten-layout benötigen als schlecht dargestellt werden. Das ist einfach eine traurige Argumentation, die es garnicht Wert ist, in die Liste der Argumente oben mit aufzunehmen. Wie etwas aussieht hat der Designer zu sagen, und nicht derjnige, der es dann umzusetzen hat.
Wie man auf meiner eigenen Webseite sehen kann, benutze ich keine Tabellen: 6 Sonstige interessante Links und Zitate zum Thema[/SIZE]

[url]http://www.flownet.com/ron/css-rant.html
Seitdem ich diesen Artikel gelesen hab, ist mein Verlangen nach dem Verfassen dieses Artikels erheblich gestiegen. Ich hatte das schon länger vor, da mir der "CSS-War" einfach suspekt ist. Existieren tut er jedoch auf alle Fälle!

http://stackoverflow.com/questions/282489/css-div-w-border-images
Hier noch ein Beispiel, wo mittels einer DIV-Suppe etwas umgesetzt wird, was aufgrund der Beschränktheit von CSS nicht besser zu machen ist. Die Semantik geht auch hier den Bach herunter!

Da geht die Suchmaschinenfreundlichkeit den Bach runter... und auch viele andere Sachen. Sind deswegen Flash Seiten prinzipiell böse, schlecht und dumm? Ich mag keine Flash Seiten, aber nur aus rein user-orientierten und Design Gründen. Dennoch sieht man hier ganz deutlich wie irrsinnig die ganze Argumentation für rein CSS basierte Layouts sind.
Für mich ist das einzig wichtige Argument das folgende: Wartbarkeit und Lesbarkeit des Codes.


http://rondam.blogspot.com/2009/02/css-and-meaning-of-life.html
If SEO and semantics are so important, a new layer should be added to HTML or CSS or XML that is purely for bots and search engines and screen readers, that allows a developer to markup the semantica flow of the document, irrespective of the actual physical layout of the code.
Das wäre die eigentlich Lösung

http://rondam.blogspot.com/2009/02/css-and-meaning-of-life.html
Using tables for layout is as bad as using horrible CSS hacks to make a site do anything other than what websites are supposed to do, that is, display content in an easy to read coherent way.

http://rondam.blogspot.com/2009/02/css-and-meaning-of-life.html
Who says that tables are not accessible to the blind? That's BS. As someone who works with assistive technology and electronic accessibility for the blind issues, format tables are absolutely accessible -- and more reliable with certain screenreaders than sloppy CSS will ever be.


http://glazkov.com/2005/05/02/tilt/
tables are bad, but they may be necessary to keep the layout intact in real-life conditions.
Die Thematik mit einem Satz auf den Punkt gebracht!
 
Zuletzt bearbeitet:
Ohne mir jetzt alles durchgelesen zu haben: Auch in CSS gibt es eine Eigenschaft display:table, mit der sich reine Layout-Tabellen erstellen lassen und die von den meisten Browsern bis auf den IE < 8 bereits unterstützt wird. Der IE dagegen unterstützt bereits display:inline-block, was dem ebenfalls ziemlich nahe kommt.

PW-toXic schrieb:
HTML:
<div id="menu"></div>
<div id="content"></div>
<div id="shortInfo"></div>
Die Namen der divs sollte man natürlich so verwenden, wie sie dem Aufbau der Webseite entsprechen würde. Hier kommt eine gewisse intuitiv verständliche Semantik rein, die jedoch nirgendwo exakt definiert ist -> gefährlich!
Wie? Streng genommen sind alle das Menü, der Inhalt und die Kurz-Info alles dasselbe: Ein Bereich (engl. Division). Die id dagegen dient nur zur präziseren Beschreibung.
PW-toXic schrieb:
Noch besser wäre:
HTML:
<menu></menu>
<content></content>
<sidebar></sidebar>
Das ist jedoch eine fiktive Syntax, die so nicht existiert. wünschenwert wäre es so jedoch.
Doch, sie existiert: XML. Wenn man so versessen davon ist, dann kann man den ganzen Inhalt einer Seite in mehrere XML-Dateien auslagern. Ginge auch.
PW-toXic schrieb:
Klar wird jedoch, dass die div-Suppe von oben rein garnichtsmehr mit einer strukturellen Semantik zu tun hat, da die div-verschachtelung rein dem Layout dient, und nicht der Struktur des Dokuments, welche (möglicherweise) in drei Bereich aufgeteilt werden kann: Menü, Inhalt, und Sidebar (diese könnte man ggf. noch präziser benennen).
Das zählt also auch nicht mehr.
 
Zuletzt bearbeitet:
Den ganzen Text in einen Satz zusammengefasst:

Tabellen sind lediglich für die Darstellung von tabellarischen Inhalten wie Preislisten oder Übersichten zu verwenden.
 
Vollkommen richtig t R I A S, Tabellen sind dazu da um Tabellen darzustellen, aber nicht um irgendwelche Menüs von irgendwelchen Contentseiten zu trennen.

Zudem sieht man was er für einen Scheiss schreibt bzgl. der Entwicklungszeit, der Ladezeit und der Barrierefreiheit.

Ich frage mich wie eine Datei die mit tables vollgeballert ist und größer ist als eine Datei mit DIV Containern schneller laden sollte... ebenso eine Frage des Traffics. Wenn Onkel Hubert eine Homepage hat wo im Monat 50 Clicks drauf sind, dann mag das egal sein. Sollten aber mehrere 100.000 Clicks pro Monat entstehen sieht die Geschichte wieder ganz anders aus.

Aber eigentlich hat claW. im anderen Thread schon alles gesagt..
https://www.computerbase.de/forum/threads/viele-fragen-webdesign-dreamweaver.554287/#post-5665574
 
Ohne mir jetzt alles durchgelesen zu haben: Auch in CSS gibt es eine Eigenschaft display:table, mit der sich reine Layout-Tabellen erstellen lassen und die von den meisten Browsern bis auf den IE < 8 bereits unterstützt wird. Der IE dagegen unterstützt bereits display:inline-block, was dem ebenfalls ziemlich nahe kommt.
1) Dann lies es dir bitte doch mal durch bevor du etwas sagst was a) bereits besprochen wurde und b) keinen Sinn ergibt.
2) Etwas was im IE 6 nicht geht ist keine akzeptable Lösung für den Großteil aller Webseiten (Nichtfunktionale Anforderung!)
3) du willst display: table machen, aber mir verbieten tabellen zu benutzen? Aber Hallo!
Ich bin sprachlos ;)
4) ein inline-block, was dem ganzen "sehr nahe" kommt hilft mir nichts, wenn er die Eigenschaften die ich wünsche nicht vollständig umsetzt.


Wie? Streng genommen sind alle das Menü, der Inhalt und die Kurz-Info alles dasselbe: Ein Bereich (engl. Division). Die id dagegen dient nur zur präziseren Beschreibung.
Ich spreche hier nicht von der strukturellen Semantik die HTML anbietet, sondern von einer intuitiv verständlichen semantik, die nirgendwo klar definiert ist, sondern rein darauf basiert, dass Menschen kontextabhängige Sachen verstehen können. Zugegeben ist dieser Abschnitt evtl. fehl am Platz, ändert jedoch nichts an der Tatsache.

Doch, sie existiert: XML. Wenn man so versessen davon ist, dann kann man den ganzen Inhalt einer Seite in mehrere XML-Dateien auslagern. Ginge auch.
Mit reinem XML kannst du keine Webseiten darstellen, sondern eine variable Struktur ohne jede Semantik. Um dort eine Semantik hineinzubekommen benötigst du eine DTD oder XML-Schema oder Relax NG (und was es sonst noch so gibt), das dir erstmal die erlaubten Elemente definiert. Dann brauchst du desweiteren eine Dokumentation, die genau die Bedeutung von jedem Element definiert, und alle Browser müssen das verstehen können (Unmöglich allein aufgrund von IE6, da dieser nicht geupdated wird)

Tabellen sind lediglich für die Darstellung von tabellarischen Inhalten wie Preislisten oder Übersichten zu verwenden.
Falsch.
Bitte lies den Text nochmal, und zeige uns, dass die Pisa Studie für Deutschland doch nicht ganz der Wahrheit entspricht -> Lesekompetenz

Zudem sieht man was er für einen Scheiss schreibt bzgl. der Entwicklungszeit, der Ladezeit und der Barrierefreiheit.
Du hast rein garnichts verstanden. Bitte lies auch dir dir den Text aufmerksam und mit Kopf durch.
 
Zuletzt bearbeitet:
Weiss auch nicht was das die Pisa Studie damit zu tun hat, aber man sieht was dabei herauskommt :).

Faktum ist was ich geschrieben hab. Alles andere ist kein heutiger Standard mehr. Das man hier und da Ausnahmen machen kann bzw. beide Varianten möglich sind steht nicht zur Debatte. Für ein Seitenlayout sind Tabellen einfach nicht mehr zu verwenden und fertig.
 
t R I A S schrieb:
Tabellen sind lediglich für die Darstellung von tabellarischen Inhalten wie Preislisten oder Übersichten zu verwenden.

Turbostaat schrieb:
Vollkommen richtig t R I A S, Tabellen sind dazu da um Tabellen darzustellen, aber nicht um irgendwelche Menüs von irgendwelchen Contentseiten zu trennen. / Zudem sieht man was er für einen Scheiss schreibt bzgl. der Entwicklungszeit, der Ladezeit und der Barrierefreiheit. [...] ebenso eine Frage des Traffics. Wenn Onkel Hubert eine Homepage hat wo im Monat 50 Clicks drauf sind, dann mag das egal sein. Sollten aber mehrere 100.000 Clicks pro Monat entstehen sieht die Geschichte wieder ganz anders aus.

@trias und dem beipflichtenden Turbostaat
Das ist immer super: Jemand zerbricht sich den Kopf und kommt zu diskussionswürdigen Ergebnissen und dann kommen gleich Zwei und bezichtigen ihn der Scheißelaberei. Drückt mal auf STRG-U, damit wären beide Argumente schon mal weg.

Was man tun und lassen soll, ist natürlich 'ne andere Frage. Im Grunde geht's um Trennung von Layout und Content und nicht um Traffic (CB!) oder "Welche Inhalte in Tabellen?". Wenn der Content aus "Preislisten und Übersichten" besteht, greife ich bei konsequentem Div & Co.-Einsatz, wenn ich es sauber mache, natürlich nicht wieder auf table, td & Co. zurück. Entweder mach' ich eine divcss-Landschaft oder nicht. Und ob man das will und kann bzw. es ratsam ist, zeigt der dankenswerte Beitrag des Threadstarters ganz gut ...

P.S.
Alle vBulletin-Foren (wie ComputerBase) bis Version fällt-mir-nicht-ein basieren z.B. auf Tabellen-Layouts, sicherlich kein Onkel-Hubertus-Projekt ...
 
Zuletzt bearbeitet:
Dann schau dir das WBB3 an und du hast deine Antwort...

@trias und dem beipflichtenden Turbostaat
Das ist immer super: Jemand zerbricht sich den Kopf und kommt zu diskussionswürdigen Ergebnissen und dann kommen gleich Zwei und bezichtigen ihn der Scheißelaberei. Drückt mal auf STRG-U, damit wären beide Argumente schon mal weg.
Nein sie fallen nicht weg, die Darstellung wie sie hier ist, ist semantisch einfach nicht korrekt. Da gibts keine Diskussion drüber, es ist nach dem heutigen Standard einfach so und einsehbar.
 
Zuletzt bearbeitet:
Wobei man allerdings Zugeben muss, dass ein Forum eine Tabelle ist, wenn man sie rein von den Daten sieht:
zwei spalten:
1) Ersteller des Beitrags
2) Beitrag
Allerdings wird die Tabelle bei dem Forum auch für ganz andere Dinge verwendet ;)


trias du hast keine Ahnung von Semantik, also bitte argumentier damit nicht.
 
Dass die Inhalte tabellarisch sind steht außer Frage, das stimmt, aber hier gehts in erster Linie ums Layout. Die leeren Spalten und Platzierungen von Buttons gehören sicher nicht dazu.

Schonmal was von TableZenGarden gehört? Ich net.

Wenn du meinst dass ich keine Ahnung davon hab, dann soll es so sein. Ich will dir da gar nicht im Weg stehen :)
 
Ich sehe das ganze mit den Tabellen folgendermaßen:

Vorweg:
Ich persönlich bin (lt. Threadersteller) ein CSS Dogmatiker.
Ich verwende leidenschaftlich XHTML 1.0 und CSS zum Layouten meiner Websites.


Ich bin von Tabellenlayout auf CSS-Layout umgestiegen, weil mir das ganze um einiges einfacher viel. Und darum geht es!
Wenn der Webentwickler empfindet, dass ihm Tabellen besser von der Hand gehen - bitte, dann soll er Tabellen schreiben.
Das Internet ist es bereits "gewohnt" aus Tabellen zu lesen. Und natürlich kapier Google auch, wo was steht. Selbst wenn es eine Tabelle ist.

Noch dazu geht es nur darum "wie soll die Homepage aussehen". Und nicht: "Ich bin gezwungen das die Homepage so aussieht, weil...".
Wenn ich will das der Inhalt rechts oben steht, und die Links links unten, dann soll es so sein. Wie das realisiert wird, ist doch alles gleichgültig. Das Internet hat gelernt damit zu Leben.

Klar, ich bevorzuge die neuesten Standards. Aber wozu? Wenn es nicht anders geht, greif ich eben auf ältere Techniken zurück. (Zwar ungern, aber ich kann das Rad auch nicht neu erfinden... idR. aber finde ich doch eine Lösung ;) )


Was ich noch sagen will: Div-Suppe hin oder her, den "Div-Wahnsinn" halt ich im Kopf nicht aus. Wenn ich ein CSS-Layout mit Div's erstelle und tabellarisch etwas anzeigen soll (zB eine Preisliste) dann kommt die bei mir in eine Tabelle. Für so etwas war das <table> schließlich gedacht.

---
So.. "Senf" dazu gegeben hab...
 
Zuletzt bearbeitet:
PW-toXic schrieb:
Der code ist absolut unverständlich.
Auf den ersten Blick, ja. Spätestens wenn es komplexer wird, und man mit colspan/rowspan und verschachtelten Tabellen arbeitest, findst du dich in Tabellenlayouts wesentlich schlechter zurecht als in divs.
Der logische Aufbau widerspricht der Intuition, da die mittlere Spalte zuerst kommt (Anm. Ja ich weiss: SEO..)
In diesem Beispiel, ja.
3.2.5 Suchmaschinen unfreundlich (SEO)
1) Das ist nicht mein Problem, sondern das der Suchmaschine.
Das hilft dem Ersteller einer Webseite aber auch nicht. Soll er sich damit abfinden, dass seine Seite nirgends gefunden werden kann?
3.2.6 Längere Ladezeiten für den Benutzer
Table wins.
Wieso? Weil der Code an sich (vielleicht) wenige Byte kürzer ist als als in CSS, dafür aber eine Tabelle erst angezeigt wird, wenn der komplette Inhalt - also auch große Bilder oder Videos - übertragen worden sind? Bei CSS ist das nicht der Fall. In Zeiten von DSL & Co. vielleicht kein Einwand mehr, aber wenn du die Größenunterschiede von Tabellen- und CSS-Layouts extra erwähnst.

Ich gebe aber auch zu, dass an einigen Stellen divs unsinnig oder deutlich klomplizierter sind als Tabellen.
 
Zuletzt bearbeitet:
In Zeiten von DSL sollte man aber auch vielleicht daran denken das es auch Leute gibt die noch Modem / ISDN oder nur DSL light haben, die sind über jedes Bit, was weniger geladen werden muss, heilfroh.
 
Antoniker schrieb:
Ich persönlich bin (lt. Threadersteller) ein CSS Dogmatiker.
Ich verwende leidenschaftlich XHTML 1.0 und CSS zum Layouten meiner Websites.
Nein du bist aus meiner Sicht eben KEIN Dogmatiker, weil du die Verwendung von Tables duldest, sie jedoch als nicht gut erachtest. Ich sehe es kein bisschen anders, ausser dass man bei ein paar Sachen mit Tables besser bedient ist. Begründungen dafür hab ich genug angegeben.
Ich verwende auch leidenschaftlich XHTML 1.0 strict, und habe nicht vor das zu ändern. Ich selbst verwende keine Tabellen (Siehe Punkt 6)

Turbostaat schrieb:
In Zeiten von DSL sollte man aber auch vielleicht daran denken das es auch Leute gibt die noch Modem / ISDN oder nur DSL light haben, die sind über jedes Bit, was weniger geladen werden muss, heilfroh.
So ein Schmarrn.
1) Ist das eine Nicht-funktionale Anforderung
2) http://www.spiegel.de/netzwelt/tech/0,1518,610503,00.html -> top aktuell
3) Brauchen Tabellen wie oben bereits gezeigt weniger Speicherplatz und somit Traffic.

Mr. Snoot schrieb:
Auf den ersten Blick, ja. Spätestens wenn es komplexer wird, und man mit colspan/rowspan und verschachtelten Tabellen arbeitest, findst du dich in Tabellenlayouts wesentlich schlechter zurecht als in divs.In diesem Beispiel, ja.Das hilft dem Ersteller einer Webseite aber auch nicht. Soll er sich damit abfinden, dass seine Seite nirgends gefunden werden kann?Wieso? Weil der Code an sich (vielleicht) wenige Byte kürzer ist als als in CSS, dafür aber eine Tabelle erst angezeigt wird, wenn der komplette Inhalt - also auch große Bilder oder Videos - übertragen worden sind? Bei CSS ist das nicht der Fall. In Zeiten von DSL & Co. vielleicht kein Einwand mehr, aber wenn du die Größenunterschiede von Tabellen- und CSS-Layouts extra erwähnst.
Ich habe nirgendwo gesagt, dass Table Layout in irgendeiner Art und Weise gut ist, sondern ich habe gesagt, dass es prinzipiell schlecht ist und vermiden werden sollte. Dein Argument bezieht sich jedoch nur darauf. Das Thema colspan und verschachtelung tritt hier nicht auf.
Zur Suchmaschine:
Ich sagte es ist das Problem der Suchmaschinen, und die sehen das genauso, und deswegen werden auch Seiten mit table layout gefunden. Deine Argumentation verläuft also im Sand.
Zur Ladezeit: Da die Tabelle nur für das Layout benutzt wird und nicht für übergroße Datenmengen, tritt dein Argument nicht in Kraft.
Davon abgesehn zeigt mein Browser bei sehr großen Tabellen den Inhalt der Tabellenzeilen an bevor die letzte Zeile geladen wurde.
 
PW-toXic schrieb:
....
So ein Schmarrn.
1) Ist das eine Nicht-funktionale Anforderung
Was erzählst du da wirres?
Ohja, sie fordern, versprechen, machen sonstwas. Und was wird in der Wirklichkeit umgesetzt? Und im Jahre 2014 75% uiuiuiui Oh man....

3) Brauchen Tabellen wie oben bereits gezeigt weniger Speicherplatz und somit Traffic.
Das kommt ganz auf das Design drauf an und die Komplexität einer Homepage. Mag ja sein das ein Homepagedesign basierend aus dem Jahre 1994 kleiner ist als eines mit div Container, wir leben aber bereits im Jahre 2009.
 
t R I A S schrieb:
Dann schau dir das WBB3 an und du hast deine Antwort... Nein sie fallen nicht weg, die Darstellung wie sie hier ist, ist semantisch einfach nicht korrekt. Da gibts keine Diskussion drüber, es ist nach dem heutigen Standard einfach so und einsehbar.

Die "Semantik" wird nicht besser, wenn ich - vgl. Deinen Beitrag oben - Preislisten reinpacke. Außerdem: Google rules (Semantik). --- WBB3: Ja, keine Tabellen mehr. Ob es sich dadurch einfach warten lässt, ich weiß es nicht.

Wie PW-toXic sagt: "Letzendlich muss man auch hier das magische Dreieck erwähnen: Kosten - Qualität - Zeit".

P.S.
Um auch mal was Nützliches zu sagen :)
=> Was die SE-Tauglichkeit betrifft, also Punkt 3.2.5. bzw. Bedenken von Mr. Snoot (DIV o. Tabelle), kann ja jeder seine WWW-Würste oder z.B. die URL dieses Threads hier reinstecken: http://seobrowser.com/
 
Zuletzt bearbeitet:
Turbostaat schrieb:
Das kommt ganz auf das Design drauf an und die Komplexität einer Homepage. Mag ja sein das ein Homepagedesign basierend aus dem Jahre 1994 kleiner ist als eines mit div Container, wir leben aber bereits im Jahre 2009.
VERDAMMTNOCHMAL!
Jetzt lies dir den Thread durch oder misch dich hier nicht in eine Diskussion ein ohne anderen Leuten zu zu hören!
Das ist Unverschämt in jeder Hinsicht!

Turbostaat schrieb:
Was erzählst du da wirres?
Ok ich mach es für dich mit einem Beispiel:
http://www.iminlikewithyou.com/#/
Ich bezweifle das bei der Konzipierung der Webseite die Nicht-funktionale Anforderung "Muss auch mit Modem in einer angemessenen zeit laden" eine Rolle gespielt hat.
Dennoch ist diese Seite einfach scheisse geil! Und das sage ich als Flash Hasser ;)

http://de.wikipedia.org/wiki/Anforderung_(Informatik)
Hier findest du mehr über nicht-funktionale Anforderungen. Das was ich hier beschreibe bezieht sich auf "Antwortzeiten"


Ansonsten möchte folgendes Bild in den Raum werfen, und verbitte mir auch gleichzeitig jede Deutung ;)
http://www.reallybored.net/m_pictures/305.jpg
 
Zuletzt bearbeitet:
Hi,

ich finde die Trafficdiskussion ziemlich absurd. Zum Einen stehen selbst jemandem, der noch mit Analogmodem unterwegs ist, 56k (56 000, 56 tausend) Kilobyte - und damit entsprechend 56 tausend Zeichen pro Sekunde - zur Verfügung (bei UTF je nach Version evtl. die Hälfte). Jener wird sich sicher weniger über ein paar überflüssige Tags, als über schlecht komprimierte Bilder/Flashvideos ärgern.

Zu Anderen finde ich es einen Schritt in die falsche Richtung, korrektes, lesbares (sowohl mensch- als auch maschinenlesbares) Markup nur für ein paar Byte weniger zu schrotten. Das ist so, als würde man keine Absätze, Klammern und Einrückungen machen, nur damit die Quelldatei kleiner ist. Das würde mMn auch mehr bringen - trotzdem absurd.

MfG, Christian.



PS:

Und zum Letzten: Jemand, der entsprechend viele Tags hat, hat meistens auch entsprechend viel Content. Und da zählt mMn das Verhältnis. Aber auch dies ist zu vernachlässigen, wenn der Content technisch und verständlich rübergebracht wird. Es wird wohl auch kaum jemand behaupten, man sollte jetzt bei allen Texten den letzten Absatz wegschneiden, weil das Modemusern entgegenkommen würde (wenn die Hälfte der Information fehlt.)
 
Zuletzt bearbeitet:
@PW-toXic

Führ dich mal nicht so auf.... :rolleyes:

Eine Website sollte immer so gestaltet werden das jeder damit einigermaßen klarkommt, ebenso für jeden moderat erreichbar sein sollte, egal ob Modem oder DSL. Genauso sollte man bedenken das es Menschen gibt, die z.B. kein Flash oder Javascript verwenden (wollen) und die Bedienbar- und Nutzbarkeit sollte dennoch gewährleistet sein, auch wenn es für den Webentwickler Mehrarbeit bedeutet.

Ebenfalls sollte man seine Seiten so aufbauen das sie egal in welchem Browser aufgerufen, diese (so gut wie) genauso aussehen und funktionieren.
Auch wenn es mich z.B. ärgert weiterhin an den IE6 anzupassen, per extra Style Sheet o.ä. kann man Nutzer dieser Systeme nicht einfach ausschließen und / oder der Auftraggeber würde einem was husten wenn man eine Homepage abliefert, welche nur auf Firefox, Opera o.ä. läuft. Oder halt nur auf dem Internet Explorer.

Ansonsten hat man seinen Job verfehlt.
 
Zurück
Oben