PW-toXic schrieb:
Die Organisation, die den Standard für die Web Sprachen wie (X)HTML und CSS definiert sieht das ähnlich:
[...]
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:
hast du dir dabei denn mal das datum angesehen? mit firebug kommt man ganz einfach auf folgenden wert:
Last-Modified: Mon, 06 Nov 2000 23:07:21 GMT. mittlerweile haben wir 2009 und css 3 steht vor der tür (der große schub wohl mit firefox 3.1, opera 10, sowie ie 8, webkit sollte dies ja so oder so in den snapshots immer aktuell haben).
PW-toXic schrieb:
2 Was ist die alternative Lösung?
stimmt soweit im großen und ganzen.
PW-toXic schrieb:
3 Die Tabelle hat weiterhin ihr Existenzrecht bei Layouts
NEIN, hat sie nicht!
css 3 steht mittlerweile vor der tür und spätestens ab hier sind tabellen für das layout obsolet.
[1] selbst mit der aktuellen css version ist all das überhaupt kein problem. tabellen sind einzig und allein für übersichten und auflistungen da, sonst für nichts!
PW-toXic schrieb:
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.
aha? die mittel von css sind stark begrenzt. dann sieh dir bitte mal die unten verlinkten webseiten an. sieht dies nach "stark begrenzt" aus?
[2],
[3],
[4] ich habe bisher auch immer alles via css-layout erfolgreich hinbekommen und musste nie auf tabellen fürs layout zurückgreifen.
PW-toXic schrieb:
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.
wieso willst du dich auf andere elemente beziehen? ich weiß dabei nicht wirklich, was du damit meinst. ein beispiel wäre vllt angebracht, denn so wie es bis jetzt dort steht, hat es null bedeutung. und ja, hacks sind nicht wirklich schön, aber sie ermöglichen eine sehr leichte umsetzung für etwas, "was nicht geht".
PW-toXic schrieb:
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!
meinst du so etwas?
[5] wenn nicht, bring ein beispiel, denn darunter kann ich mir nur schlecht etwas vorstellen
PW-toXic schrieb:
Drei Spalten Layout mit DIVs
wie wäre es damit?
HTML:
<style type="text/css">
<!--
* {
margin: 0;
padding: 0;
}
#table {
width: 90%;
height: 64px;
margin: 0px auto;
}
#table > .col1, #table > .col2, #table > .col3 {
float: left;
display: inline-block;
width: 25%;
height: 100%;
}
#table > .col1 { background: #d8dada; }
#table > .col2 {
width: 50%;
background: #a8d5f2;
}
#table > .col3 { background: #98999a; }
-->
</style>
<!-- ... -->
<div id="table">
<div class="col1">Spalte 1</div>
<div class="col2">Spalte 2</div>
<div class="col3">Spalte 3</div>
<div style="clear: both;"></div>
</div>
PW-toXic schrieb:
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.
hm, kein argument zieht mehr?
PW-toXic schrieb:
(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%))
die eigenschaft
right ist also ein "css-hack" in deinen augen? dann müsste genauso
left,
top, sowie
bottom ein hack sein. oder gehen wir weiter:
padding und
margin -> css hacks.
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.
dies soll in xhtml 2.0 eintreffen (den artikel suche ich im laufe des tages noch raus). wenn es dir per (x)html nicht passt, dann verwende doch bitte xml, mithilfe von xslt, xpath und anderen "spielereien". dort kannst du definieren was du willst und es sieht so aus wie du willst (ein
sehr sehr sehr sehr schönes beispiel ist hierbei die wow-europe.com seite von blizzard (auch wenn man wow nicht mag ist es aus programmiertechnischer sicht auf jeden fall einen blick wert!), welche vollkommen auf xml basiert). komischerweise gibt es in xml überhaupt keine tabellen mehr.
PW-toXic schrieb:
Wer hier also mit der Semantik argumentiert, hat sie nicht verstanden.
semantik != verständnis. ich gebe deinen satz an dich zurück.
Semantik
[...]Ersteres nennt man den Begriff, die Bedeutung oder den Sinn eines Ausdrucks, das zweite das Zeichen.[...]
PW-toXic schrieb:
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.
siehe oben. offenbar wurde dies auch widerlegt.
PW-toXic schrieb:
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.
jap, die css-layout variante ist um einiges einfacher wartbar (selbst mit vielen weiteren verschachtelten tabellen bzw. divs).
PW-toXic schrieb:
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!
findet man sich ein mal in css-layouts rein und sammelt ein wenig erfahrung, geht dies um einiges logischer und einfacher von der hand als ein tabellenlayout (welche mir mittlerweile übrigens sehr schwer fallen, da alles einen festen ort besitzt).
PW-toXic schrieb:
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.
ja,
padding,
margin und
border sind ziemlich gemein. trotz allem sollte man solche sachen sowieso selten im layout verwenden, sondern eher um text o.ä. einzurücken.
PW-toXic schrieb:
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.
siehe
[6],
[7],
[8]
PW-toXic schrieb:
3.2.6 Längere Ladezeiten für den Benutzer
Table wins.
epic fail. siehe mein "alter" post:
claW. schrieb:
desweiteren gibt es den vorteil, dass stylesheets nur ein mal geladen werden bzw. dann, wenn der user einen refresh ohne cache benutzt (bei firefox shift + reload). wenn ein normaler refresh oder ein seitenwechsel stattfindet, wird immer die stylesheet datei aus dem cache genommen (zumindest machen das ordentliche browser so). weiterhin kannst du damit auch einfache portierungen hinbekommen (aus deinem html code z.b. latex code machen und darüber nun ebooks o.ä. generieren).
ahja: latex code und ebook war ein
beispiel, keine wirkliche anwendung.
PW-toXic schrieb:
3.2.7 Vermischung von Inhalt und Präsentation
Table wins. Siehe Semantik oben.
epic fail. eine tabelle ist kein mittel um ein layout zu erstellen, sondern um übersichten anzufertigen! warum wird in sehr vielen artikeln wohl von
unsichtbaren tabellen gesprochen? wenn es denn layout-mittel sein sollen, warum spricht man nicht einfach von "layout-tabellen"? unsichtbare tabelle = layout-mittel -> css-layout = strukturierungsmittel - passt nicht ganz oder?
PW-toXic schrieb:
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.
hierzu lege ich dir
[9] ans herz. barrierefreiheit wird dir in zukunft viel viel häufiger begegnen als du denken magst. ob es nun der pc ist oder nicht, spielt keine rolle. es kann genauso gut ein handy (wozu haben neue sonst wlan?), ein pda, ein navi oder sonst was sein. zeig mir hier mal bitte, wie du deine seite auf einfache weise (ohne neue spezielle unterseiten erstellen zu müssen [
mit gleichem inhalt!]) an ein anderes gerät als den pc anpasst. geht mit tabellen sehr schlecht bei einer maximalen auflösung von 320x240 oder vllt sogar schon 640x480. das css-layout kannst du kurz anpassen und schon sieht die seite komplett anders aus (
wobei der inhalt ganz und gar nicht angerührt wird). ohne schnick-schnack, ohne bilder (für portable geräte ohne dsl-bandbreite hervorragend), ohne horizontaler scrollleiste.
PW-toXic schrieb:
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
)
bist du behindert? ich denke nicht. woher weißt du dann, was für diese personen schwer ist? irgendwo müssen diese erkenntnisse doch herkommen. und an den haaren herbeigezogen werden sie auch nicht sein, denn sonst würde man in der presse nicht "dauerhaft" davon reden. btw, wenn du mit dem wort "bilde" blinde meinst, dann ging dieser schuss nach hinten los.
PW-toXic schrieb:
3.2.9 Tabellen sind nicht zum Layouten da, sondern nur für Daten. (Im allgemein weltlich-menschlichen Sinne)
ein richtiger satz zwischen dem vielen kauderwelsch.
PW-toXic schrieb:
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!.
niemand hat es definiert, man hat es einfach aufgrund von fehlenden technologien verwendet. durch css ist dies abgelöst worden, auf einem weit saubererem weg! wer heutzutage noch auf tabellen setzt, meint wohl auch dass der internet explorer der einzige und beste browser ist.
PW-toXic schrieb:
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!
was ist der unterschied zwischen einer html-tabelle und einer allgemeinen tabelle? beide werden mittels <table> eingeleitet und beschreiben im endeffekt die gleiche sache - eine tabelle. wo ist hierbei der unterschied? ich, und bestimmt auch viele andere, kann/können ihn nicht erkennen. die eine wird zum layouten verwendet, die andere für daten. trotz allem sind beides tabellen.
PW-toXic schrieb:
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.
und genau an den designern liegt es heutzutage und nicht an dem standard. einige gründe habe ich oben schon erwähnt.
PW-toXic schrieb:
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.
ganz ehrlich: an den ie 6 passe ich nichts mehr an! mittlerweile ist der internet explorer 7 standard und wer diesen nicht benutzt hat einfach pech gehabt. irgendwann läuft der support dafür aus (oder rufst du jetzt noch bei microsoft an und fragst warum dein modem nicht unter windows me läuft?) und man kann einfach nicht erwarten, dass ein webdesigner sich solchen alten schinken widmet. ich passe in 10 jahren doch auch nicht mehr auf den firefox 3 an, selbst wenn dieser noch bei 30% marktanteil sein sollte... irgendwann ist schluss und man sollte eine aktuelle version einsetzen. einen tüv sollte man in sachen software langsam auch einrichten, denn sowas würde eine menge ersparen.
PW-toXic schrieb:
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
xml, xslt, xpath und konsorten. dafür gibt es ein gutes anfänger tutorial auf w3schools.com.
und vllt auch noch mal hier ein kleiner seitenhieb auf meinen
alten post (bezüglich overhead von tabellen und traffic und demzufolge die damit verbundenen kosten an den webmaster):
claW. schrieb:
sagen wir der overhead durch tabellen beträgt ~1 kib. diese seite bekommt täglich nun 500.000 unique klicks (die refreshs [= eigentliche anzahl an seitenaufrufen] sind dabei nicht einberechnet!), was summa summarum 500.000 kib ausmacht (sprich 488 mib). wenn du hier noch jeden einzelnen refresh mit einbeziehst (so wie du hier im forum thread für thread durchsuchst z.b.), bist du gut und gern bei über einem gigabyte. nimm dies mal 31 (für einen monat) und du hast allein durch deine tabellenlayouts 31 gigabyte overhead an traffic, den du natürlich bezahlen musst und diesen natürlich schnellstmöglich eliminieren willst.
der vorteil von divs ist weiterhin einfache barrierefreiheit (wie schon erwähnt wurde), d.h. du kannst ein und die selbe seite für pcs, pdas, handys, waschmaschinen (die bekommen sicher bald auch einen ethernet anschluss), kühlschränke und was weiß ich noch anpassen, alles mit einer simplen stylesheet definition.
ein klein wenig weiterführende lektüre an der stelle (zu dem thema):
Introduction to The Web Standards Curriculum
In the old days, people used to do things like laying out their web sites inside giant tables, using the different table cells to position their graphics, text etc (not what tables were intended for, adds superfluous markup to the page). They used to use invisible images called spacer GIFs to fine tune positioning of page elements (not what images are intended for, add superfluous markup and images to the page). They used to write JavaScript that generated menus etc on the fly (no good for people with JavaScript disabled in their browsers, or people with visual impairments using screenreaders, which get confused by such JavaScript) or worked on only one browser (what about people using other browsers?). They used to insert styling information directly into the HTML using <font> elements (terrible for maintenance, and adds superfluous markup to the page). And many other crimes against web development. The worst thing is that I say “in the old days” above, but the fact is that a lot of people are still doing things like this!
Tabellen als Mittel für Web-Seiten-Layouts
Einen Nachteil sollten Sie jedoch beachten, wenn Sie beabsichtigen, den gesamten anzuzeigenden Inhalt einer Web-Seite mit Hilfe einer blinden Tabelle anzuordnen: Tabellen werden vom Web-Browser erst angezeigt, nachdem ihr kompletter Inhalt eingelesen wurde bzw. erst in dem Augenblick, wo der Web-Browser genau weiß, wie groß und wie breit die Tabelle angezeigt werden muss. Das bedeutet bei der Datenübertragung aus dem Web, dass ein Anwender am Bildschirm länger wartet, bis überhaupt etwas angezeigt wird. Es sei denn, Sie benutzen die Möglichkeit, um Seite Spalten vorzudefinieren.
Ein weiteres Problem besteht darin, dass Browser mit gewünschten Breiten- und Höhenangaben nicht unbedingt so umgehen, wie Sie es wünschen. Inhalte werden dann plötzlich gestaucht, auseinandergezogen usw. Dies hat zur Erfindung des so genannten "blinden Pixels" geführt, einer kleinen GIF-Grafik, die nur aus einer einfarbigen Fläche besteht, deren Farbe wiederum als transparent definiert ist. Zusammen mit der Möglichkeit, Seite Breite und Höhe einer Grafik in HTML unabhängig von der tatsächlichen Größe der Grafik anzugeben, lässt sich eine solche Grafik scheinbar unsichtbar und unauffällig einbauen. So lassen sich vor allem feste Mindestbreiten für einzelne Spalten einer Tabelle erzwingen, und der Browser kann die Inhalte darin nicht mehr stauchen. Diese Technik gilt einerseits als unsaubere Trickserei, ist aber andererseits Ausdruck für fehlende Formatiermöglichkeiten. Mittlerweile stellen Kapitel Stylesheets solche Möglichkeiten zwar bereit (vgl. die CSS-Eigenschaft Seite min-width), doch das nutzt nicht viel, solange die weit verbreiteten Browser noch keine Unterstützung dafür anbieten.
[1] Everything You Know About CSS Is Wrong
[2] Die besten 5 CSS-Seiten (komplett ohne tabellen!)
[3] CSS Zen Garden (im moment gibts einen 403 error)
[4] Best of CSS Design 2007
[5] Gleichhohe Spalten (Auffüllen)
[6] CSS Layouts ((grid-)layouts zum wählen)
[7] Tabellenlayouts 2.0: CSS-Tabellen fürs Webseitenlayout?
[8] Grid Generator
[9] Video zum Thema Barrierefreies Webdesign
Webseiten ausdrucken? Webstandards bieten Alternative! (thema barrierefreiheit)
Checkliste für die Layoutentwicklung
anderweitige links zum thema css (mehr oder minder mit dem eigentlichen thema verknüpft):
/CSS/ Creating scalable layouts
9 Top CSS Essential Skills That Every Web designer Should Learn
10 Principles of the CSS Masters
Pixelgenaues CSS-Layout trotz relativer Werte
CSS – wir räumen auf!
10 Challenging But Awesome CSS Techniques
Powerful CSS-Techniques For Effective Coding
SitePoint CSS Reference
Web Developer's Handbook
Best Practices for Speeding Up Your Web Site
Articles by Topic: CSS
Hip to Be Square
). Erst Barrierefreiheit predigen, dann einen wichtigen Browser ignorieren 
.
