Webstandard & Webdesign - CSS, HTML

Spiele ich doch mal ein bisschen den Advocatus Diabolus, damit die Diskussion in Schwung kommt :-)

Zu 1: Jein. Ein einfaches (!) Tabellendesign muss keine Barrieren enthalten - verschachtelte Tabellen schon. Bei Handhelds etc. stimmt es, also mehr Ja als Nein.

Zu 2: Jein. Eine einfache Layouttabelle wird schneller laden als viele der CSS-Monster, die ich schon gesehen habe. CSS-Dateien mit bis zu 50 KB habe ich schon erlebt. Bei Auslagerung der Hacks in Conditional Comments kommen noch zusätzliche Server-Anfragen hinzu. Da CSS-Dateien aber nur einmal laden, steigt der Vorteil, wenn die Besucher mehrere Seiten ansehen. Also: bei Stippvisiten nein, bei längerem Aufenthalt Ja. Also wieder mehr Ja als Nein.

Zu 3: CSS ist auch Quellcode, also ohne Änderungen gehts nicht. Bei guten dynamischen Anwendungen via PHP ist Logik, Content und HTML eh sauber getrennt, da spielt das keine Rolle. Es ist sogar mit CSS aufwändiger, da die Manipulation von CSS-Dateien über PHP nicht trivial ist und durch die vorhandenen Templatesysteme nicht unterstützt wird. Ausserdem muss ich bei Änderungen unter Umständen mehrere Dateien ändern: das HTML-Template und die CSS-Dateien, während bei purem Tabellendesign nur eine Templatedatei geändert werden muss. Auch hier also: Prinzipiell Ja, aber oft auch Nein.

Zu 4: Das widerspricht meiner Erfahrung. Natürlich achten Suchmaschinen nicht auf den META-Tag, aber auf semantische Richtigkeit achten sie auch nicht, und die Anzahl der Tabellen ist ihnen völlig egal. Die am besten gefundenen Seiten mit dem höchsten PageRank sind Tabellenlayouts. Hier lautet die Antwort generell Nein, nicht zutreffend. Für Suchmaschinen reicht eine grundlgegnde Semantik: h1 bis h6 und p, mehr brauchts nicht.

Zu 5: Bei kleinen Projekten Nein, bei großen Ja. CSS-Layouts zu erstellen dauert länger (und zwar nicht unbedeutend). Ausserdem erfordern sie viel mehr Tests und langfristige Pflege (Siehe IE 7). CSS-Layouts sind nur mit hoher Sachkenntnis zu erstellen und zu pflegen - und höhere Sachkenntnis = höhere Kosten. Bei größeren Projekten amortisiert sich das (und zahlt sich irgendwann auch aus), bei kleinen nicht. Bei sehr kleinen Projekten kommt hinzu, dass die Wysiwyg-Edioren und vor allem deren Integration mit Photoshop oder Fireworks nicht verwendet werden können.

Grundlegend Standards eine einheitliche Richlinie für alle! "Und das ist auch gut so!"
Nehmen wir mal folgendes an:

Der Einbauherd von "Menschlein A" geht kaputt. "Menschlein A" geht somit in das Fachgeschäft und kauft sich einen neuen Einbauherd. Dieser wird am nächsten Tag bei "Menschlein A" angeliefert. "Menschlein A" freut sich dann das der Herd so schnell einbaut ist. Und warum? Weil es Standards gibt! Somit pass der neue Herd in das gleiche Einbauschränkchen wie der Alte.

Aber "Menschlein A" hätte auch den Einbauherd der Firma "XY" aus Vagadugo nehmen können welcher rund 120€ billiger wäre. Diesen hätte er gleich selber mitnehmen können, denn der wäre ja 30KG leichter, so stand es jedenfall auf dem Papier (wobei da der Bezug zu Wirklichkeit fehlt). Aber spätestens beim Einbau hätte er gemerkt das irgendetwas nicht stimmt. Irgendwie iss das Loch größer als der Herd ... hmm?!? ... kurz beim Hersteller anrufen ... ahhh ja da gibts Abdeckblenden für die Ränder ... so und der Stromanschluß ?!? ... kurz nachgefragt ... gibts auch in Euro-Ausführung ... schön *g* ... 30min und einige Teile später ... So was kost dat nun ? ... 195,99€ zugl. Versand & Versicherung ... macht 210€ !
Spätestens dann versteht jeder welchen Zweck Standards haben und verfolgen *g*.

Webstandards: Sollten schon um ihrer selbst willen verfolgt werden (siehe Elektroherd)
CSS vs. Tabellenlayout: Habe mich gerade wieder durch den Code einer sehr stylischen Kundenseite gewühlt, die im Validator 2m scrollbare Fehler auswirft. Und den Kunden natürlich Schmerzensgeld kostet, wenn ich den Tabellenverhau beim besten Willen nicht auf Anhieb durchblicke. Wo ist hier noch mal der Inhalt, den ich ändern sollte?
SEO: Eine standardkonforme Seite, die Inhalte so verpackt, wie es die Natur (sorry: W3C) vorgesehen hat, ist schon die halbe Miete. Wer Layouttabellen benutzt, formatiert auch Überschriften mit suchmaschinenwirksamen Keywords per font-face=irgendwas statt h1. Und haßt Haustiere (oder so...)

CSS-basiertes Layouten ist überhaupt viel cooler, weil alles so übersichtlich ist, die Tabellenverhaue verschwinden und einen klar-gereinigten Quelltext hinterlassen.

Wer das einmal gemacht hat und über die Anfangsprobleme (vielleicht Hacks, ungewohnten Listeneinsatz, Browserprobleme) hinweggekommen ist, wird nie wieder zurück wollen.

Die in Punkt 1 angesprochene einfache Anpassung an verschiedenste Ausgabemedien einen entscheidenden Vorteil, der jedoch fast nie erwähnt wird. Gerade an dieser Stelle entstehen entweder Einschränkungen für den Nutzer oder Mehrkosten für den Kunden, weil mediensepzifisch nicht nur das CSS, sondern der gesamte Code angepasst werden muss.

1. Versuche einem Kunden, der sich selbst als wichtigsten Benutzer der Seite sieht, zu erklären was seine Zielgruppe im www ist. Hier muss im Bereich der Massenmedien oder Fachzeitschriften, BWL-Ausbildung vieles noch nachgeholt werden. Aber im Grude ein sehr gutes Pro-Argument.
2. Auch hier leider wieder der DAU als Kunde. Traffic???
3. Blos keine solchen Aussagen. Das geht nur wenn absolut keine Stilangaben im Inhalt stehen. Und das ist echt heavy zu machen. Aber hier passt gut ein Beispiel zu einem print-style extra.
4. Stimmt so nicht. Es interessiert nur der Google-Platz. Dieser wird zu 99% durch externe Verlinkung, Seitengröße und Aktualität der Seite bestimmt.
5. CSS3 wird zeigen, dass man mit Tabellen schon über deren Design-Möglichkeiten hinausgeschossen ist.

Persönlich verwende ich validen Code um sicherzustellen dass zukünftige Browser die Seiten weiterhin genauso darstellen.

Das ist im wesentlichen mein Argument: manchmal ist eine Layouttabelle schneller und einfacher. Was nicht heissen soll, dass dein Problem nicht mit CSS zu lösen wäre, das ist es sehr wahrscheinlich. Ich finde es kurios, wenn man sich schlecht fühlt, weil man für ein spezielles Problem auf eine Layouttabelle ausweichen möchte. Ich würde die Tabelle einfach verwenden - und wenn ich irgendwann später Zeit und Lust habe, dann puzzle ich es mit CSS zusammen. Ich sehe das eher sportlich :-)

Hi,
danke für die Antworten. @Dirk: Ja, Sowas in der Art hatte ich auch schon probiert. Absolute (oder auch fixed) Positionierung funktioniert im IE und im Firefox aber nur dann gleich, wenn der umgebende Container so groß ist wie der Canvas. Ansonsten gibt's im IE gerne einen horizontalen Scrollbar, obwohl rechts gar Nix zum angucken ist. Letztens habe ich damit experimentiert, den Container mit den beiden Bildern wie einen "pre" Block zu formatieren (ich glaube, das hiess: "white-space: preserve" oder so ähnlich). Damit bleiben die Bilder nebeneinander. Aber der Containerhintergrund wird beim Verkleinern des Viewports trotzdem verkleinert, so daß die Bilder über den Rand des Containers hinausragen. Sieht unschön aus. Für den IE habe ich auch schon damit experimentiert, einen leeren Block-Container mit fester Breite einzubauen, sozusagen als "Zusammenschieb-Begrenzer". Hat auch nicht funktioniert, der IE reißt in diesem Fall das Bild auseinander.
Wie gesagt, mit einem modernen, standardkonformen Browser, der css2 unterstützt, bei dem man dem Container per min-width das Schrumpfen ab einer bestimmten Mindestgröße untersagen kann, kein Problem. Aber es gibt verbreitete Browserimitate :( Tja, ich werde wohl in diesem Fall auf die 2-Zellen Tabelle zurückgreifen. Es ärgert mich zwar etwas, daß ich die Lösung, die ich mir wünschen würde, nicht finde, aber so schlimm ist es nun auch wieder nicht. Eine Lehre, die man aus Sowas ziehen kann: Es geht eben nicht immer ohne eine Layouttabelle.
Gruß
Siegfried

Es hätte sich villeicht angeboten, in die ListItems die Absätze reinzupacken. Aber egal, Teil 2 ist auch echt super geworden!