Layouttabellen total Technikwürze 129

Da mir der Oliver sowieso aufn Zeiger geht, ich kick ihn jetzt mal. Und dann hab ich meinen ganzen Account da gelöscht. Ich hab da echt die Schnauze voll gehabt von dem Teil. Na ja, sei es drum. Also fangen wir mal an. Welche Nummer haben wir denn? Mal ein bisschen hochscrollen.

Danke schön. Technikwürze 129. Es geht um Layouttabellen total. Heute mit mir dabei sind Dirk Jesse.

Hallo.

Und der Tomas Caspers.

Guten Tag.

Bam, bam, bam, bam, bam, bam, bam. Hier schneide ich später.

Herzlich willkommen zu Technikwürze, eurem Design- und Webstandards-Podcast. Von und mit David Macievski.

Ja, wir alle drei, beziehungsweise noch mehr Webkrauts haben 'n schönen Artikel im Netz gefunden, beziehungsweise eigentlich zwei, die aufeinander aufbauen. Wer möchte denn mal was drüber sagen?

Dirk hatte sich am meisten darüber aufgeregt, deswegen darf er anfangen.

Gut, genau, dann sag ich was. Ja. Ich habe vor – wann war's? Am Mittwoch, glaub ich, ne? – den Artikel in meinem Feedreader gefunden von Mike Davies,, der da heißt: The Solace of CSS Evangelism und der sich in 13 wunderschönen formulierten Punkten, einen ebenfalls im Netz erschienenen Artikel über 13 Gründe, warum CSS viel, viel besser ist als Tabellenlayout, zur Brust nimmt und jeden einzelnen Beitrag, jeden einzelnen Punkt in dieser Diskussion, widerlegt. Und da dieser Artikel wunder...

sehr, sehr lang ist, hat das also gereicht, um bevor ich am Ende war, beim Lesen schon wirklich in Richtung 100 zu gehen. Mir sind die Haare zu Berge gegangen und erst am Ende dieses Artikels kommt im Prinzip eine Auflösung, worum's Mike Davies hier,, eigentlich geht. Ja, es hat aber dann 'ne ganze Weile gebraucht, um mich 'n bisschen abzuregen.

Ich hatte auch so das Gefühl, als ich den, in Vorbereitung zu der Sendung gelesen hatte, dass ich auch kurz davor war, meine eigene Schuhe vollzubrechen, ich dann aber am Ende angelangt bin und hab dann so langsam verstanden, worum es sich dreht. Und vor allen Dingen, ich wusste nicht, von wem diese Webseite ist, beziehungsweise von wem der Artikel ist. Guck dann unter Kontakt und Impressum, hab nichts gefunden, guck auf die Startseite und sehe Mike Davies. Aha, interessant.

Senior Web Developer für Yahoo Europa. Und da hab ich mir gedacht: „Moment, eigentlich ist er doch, wenn einer derjenigen, die eigentlich richtig Ahnung davon haben sollten, dass das alte Vorurteil Tabellen sind böse, CSS ist besser, ne, dass er dafür stehen könnte. Aber wie gesagt, interessanter Artikel und darüber wollen wir uns heute unterhalten. Ja, wollen wir vielleicht mal einsteigen mit den 13 Punkten, die er so erzählt hat?

Ja, vielleicht sollte man noch 'n Warnhinweis,, nachschieben, dass wenn den jemand liest, den Artikel von Mike, Mike Davies, Link wie üblich in den Show Notes, doch bitte zuerst unten anzufangen und den quasi von unten nach oben zu lesen, weil der Mike eben,, das, ja eigentlich gemacht hat, was, was man nicht machen sollte. Also zumindest, wenn man, mit 'nem Publikum rechnen muss, was sehr schnell mal eben 'ne Seite überfliegt und nicht der ganzen Argumentation folgt, die aufeinander aufbaut.

Und dann am Schluss wird das Ganze dann erst rund gemacht durch den letzten, Abschnitt Advice for a CSS Evangelist, der das dann noch mal darlegt, worum's Mike eigentlich wirklich geht. Also wenn man das nur überfliegt, dann kommt man natürlich sehr schnell zu dem Schluss, der, der spinnt und der findet irgendwie Layouttabellen viel besser als CSS und versucht das jetzt zu verkaufen und genau das ist es nicht..

Ist im Prinzip 'n Horrorthriller.

Bitte?

Im Prinzip 'n Horrorthriller, der fünf Minuten vor Schluss noch mal sich die gesa-gesamte Handlung um 180 Grad dreht.

Ja, genau.

Deswegen bitte entweder wenn ihr oben anfangt, bitte zu Ende lesen oder wie, Thomas sagt, am Ende anfangen. Okay, ja, worum geht's denn da?

Fangen wir mit dem ersten Punkt an?

Gern.

Ja, klar.

Fast, faster page loading. Also das, typische Argument für CSS-Layouts ist ja, dass Seiten mit, wenn sie mit CSS entwickelt sind, schneller laden, weil eben Style Sheets gecacht werden und demzufolge, nicht so viele, Daten vom Server geholt werden müssen.

Mhm. Das, Entschuldigung, da hake ich mal kurz ein. Das ist ja das, was, teilweise auch wir, auf jeden Fall aber die CSS-Evangelisten immer behaupten. Also dass Webseiten schnell laden, sofern CSS eingesetzt wird. Und, der Mike hält eben dagegen und ja, Punkt, Punkt, Punkt.

Ja, und man kann jetzt auch sagen, warum er dagegen hält. Er sagt eben ganz einfach, CSS wird in der Regel ausgelagert, in der Regel auch nicht sonderlich schön mit mehreren Style Sheets. Das heißt alles Latenzzeiten, Wartezeiten, HTTP Requests. Da wird auch nicht sonderlich viel optimiert. Und das ist nicht wirklich glaubhaft schneller als zu sagen: „Ich hab hier ein einfaches Table Layout.

Das ist, das Markup, das bisschen mehr, was an Markup da bei ihm im Quelltext steht, wird innerhalb dieses einen Requests geladen, was sowieso das HTML-Dokument vo-vom Server zieht und ist damit schon flinker.

Mhm. Genau, er sagt ja auch, dass, Inline CSS 'ne Möglichkeit wäre, das, bei CSS-Layouts schneller zu machen. Allerdings die Web-Ega... Evangelisten, die ja die, die Ladezeiten irgendwie hervorheben, das doch, weil's eben sauber ist, auslagern wollen.

Ja. Ne, der hält ihm dagegen so. Wartbarkeit und Ähnliches, ne. Also das natürlich, du nicht die immer wieder gleichen Anweisungen und Regeln in allen, HTML-Dokumenten drinstehen haben willst. Also das ist, das ist natürlich ein Argument dafür. Wodrauf Mike aber abhebt, ist, ist, dass, es gibt, es gibt eine Untersuchung, die ist schon 'n bisschen älter von Yahoo, dass, ein, ein ganz großer Teil der Besucher bei Yahoo, mit einem leeren Cache vorbeikommt.

Also dass diese, diese vermeintliche Effekt, des CSS ist sowieso schon bei einer Seite wie Yahoo, die bei vielen Leuten vielleicht auch die Startseite ist, liegt sie sowieso schon im Browser-Cache und muss nicht noch mal extra vom Server angefragt werden.

Beziehungsweise sie wird angefragt, Server sagt: "Du hast sie schon, die ist nicht veraltet, also nimm die, die in deinem Cache ist." Da spart man schon eine Menge Traffic, aber das Problem ist, dass eben sehr viele Webbrowser offensichtlich so eingestellt sind, dass sie beim Schließen des Webbrowsers den Cache gleich mit leeren. Das ist ein Knopf in Firefox, den kann man drücken.

Wenn man das gemacht hat, werden die Style Sheets dann eben auch gelöscht und dann bei jedem neuen Aufruf der Seite, dann wieder neu geladen. Und damit ist natürlich der, der Performance-Vorteil des Cachings komplett weg. Wobei man dazu sagen muss, dass das natürlich nur, sagen wir so für diesen Fall gilt, Browser, zumachen. Beim Erst-, beim Erstbesuch der Seite, selbst da, wenn der Cache leer ist, ist es klar.

Dann, dann lade ich diesen ganzen Krempel runter, egal wie er, im Layout angelegt ist, ob nur als Tabellenlayout oder als CSS, aber auch schon bei der zweiten Seite, die ich lade- Mhm. -von derselben Domain, ne. Also wenn ich nicht den Cache generell ausgeschaltet habe, dann kommt dieser Effekt wieder zum Tragen. Ja, ja, aber der, der wichtige erste Eindruck ist, die Seite lädt langsam. Mhm. Genau, das ist das Problem.

Du kommst auf das, du kommst das erste Mal auf 'ne fremde Seite und uä, gähnend langsam. Ja, auch bei, auch beim zweiten Mal auf 'ne fremde Seite, wenn ich zwischendurch meinen Browser zugemacht hab, ne. Also am nächsten Morgen zum Beispiel. Habe ich wieder das Problem, die lädt ja ewig langsam und alle Folgeseiten auf dem Server laden dann relativ schneller. Aber die erste Seite, die den ersten Eindruck hinterlässt, lädt ewig langsam. Ja.

Was, was hier natürlich nicht in, in der Argumentation mit auftaucht, ist, dass Tabellen generell erst gerendert werden, wenn deren Inhalte da sind. Mhm. Das heißt, wenn ich also eine Tabelle aufbaue und dort ein grafisches Layout dahinter reinpacke, indem ich eben entsprechende Image-Elemente da drin hab, dann müssen diese Inhaler, Inhalte in der Regel alle erst mal vollständig, halbwegs vollständig geladen sein, ehe der Browser mit dem Rendern anfängt.

Und genau das macht CSS nicht, sondern CSS, wenn das die ersten zwei Container oder er hat den ersten Container innerhalb von Body, wenn der da ist, dann wird der gerendert. Ja, wobei auch das lässt sich mit Tabellenlayouts umgehen. Also bitte nicht falsch verstehen, ich will, ich will jetzt nicht pro Tabellenlayouts argumentieren, ne. Ich versuche nur grade, das nachzuvollziehen, was der- Genau. -was der Mike, gemacht hat, nämlich die Argumente von dem, Menschen, wie hieß er?

Matt, Matt irgendwas. Moment, ich hab's mir auch abgeschrieben. Also der- Matt, Matt German heißt er. Ja. Auch da kannst du natürlich 'ne Seite, die mit Layoutervellen, aufgebaut ist, so aufbauen, dass du eben für verschiedene Elemente verschiedene Layoutervellen nimmst. Es muss nicht eine ganz große sein, sondern du klatscht einfach zig Tabellen nacheinander, die dann natürlich progressiv alle nacheinander laden. Und auch- Ist klar.

-auch von den, mit, auch da kannst du halt Tabellenlayouts mit, mit CSS vermischen, mit, mit Table Layout Fixed und so weiter. Hast du da auch, kannst du auch Performance optimieren, ne. Mhm. Also insofern ist das auch, auch eigentlich kein sauberes Argument pro CSS. Mhm.

Ja, aber das, zeigt auch, vorweg, wenn ich das Ganze mal vorwegnehme, dass, die Argumentation, also wenn ich jetzt diesen letzten Absatz mal beiseite lasse, dass die Argumentation, dass sie sich an den Haaren herbeizieht, der Mike.

Und zwar, sagt er zwar auf der einen Seite, also, Tabellenlayouts sollte man, wenn man sie macht, denn auch richtig gut, durch, ich sag mal, also richtig durchplanen, und dann richtig veröffentlichen und das noch mal prüfen und richtig sauber machen, also richtig Aufwand reinstecken.

Auf der anderen Seite, sagt er auch, dass, die Nobodys, die sich eben nicht auskennen und für die CSS zu schwierig ist, worauf er ja auch ein bisschen eingeht später, dass er dann wiederum sagt, für die muss es ganz einfach sein.

Also, na ja, also das deswegen, also schlussendlich stelle ich mir dann immer noch die Frage, ob es ein bisschen Scherz war von ihm oder ob es ihm wirklich nur um die Widerlegung gilt und, er, er überschreitet ein paar Gesetze, indem er auch ein paar Argumente reinzieht, die vielleicht nicht hundertprozentig gelten. Aber wie gesagt, darum soll's erst mal gar nicht gehen.

Es geht einfach nur darum, einfach mal zu vergleichen beziehungsweise die Leute darauf aufmerksam zu machen:, überlegt doch mal, was ihr da redet, ja. Also wenn ihr jetzt sagt, CSS ist schneller, dann muss es nicht unbedingt stimmen, weil auch Tabellen können schnell sein. Mhm. Ja. Das kommen wir beim, kommen wir beim nächsten Punkt, ne. Geht's ja gleich weiter. Sagen wir so, oder bei dem nächsten Punkt. Nehmen wir den nächsten gleich mal. Lowering Hosting Costs. Mhm. Ja.

Das typische Argument, ne: Mit CSS habe ich geringeren Traffic, weil eben wieder, das geht jetzt alles wieder, die Kette bezieht sich jetzt immer wieder auf die vorgehenden Punkte, weil ich eben vorher sage, ich hab den Cache angeschalten, ich kann das Styling im Prinzip auslagern und, Sachen, die gecacht werden, werden automatisch nicht noch mal runtergeladen, demzufolge geringeren Traffic, geringere Kosten. Mhm. Das ist das Argument von, der ursprünglichen Chromatic-Seite.

Und ja, das wird hier an, an der Sprechstelle genauso widerlegt, wie, widerlegt wegen dem Cache.

Wo kommt das her, ne? Wenn der Cache nicht an ist, kann das alles nix bringen. Ich lager eher noch, ich lager eher noch aus. Das heißt, statt einem einfachen, statt einem einfachen Dokument, wo alles drin ist, hole ich mir zusätzliche HTP, HTTP-Requests, indem ich zusätzliche Dateien, nämlich die Style Sheets, anfordere, was in der Regel dann eher länger dauert.

Ja, dazu kommt, dass, dass, dieser, dieser Mensch bei Chromatic Sites, sich ja quasi durch, durch seinen eigenen Quelltext, ja selbst widerlegt. Also wenn er- -sagt, er hätte da low hosting house, schreibt er in seinem Artikel und das ist alles viel, schneller und so weiter und hat aber selber-

Elfte Zeilen. Also zumindest Mike hat's so, aufgezählt.

Elf Style Sheets, aber d-du sagtest irgendwie, in Wirklichkeit sind's, weil da noch mal welche dynamisch nachgeladen werden, sind's paarmal zwanzig Style Sheets.

Also ich hab jetzt hier nach, nachgeguckt. Ich, ich finde hier einundzwanzig Style Sheets auf seiner Seite.

Einundzwanzig Style Sheets, ne, die, die, der braucht, um diesen einen Artikel darzustellen. Das ist ja nicht nur, das ist ja nicht nur die, die Cache-Problematik, sondern es muss dann ja auch einundzwanzig Mal beim Server angefragt werden, hat sich die Datei geändert.

Also selbst wenn die lokal im Cache vorliegt, fragt der Browser ja trotzdem, d-diesen Last Modified, beim, beim Server an und der Server sagt: "Nee, ist..." Also man hat trotzdem einundzwanzig Requests, die erst mal hin und her müssen, bevor der Browser irgendwas machen kann.

Ja. Zumal das hier, ich, ich guck mir die Seite, ich guck mir die, die Style Sheets grad an. Das ist also, pro Style Sheets ist das nicht mehr als, hmm, maximal 'ne A4-Seite. Ne, Books CSS, Node CSS, Device CSS, System CSS, User CSS, Content Module CSS, Failed Group CSS, View CSS, HTML Elements CSS, Tabs CSS.

Er hat ein bisschen zu viel gewollt.

Da stehen teilweise dann zwanzig Zeilen drin, ne.

Ganz genau.

Schwer.

Also das ist- -geschwindigkeits technisch 'ne Katastrophe.

Also ich nehme mal an, dass er ganz einfach eine kleine Seite hat, die kaum gelesen wird, sodass sich bei ihm gar kein Traffic aufstaut, sodass er eben der Meinung ist, er würde da Traffic-Kosten sparen. Wahrscheinlich hat das noch nicht ganz groß, mit großen Seiten zu tun gehabt, wo es wirklich wichtig ist, wie viel Bytes du rüber schickst.

Und dass du wirklich noch mal auch heute in Zeiten von DSL in jedes einzelne Bild reingehst, und optimierst wirklich jedes einzelne Bild und welches Format nimmst du. Also zumindest hab ich so bei Sevenload gemacht. Also da hab ich jedes, wirklich jedes einzelne Bild, auch wenn's im Background ist, geguckt, kann ich die zusammenmergen und, mir irgendwelche Techniken überlegen.

Das muss echt klein sein, sonst läuft aber, Traffic auf ohne Ende und bei ihm ist es offensichtlich nicht der Fall, deswegen kommt er mit seinen über zwanzig Style Sheets gut aus wahrscheinlich.

Da, da gab's mal die, ach so. Da gab's ein interessantes mal, 'nen, 'nen interessanten Vortrag von Nicole Sullivan von Yahoo, die über, über, Website-Performance geredet hat. Da müssten wir mal gucken, ob wir den, den Beitrag noch mal rausfinden. Das war so 'ne Präsentation. Wo sie drüber geredet hat, wie beispielsweise bei, bei Amazon das ist.

Wenn diese, die haben bei Amazon wohl eine Untersuchung gemacht und, getestet, w-was, wie sich die, die, die, die Umsätze entwickeln, wenn die Seite schneller oder langsamer wird.

Ja, und zwar um, um Zehntelsekunden schneller.

Genau, da ging, da ging's, glaub ich, um 0,1 Sekunden langsamer, hei, hieß da automatisch, glaub ich, ein Prozent, weniger Umsatz.

Ich glaub, das war sogar zweistellig, was da an Umsatzeinbußen dann zu verzeichnen war.

Also das ging extrem schnell hoch.

Ja, ja.

Das ist eben, das ist das, was man sich als normaler Einz, als normaler Einzelentwickler für, für, für, für 'ne popelige kleine Homepage einfach nicht vorstellen kann.

Ja. Und das ist, das ist genau der Punkt, was der David eben meinte, dass, dass, sehr oft du aus 'nem GIF oder Ping oder einfach nur über die Entscheidung, nehm ich ein GIF oder Ping, da so dermaßen viele Bytes rausquetschen kannst und ob du jetzt sechzehn oder zweiunddreißig Farben nimmst. Um genau zu kontrollieren, si-sieht man da überhaupt einen Unterschied auf dem durchschnittlichen Monitor.

Kannst du da viel mehr rausquetschen, als du jeweils irgendwie per CSS versus,, Table, erreichen kannst.

Ja, ja. Oder klassisches Beispiel ist auch, wenn man sich für 'ne grafische,, grafisches Menü entscheidet, nimmt man dann Einzelbilder oder schmeißt man die alle zusammen, auch in den verschiedenen Status, und macht das mit Sliding Door Technik. Auch alleine nur schon damit kannst du, super, super viele Kilobytes sparen. Alleine schon, weil in jeder einzelnen Datei so viel vorweggenommen, muss ja immer der Kopf gesendet mit werden.

Von wegen ich bin eine GIF-Datei, ich hab so und so viele Farben und jetzt fang ich mal an. Und da steht halt in jeder Datei drin und alleine das summiert sich schon so, dass man denkt, mit einem großen Bild, was ich hin und her verschiebe-

Ja, ja.

-kann ich schon echt einiges sparen.

Ganz klar. Ja, und für CSS ist das natürlich genauso, ne. Es ist, es, es, es macht schon durchaus Sinn, CSS zu zerlegen in, in verschiedene sinnvolle Bausteine, einfach um's auch bei großen Projekten, pflegen zu können. Natürlich kann ich 'ne kleine Homepage oder ein kleines Blog mit, mit, mit einem Style Sheet komm ich da zurecht. Aber wenn ich eben große, umfangreiche Seiten habe, dann wird auch dort so ein ein, einzelnes Style Sheet elend lang.

Ne, das wird wahrscheinlich niemand, in einem Stück, aus einem Stück File entwickeln. Aber der Unterschied ist eben der, dass man, wenn ich weiß, dass ich auf Performance gucken will, dass ich dann eben sage: "Gut, die Entwicklerfassung ist das eine. Das, was ich auf der Seite dann wirklich laufen habe im Live, Live-Betrieb, ist was anderes." Und das wird eben entsprechend optimiert. Ne? Und aber genau diesen Schritt macht kaum jemand.

Ja. Und das ist mal der, der wirklich viel bringt.

Ganz genau.

Bringt dann wirklich extrem viel dann, ja. Ja, sind wir bei Punkt drei. Redesign some efficient, so behauptet der eine. Ich les es mal, ich les es mal im Englischen vor. So: "Redesigning a website using tables, is significantly lo-slower than redesigning a website using CSS." Behauptet er also, dass, das Redesign einer, einer Webseite mit Tabellen langsamer vonstattengeht als das Redesign mit CSS. Und wie das so ist, Maik versucht es dann zu widerlegen.

Und wie das dann so ist, kann ich da Maik eigentlich auch nur beipflichten, weil ich, jetzt in meiner, gesamten Karriere, die nun auch schon ein bisschen länger andauert, kein einziges Redesign vor die Brust gekriegt habe, wo nicht auch das HTML angefasst werden musste.

Ja. Ich wüsste auch nie, wie man es richtig begründen kann, wenn ich davon ausgehe, sagen wir so vor zehn Jahren war CS, war Tab, CSS-Tabellen waren der Stand der Technik. CSS. Ist es, sei es mal drum. Warum sollten die Leute, die damals entwickelt haben, langsam, jetzt pauschal langsamer arbeiten, als, als die Leute, die jetzt ein Layout entwickeln?

Ne, das-

Und das, und das zweite Beispiel ist, als Konkretes mal: Mein aktueller Arbeitgeber hat eine Webseite mit einem Tabellenlayout, einem dreispaltigen. Und ich an der Stelle, wenn man so ketzerisch ist, kann man auch behaupten, das ist in fünf Minuten zusammengebaut, nämlich Tabelle auf, drei Spalten, Tabelle zu und es funktioniert. Mit CSS braucht man ein bisschen länger.

Absolut. Ja.

Also.

Ich meine, das, das alte Argument, dass Redesigns schneller gehen, ist ja auch an den Haaren herbeigezogen, weil es eigentlich, eigentlich schön passt. Wenn man sich überlegt, ich habe meine HTML-Struktur, und ich ändere jetzt mal die Farben und ich, verschiebe mal, die rechte Spalte nach links, ohne dass ich jetzt, das HTML anfassen muss, dann stimmt das zwar.

Allerdings, sei es dazu gesagt, dass wenn man ein Redesign macht und ein Redesign ist ja kein Refresh, sondern ein Redesign geht ja wirklich auch in die Struktur, dass man überlegt: Wie kann ich das heute besser machen? Oder ich habe neue Anforderungen an die Seite, dass ich sage, ich brauche jetzt noch eine Sidebar oder ich brauche jetzt noch irgendwelche Teaser-Bereiche oder Sonstiges. Beziehungsweise ich habe dazugelernt, das Ganze effizienter zu machen.

Genauso wie bei Technikwitzen, da habe ich auch das HTML noch mal eben angefasst, weil ich dachte: Mensch, ich baue das jetzt um und, mache das noch mal wirklich ganz neu. Und, schlussendlich, also es ist ein fadenscheinliches Argument, das ursprüngliche. Das heißt, ich kann mit CSS global über alle Webseiten das leicht ändern, also leicht ein Redesign machen.

Die Praxis sieht aber wirklich so aus, dass wenn man ein Redesign macht, dass man auch das HTML ändert und in Summe HTML plus CSS, sagt Maik, ist das aufwendiger, als wenn ich jetzt meinen HTML-Tabellenkram, hin- und herschiebe.

Oder zumindest vergleichbar. Also ob ich jetzt dann, wenn jetzt blau auf einmal grün sein soll, ob ich das dann, global über Suchen ersetzen, über meinen ganzen HTML-Bestand ändere einmal, oder ob ich dann eine Zeile im Code, vom Stylesheet ändere, ist jetzt auch nicht so der Riesenunterschied eigentlich.

Klar bin ich mit der einen Zeile Code im, im CSS, schneller fertig, aber, auch in, in tausenden Seiten, HTML-Bestand oder einer Datenbank per Suchen und Ersetzen mal eben die Farbe A in Farbe B ändern, ist jetzt auch nicht so der, der Riesenaufwand. Also auch da ist, das ist auch, auch nicht unbedingt so das Killerargument, dass Redesigns effizienter sind. Selbst auch, selbst bei kleinen Änderungen. Es ist...

Wo man einhaken könnte, sagen wir mal so, ich vermute, das, das ursprüngliche Argument,, bezieht sich ja darauf, auf das, was Webstandards eigentlich propagieren: Eine Trennung von, von, von, von, von Inhalt und Layout. Ne? -

Das gilt ja immer noch vor.

Wenn de, ja, aber wenn, wenn dem hundertprozentig so wäre- Dann hätte ich eben die Möglichkeit, das Layout komplett unabhängig v-von der, von der HTML-Struktur zu entwickeln. Nur das ist eben nicht so. Ne? Also diese hundertprozentige Trennung kriegen wir nicht hin. Wo man effektiver werden kann und jetzt kommt es wieder in den persönlichen Geschmack. Da kommt natürlich auch das hin, was ich mache, wo ich sage, ich empfehle es ja auch: Nehmt Frameworks.

Nicht jedes, aber es gibt zumindest einige, wo ich sagen kann, dort habe ich in gewissen Grenzen, für die, die, die Layout-Basis die Möglichkeit, nur mit CSS diese Grundstruktur schon mal zu machen. Und hole mir dadurch ein bisschen Zeit rein. Aber, sagen wir mal so: Je komplexer dieses, so, so, so ein Projekt wird, desto geringer ist dieser Anteil. Weil eben nachher die Inhalte kommen.

Wir hatten mit dem Tom, als wir telefoniert hatten, hat sie gesagt, ne, wenn man einfach sich überlegt, man hat vor drei Jahren mal einen Blogbeitrag geschrieben und wie man dort beispielsweise Code ausgezeichnet hat, ne? Und jetzt, jetzt macht man ein Redesign. Derselbe Inhalt muss aber rein und jetzt müssen die Inhalte umgeschrieben werden. Ne?

Das ist unter Umständen, das, diese Sachen, wenn man sagen, man, man, man, man macht alle zwei, drei Jahre macht man ein Redesign von der Seite, vielleicht sogar noch häufiger, aber die Inhalte ändern sich unter Umständen gar nicht. Das heißt, man hat viel mehr zu tun, damit das Markup der Inhalte auf aktuellen Stand zu bringen, als das eigentliche Layout. Und damit ist dieses Argument einfach weg. Weil es nicht mehr relevant ist an der Stelle.

Ja, die Argumentation geht ja immer von einer idealen Welt aus.

Ja, genau.

Also dass wirklich ganz sauber getrennt ist, Inhalt von, von Präsentation. Aber das Problem ist ja, dass du in HTML ja oder mit HTML ja schon gar keine saubere-- Also, oder in einer idealen Welt wäre, nicht nur der Inhalt von der Präsentation getrennt, sondern auch der, der Inhalt von der Struktur getrennt. Und das hast du in HTML ja schon nicht mehr.

Du hast ja automatisch irgendeine Form der Struktur drin, die schon eine bestimmte Art der Präsentation impliziert über Überschriftenstrukturen und Ähnliches, ne? Also das hast du in HTML ja schon, hast du ja da keine saubere Trennung. Das heißt, du musst das immer wieder anfassen. Das Beispiel, um das Beispiel auszuführen, was der Dirk da eben angesprochen hat. Da ging es ganz konkret um, das, das Weblog von, von „Einfach für alle", was jetzt auch schon bald acht Jahre läuft.

Und da haben wir natürlich, - Immer wieder Code Listings drin, aber, wie das dann so ist, haben wir vor, vor acht Jahren Code Listings anders ausgezeichnet als, als was vor sechs, vor vier, vor zwei. Das heißt, bei jedem Redesign musste dann wirklich, dann 'n Dump aus der Datenbank gezogen werden und, der, der, der Code angepasst werden, weil er dann einfach nicht mehr passte. Also simples Beispiel: So früher hab, hab ich Code Listings einfach mit, mit Pre und Code gemacht.

Mittlerweile mache ich sie mit OL, also als ordered list, weil es ist ja nichts anderes als eine Liste, Listing. Sprich, ich hätte dann jetzt die Wahl zwischen: Ich mach, bei jedem Redesign lasse ich die alten Styles drin und bl damit meinen Stylesheet auf. Bei vier oder fünf Redesigns hätte ich jetzt vier oder fünf verschiedene Versionen, CSS wie Code Listings aufgebaut.

Und Sachen, die sich alle gegenseitig überschreiben und du weißt nicht mehr, wo ist jetzt die Ursprung.

Mit den ganzen, mit der ganzen Kaskaden- und, und Spezifizitätsproblematik und so weiter. Oder ich hätte die Möglichkeit, jetzt dann jedes Mal alle zwei Jahre das HTML anzufassen.

Übrigens, da reingeschmissen, dieses Problem, die, die Redesigns, das CSS immer ständig mitzuschleifen, ist auch das, was ich in vielen Werbeagenturen sehe oder in, in vielen, bei vielen Webworkern, die arbeiten, die sich, Beispiele aus dem Netz kopieren in Sachen CSS, Tabs oder was auch immer die zu gestalten sind.

Hauen die dann rein, prüfen die nicht, überarbeiten die nicht großartig und überlegen sich, also merken dann, stellen an irgendeiner Stelle fest, dass gar nichts mehr hinhaut oder hier irgendeine Anweisung drin ist, die irgendwas macht, was ganz komisch ist, aber sie wissen nicht, wo es definiert ist. Auch ein Beispiel aus der Praxis.

Aber was ich noch einfügen möchte, wo ich auch mal ein HTML-Quellcode eventuell noch mal überarbeiten müsste oder generell die Inhalte ist, damals kleine Bilder verwendet. Ich mache heute ein Redesign und wir haben heute alle größere Monitor, alle Monitore, größere Auflösungen. Dementsprechend möchte ich die Bilder ein bisschen, die Inhaltsbilder plakativer gestalten, mach sie also größer.

Also auch dann, wenn ich wirklich konsistent in allen Artikeln, auch in den alten, das ans neue Layout, die breitere Spalte anpassen möchte, müsste ich sogar die Bilder noch mal überarbeiten. Also ein Redesign heißt nicht einfach nur ein bisschen im CSS rumbasteln. Die Praxis sieht wirklich ganz anders aus.

Genau, und deswegen können wir das nächste Argument eigentlich gleich mitnehmen und eigentlich mit wegwischen. Das heißt nämlich, Redesigns sind preiswerter. Wenn man sich das jetzt eben durchdiskutiert, was wir jetzt gerade eben zur Effizienz gesagt haben, dann kann man eigentlich nur dazu kommen, dass es vollkommen wurscht ist, mit welcher Technik ich arbeite. In jedem Fall, also davon hängt es nicht ab.

Sondern eher von, v-v-von einem sauberen Konzept, und von, von, von einem kontinuierlichen, sauberen Arbeiten mit bestimmten Standards, sodass ich eben bei jedem Redesign nur das Nötigste machen muss.

Das ist ein ganz wichtiger Punkt. Sauberes Arbeiten spart Geld und nicht die Technik, die du eingesetzt hast.

Genau, ja.

Wie viel, wie viel Redesigns habt-- Also ich, ich erinnere mich an ein größeres Projekt, was ich mal,, gut, darf ich jetzt nicht mehr drüber verraten eigentlich, aber wo halt, sehr, sehr viele Redakteure, auch Zugriff auf die Gestaltung der Seiten hatten, also mit irgendwelchen Tools, wie in dem Fall war es Dreamweaver, halt auch komplette Seiten gebaut haben. Und, es gab halt keine einheitliche Farbgebung.

Also ein, ein Blau, was auf dem Monitor gleich aussah, war im Quelltext aber eben, ein ganz leicht anderes Blau. Das heißt, ich konnte es also beim Redesign nicht einfach, ersetzen Blau durch Rot, sondern du hast es nicht gegriffen gekriegt, weil es eben kein, kein vereinheitliches Blau gab, sondern jeder Redakteur hat so lange am Schieberegler gedreht, bis-

Das ist halt, wie ich es sehen kann an seinem Monitor.

Ist halt klar. Also insofern, nun, da ist es dann wurscht, ob das mit CSS oder HTML gemacht ist. Es ist einfach, noch ein Schritt davor, ne, das, das mangelnde, mangelnde Qualitätsbewusstsein.

Genau, da kannst du mit auch, Copy and Replace, suchen und ersetzen. Kommst du glaube ich auch nicht weiter.

Keine Chance.

Das, das ist im Moment, würde ich sagen, das ist noch ein Riesenproblem. Gerade dieses Inhalte eingeben durch Redakteure. Ich, ja, wenn man sich anguckt, was es an WYSIWYG-Editoren gibt für Inline-Editoren, ne.

Und was die nicht alles falsch machen können.

Was die für einen Schrott in, in, in das HTML, in, in, nachher als HTML da raus rendern. Also mittlerweile gibt es die FCK Editor oder, oder, oder TinyMCE. Die kriegen es ja mittlerweile halbwegs hin, wenigstens Überschriften und Absätze und, und, und einfache Listen zu generieren. Aber selbst bei diesen Dingern klicke ich, wenn ich ein Bild einfüge, dann kommt mir, wird mir immer noch was mit, mit, mit, mit Vspace und Hspace da reingeschrieben. Ne?

Ich kann die Teile nur relativ umständlich konf,, umständlich, konfigurieren. Es gibt, bei jedem Editor, Editor ist in der Standardeinstellung erst mal drin, dass ich selbstverständlich Font tags und sonst was da alles benutzen kann. Ne? Und das ist, wenn man sich die Leute anguckt, wie die damit arbeiten, die kommen von Word und in Word stelle ich oben von, da sehe ich, ich schreibe gerade in Times und will eben eine größere Überschrift haben.

Und dann sage ich, die gehen da hin und sagen: „Nee, ich nehme jetzt nicht zwölf Punkt, nehme jetzt achtzehn Punkt“, anstatt, den Text in die Überschrift umzuwandeln. Und die arbeiten genauso in, nachher in ihrem Editor. Und die Editoren lassen es zu.

Und die Kunden wollen das auch so. Also ich, ich leb, erlebe das auch in der Agentur manchmal, wo ich als Entwickler sagen würde: „Wir, wir geben euch, dafür habt ihr uns engagiert, das, Design vor und, wie Texte geändert werden sollen und so weiter und so fort.“ Und, deswegen würde ich dem Kunden am liebsten eigentlich nur noch ein Textfeld geben, wo er maximal mit Textteil oder so was, seinen Text auszeichnet. Unter der entsprechend gerendert wird.

Die Kunden wollen aber standardmäßig, bevor ich meine Argumentation zutage bringe, wollen sie eigentlich immer: Ich will so was wie in Word machen. Ja, ich will hier fetten, ich will da doppelklicken und schön klickibunti. So was wollen die immer haben. Und, da muss man natürlich auch, Entschuldigung, den Schwanz in der Hose haben und auch einem großen Kunden mal sagen: „Nee, Entschuldigung, aber du hast jetzt viel Geld dafür bezahlt.

Dafür, dass wir dir das einmal anständig machen und das ist jetzt dein Corporate Design. Und damit deine Redakteure dann eben nix kaputt machen, reduzieren wir die Funktionen von diesem Editor." Also nur so kann es laufen.

Ja, damit sind wir eigentlich gleich beim fünften Argument, ne. Das, das passt da, fließt da sehr schön ineinander über. Da geht's um Visual Con, Consistency Maintained throughout Websites, also um, dass man eben mit CSS es leichter erreichen kann, dass die gesamte Website, gleich ist oder zumindest so eine gewisse Kontinuität über sämtliche Seiten hinweg, erreicht wird.

Und da, da finde ich, da, da merkt man ganz schön, also ich, ich kenne diesen Matt German nicht, aber das, das, da an der Stelle hatte ich so das Gefühl, da reden jetzt wirklich zwei Leute aneinander vorbei, weil dieser Matt German offensichtlich jemand ist, der noch nie irgendwie eine richtig große Website bearbeitet hat. Wohingegen, Mike Davis jemand ist, der wahrscheinlich noch nie eine richtig kleine Website hatte.

Weil also Mike, Mike sagt halt, das ist, das ist alles Quatsch, dass man da irgendwo eine Konsistenz mit hinkriegt, weil dann an wirklich großen und der geht ja immer so von der, von der Yahoo-Perspektive aus, also wo du wirklich zehn oder hunderttausende Seiten bearbeiten musst, kriegst du's einfach nicht hin, dass sich sämtliche Entwickler an eine Namenskonvention halten oder selbst wenn es eine Namenskonvention gibt und die ist noch so ausgefeilt, wird es immer wieder passieren, dass bestimmte Klassennamen oder IDs Auswirkungen auf Seiten haben, die du noch gar nicht getestet hast.

Also du schreibst irgendwas in dein CSS rein und testest das auf den Seiten, die du gerade bearbeitest und die haben aber Auswirkungen auf Seiten, an die du gar nicht gedacht hast und da macht's dann bumm. Und das ist halt eben bei, bei richtig komplexen Auftritten in der Tat 'n Problem.

Man muss sich ja bloß mal die Yahoo-Seiten angucken. Yahoo hat ja einen, einen Riesenpool von, von, von, von Seiten. Schon allein die Entwicklerseiten. Da gibt's ja nicht bloß ein Projekt, da gibt's ja viele. Und die sehen projektweise gleich aus, aber nicht-- Da folgen nicht alle samt einem, einem Corp, einem Corporate Design von Yahoo.

Und, natürlich ist das eben so, dass man sagt, bei G, wenn, wenn ich so 'ne gro, wenn ich so 'n umfangreichen Pool an Webseiten habe, normalerweise hat so 'ne Firma hat in den seltensten Fällen auch das Geld, so 'n Redesign für den kompletten Auftritt, in einem Abwasch dann umzusetzen. Das ist, das ist doch, das ist doch ein riesiger Koordinierungsaufwand, der da zustande kommt. Genau weil eben, bei so vielen Redakteuren sich, nicht alles bis ins Kleinste vereinheitlichen, lässt vermutlich.

Ja, Mike spricht ja auch. Entschuldigung?

Ja, du kannst. Ich bin durch.

Mike, Mike spricht ja auch bei der, beim Redesign der Yahoo, Homepage davon, dass da unter 'nem halben Jahr gar nichts geht.

Ne.

Und das ist also nur für Yahoo-Deckel, ne. Was noch dadrunter ist. Mit Ya, von Yahoo Finance bis zu Flickr, ist, da, da würdest du Jahre brauchen mit ich weiß nicht wie viel Entwicklern, um das zu halbwegs zu designen.

Auf der anderen Seite ist das natürlich ein Totschlaga-Argument, wenn ich sage, ne, bei so großen Seiten, ist das einfach, wäre das, ist das nicht hinkriegbar, ne. Und damit das, das generelle Argument, dass man eben so eine Konsistenz hinkriegen kann, wegzuwischen, ne. Weil wie gesagt, bei kleineren und schon bei, ist es durchaus möglich. Das zeigen ja auch viele Webseiten.

Ja, das ist auch das, was, was du Thomas sagst. Also von Anfang an wirklich sauber arbeiten, sich auf eine einheitliche Linie festlegen und dann ist die Wahrscheinlichkeit gering, wenn man das wirklich, stringent einhält, dass es am Ende leicht zu ändern wäre. Ja, aber...

Garantiert ganz trotzdem nicht.

Nee, natürlich nicht.

Ja, ja.

Gut. Nächster Punkt. Oh, mein Lieblingspunkt.

Kann ich drüber springen, mit Zündungen?

Better for SEO. Search Engine Optimization. Mhm.

CSS ist besser für Suchmaschinen.

Genau, also das, Fadenschein, also das Normalargument von CSS-Evangelisten ist, ich hab, nicht mehr so viele Tabellen, HTML-Kram, wo super viel Struktur drin steht, ohne dass ich an den Inhalt rankomme, sondern ich mache nur so ein, zwei Diffs auf. Da steht mein Text direkt drin. Ich hab, wirklich nur quasi den Text und ein paar Diffs ist viel weniger als diese Tabellenkram und deswegen kann Google das viel besser indexie-indexieren. Indexieren. Jetzt hab ich's.

Tom, willst du?

Grober, grober Unfug, weil, gerade Google, als Argument gar nicht zieht, weil sich Google einen feuchten Dreck um den Quelltext, also um die, um das HTML, um die Auszeichnung der Inhalte, kümmert, und eher mit brutaler Gewalt versucht, aus den Inhalten selber, irgendeinen Sinn rauszuziehen und das nicht über, über, semantisches Markup und so weiter,, versucht.

Ja. Würde ich auch behaupten. Wenn man sich, wenn man sich mal überlegt, wie viele Webseiten sind denn im Netz? So wie sie, wie die Webstandards es propagieren. Wenn Google darauf Rücksicht nehmen würde oder sich danach richten würde explizit, würden sie ja den, den, vierundneunzig oder fünfundneunzig Prozent des Webs nicht, nicht sauber indizieren können.

Und was ist mit Seiten, die vor zehn Jahren entwickelt wurden und, heute inhaltlich noch a, up to date sind, aber deswegen noch in Tabellen gesetzt sind, weil es gibt einfach keinen Grund, so 'ne Seite dann an der Stelle umzubauen, ne. Selbstverständlich kommt Google mit Tabellen ganz genauso klar.

Ja, also wüsste ich keinen Grund, warum Google an der Stelle,, den dieser alten Technik an der Stelle den Garaus machen sollte oder wollte, weil ich vermute mal, der, ein, ein, ein Großteil des Webs, ist noch so aufgebaut.

Ja, natürlich. Das ist ja, was, was Mike auch sagt. Wir haben ja dieses Chicken and Egg Pro-Problem. Also, was war zuerst da? Also You, auch, auch Google steht natürlich vor dem Problem, mit Schrottcode klarkommen zu müssen. Und die Realität im Web ist einfach Schrottcode. Sprich, sie, ignorieren einfach den Code und gehen nur auf die Inhalte. Zumal, also Suchmaschinenoptimierung ist ja eh, so 'ne Geschichte. Das ist ja keine exakte Wissenschaft.

Man, man ist da ja auf Beobachtung angewiesen und kann immer nur gucken, wenn ich das so mache, was passiert mit meinen Seiten dann in Google, und dann ändert Google den Algorithmus wieder. Und dann, dann muss ich irgendwie so zwei konkurrierende Test Cases bauen und die, die parallel ins Netz stellen und gucken, welche kommt dann in Google weiter nach oben und so weiter.

Und das sind üblicherweise nicht die Mechanismen, die die Webstandards-Evangelisten dann so propagieren, mit denen du so 'ne Seite nach oben schießen kannst. Das sind eben ganz, ganz viele andere, ganz böse Sachen teilweise, die man, wo man sich von Google nicht erwischen lassen soll, um 'ne Seite nach oben zu bringen.

Oder eben, was Georg schon sagte, wenn 'ne Seite zehn Jahre schon im Netz ist, dann ist die einfach, wird die von Google automatisch fast schon höher gewertet als irgendwas, was jetzt gerade seit zwei Wochen dran ist und auch keine Links hat und Ähnliches.

Ja. Man blendet bei der, man blendet bei der Geschichte dann ansonsten auch die, die Geschichte aus, ne, wenn man sagt, wir haben jetzt seit ein paar Jahren haben wir die Webstandards. Vorher hat man seit ein ganz paar Jahren hat man eben was anderes. Da hat man die Tabellen, da war das der Stand der Technik. Beim, beim, bei den Browsern jammern wir doch auch beim Web, die Webentwickler. Das hört man doch, geht doch gerade die Runde rum, ne.

Natürlich haben wir jetzt CSS2 und wir haben viele standardkonforme Browser. Wir haben aber auch den Internet Explorer 7, der schon vor acht Jahren da war und der es eben bis heute nicht gerafft hat und aber noch existiert. Und mit dem muss man eben klarkommen. Also man hat eben nicht nur den aktuellen Stand der Technik, sondern das ist eine viel größere Spanne dessen, die da für Suchmaschine, die kann sich nicht nur auf das Optimum stützen und trotzdem geht die Entwicklung ja weiter, ne.

Es ist ja nicht so, dass jemand sagt, HTML5 wär scheiße mit den zusätzlichen Algum, zusätzlichen Elementen, die auch für die Struktur einer Seite, jetzt wirklich semantisch gehaltvolle Elemente reinbringen. Und trotzdem heißt das nicht automatisch, dass mit Zeitpunkt X da jemand den Schalter umlegt und sagt, es geht jetzt nur noch so.

Schön wär's.

Natürlich, ne. Das, das würde auf allen Seiten wahrscheinlich, - -Positives bewirken. Es würde aber wahrscheinlich auch, mmm-

Viel Negatives, das würde zumindest

Das Positive in viel, viel Frust untergehen.

Genau, ja.

Ja, in einer idealen Welt. Dann kommt mein absolutes Lieblings-, Lieblingsunargument.

Die Nummer sieben: Accessibility.

Mhm. Schieß mal los.

Ja, das, das übliche Argument, dass, dass halt, CSS-Layouts für Accessibility, besser sind. Der wählt da aber dummerweise, genau die falschen Argumente, die alle auch wirklich einzeln widerlegbar sind und, und teilweise auch, na, wo er sich selber auch ein bisschen widerspricht. Also das, was er da sagt, dass, weiß ich, die Schrift skalierbar sein muss und so weiter, hat nichts mit, mit Layouttabelle zu tun. Also ich kann auch in einer Layouttabelle skalierbare Schrift reintun.

Das ist, das hat gar nichts mit dem, mit dem Seitengerüst zu tun. Und er, er geht dann ins Detail mit dem bösen IE sechs und, dass da eben Text nicht in Pixel definiert werden soll. Da frage ich mich: Was, was hat das bitte mit Layouttabellen zu tun?

Ich kann auch in, in 'ner Layouttabelle meinen Text in EM oder Prozenten oder was auch immer, rein, um, also da geht's eher wahrscheinlich ihm um, da, da hab wir vergessen aufzuschreiben, wahrscheinlich so um Old School Styling Techniken mit, mit Font Tags und ähnlichem. Und er geht dann noch weiter drauf, dass, dass, halt strukturierte Inhalte mit Überschriften und Absätzen und Listen und ich weiß nicht was alles ausgezeichnet werden können, kann ich in einer Layouttabelle genauso machen.

Also das, das ist, das ist kein Argument. Insofern, na ja.

Und auch da haben wir wieder das Problem wie bei den Browsern, wenn wir, wenn wir, Accessibility ganz streng genommen als die ganz spezifische Usability für Menschen mit Behinderungen betrachten und das tue ich einfach mal nun und nicht als, wo es auf dem Handy und auf dem Navi, funktionieren, sondern es geht ja wirklich nur um die Zugänglichkeit für, für Menschen, die drauf angewiesen sind, dass sie, dass das Web bestimmte Qualitäten erfüllt oder dass sie bestimmte Hilfsmittel einsetzen können, um das Web zu nutzen.

Und so das, das, das Posterchild, also das, das Lieblingsbeispiel, für Accessibility, weil's so herrlich einfach demonstrierbar ist, sind ja immer die Screenreader, mit denen sich Blinde, Seiten vorlesen lassen. Auch die kommen, weil die Realität im Netz eben leider eine andere ist als in der idealen Welt, ganz wunderbar mit Tabellenlayouts klar.

Vielleicht sollten wir dazu, sollte man als, als an verschiedenen Positivbeispielen mal, auch beschreiben, wo das Zugänglichkeitsproblem bei Tabellen herkommen kann. Dass wenn man sich beispielsweise, also für die Vorstellung ist es halt so, dass, jemand, der, 'ne Tabelle ist in Zeilen und Spalten aufgebaut- Und wird,

Zeilen- und spaltenweise vorgelesen. Also es geht von links oben nach rechts unten. Mhm. Und das Problem entsteht dann, wenn die visuelle Darstellung, die ich, die ich als sehender Nutzer auf dem Bildschirm sehe- Mhm. Na, g-, der anderen Hierarchie folgt. Wenn ich also spaltenweise und dann zeilenweise beispielsweise lese.

Wenn also eine Überschrift, für eine, beispielsweise für ein Formular, wenn ich sa-, wenn ich sage, ich habe das, das Label und das Input-Element, die sind in zwei Zellen derselben Zeile in einer Tabelle, dann werden die schon sauber vor, das Label vor der, vor, dem Input-Element vorgelesen. Dann passt das auch. Steht aber das Label in einer Zei, in einer Zeile drüber- Mhm. Und das, ne, wird’s also, vertikal strukturiert und, und ich pack das in ’ne Tabelle. Mhm.

Dann kommt der Screenreader unter Umständen durcheinander, weil ich nämlich, wenn ich jetzt mehrere Spalten habe, liest er mir drei Labels vor, ehe er zum ersten Input-Element kommt. Und dann wird’s problematisch. Ja, aber auch das, das Argument humpelt auch so ’n bisschen, weil, das, das sieht nur dann, wenn du in ’nem Screenreader diese Seite von oben bis unten vorlesen lässt.

Um ein, in ’nem Screenreader aber ein Formular zu bedienen, musst du, zumindest in den marktführenden Screenreadern in den Formularmodus gehen. Neuere gehen dann automatisch in den Formularmodus. Und wenn du dann deine Labels sauber als Labels getaggt hast, also wirklich das Label-Element verwendest- Ja.

Und die auch sauber verknüpft sind mit den Eingabefeldern, dann ist das so, weil nämlich dann der Screenreader die gesamten Strukturelemente außen rum, also die Layout-Tabelle komplett ignoriert und wirklich nur die Formularelemente vorliest. Und wenn die Labels sauber mit ihren Inputs verknüpft sind, ist halt egal, ob die per CSS... Anderes Gegenargument dagegen ist: Denselben Bockmist kannst du auch mit, mit CSS, mit zum Beispiel absoluter Positionierung machen.

Also indem du einfach wie wild in beliebiger Reihenfolge die Sachen in den Inhalt rein klatscht ins HTML, da eine komplett, komplett chaotische Struktur im Quelltext drin hast und per CSS die Sachen dann visuell an die richtige Stelle schiebst. Ja. Dann gibt’s alles, ne? Also wenn ich so ein klassisches Dreamweaver-Layout, ne?

Am besten noch irgendwie so als, hier diese, diese Funktion von Dreamweaver, wo ich mir so ’n Photoshop-Layout, dahinter lege und dann die Seite rüber und dann so Malen nach Zahlen, ne? Und dann am besten noch mit absoluter Positionierung, dann einfach beliebig dann irgendwie die Überschriften dahin ziehen und die Textblöcke dann irgendwie mach ich ganz am Schluss.

Ich mach jetzt erst mal die Überschriften und setz erst mal alle Überschriften da rein und positioniere die absolut und nehm dann die Textblöcke und schieb die dann zwischen die Überschriften. Dann hab ich die ja im Quelltext in der Reihenfolge, wie ich sie angelegt hab. Hab sie aber visuell eben in ’ner, in ’ner richtigen Lesereihenfolge. Der Screenreader liest aber dann die Reihenfolge im Quelltext vor, also kompletten Unsinn. Ja.

Also kann man, man kann auch mit CSS jede Menge Bockmist machen, den man mit Layout-Tabellen genauso machen könnte, ne? Mhm. Also insofern auch da dieses Argument Accessibility, Accessibility, das darum geht’s letztendlich, ja, ist, hinkt an der Stelle ganz gewaltig. Okay, kommen wir zu Punkt acht. Zumindest nicht sauber verargumentiert dann. Punkt acht, : Competitive Edge, Job Security heißt es da. Ja, heißer Punkt. Da, das, da ist tatsächlich was dran.

Also es ist einfach, na ja, Layout-Tabellen sind hoffentlich irgendwann mal tot. Und we-wer dann als einzige Kompetenz im Lebenslauf „Ich kann ganz tolle Layout-Tabellen machen“, stehen hat, der wird sicher ’n Nachteil haben. Sind wir noch da? Ja. Ah ja, okay. Mhm. Aber es ist natürlich richtig. Ich meine, man kann sich einerseits hinsetzen und sagen, : „Jungs, das hat seit zehn Jahren funktioniert.

Warum soll ich mich ändern?“, dann kann man eigentlich nur sagen: Dann bist du im falschen Medium, weil das Web, hat sich in den letzten zehn Jahren schon dreimal um sich selbst gedreht. Mhm. Mindestens, ja. Mhm. Und, und hat einfach, so viele neue Techniken un-un-und entwickelt, die es zu lernen und anzuwenden gilt, damit eben wir nicht bloß dasselbe visuelle Bild, was wir vor zehn Jahren schon hinkriegen...

Also man muss sich vor machen, mit, mit, mit ’n paar Grafiken, mit ’ner Tabelle und ’nem Spacer GIF hab ich vor, vor fünf, zehn, 15 Jahren genau dasselbe visuelle Layout hinbekommen wie jetzt. Ja. Ne? Ja, das ist aber auch kein, das ist, das ist- Aber das ist, das ist kein Argument. Ja. Also... Ja, und das ist auch nicht auf CSS versus Layout-Tabellen beschränkt. Also jemand, der eben nichts dann, dann, zulernen will, das, das gibt’s in jeder Branche.

Ne, also ich, ich hab ja in ’nem früheren Leben, auch mal Print gemacht. Auch da, hat sich, aber hallo, ganz viel geändert. Und also auch da gab’s Leute, die, halt, noch richtig klassischen Bleisatz gelernt haben und dann kam Fotosatz dazu und dann kamen irgendwann die ersten,, Commodores und, und Macs dazu, und, und, und, Pagemaker 1.0 und so weiter.

Also da, auch da hat sich alle drei Jahre was geändert und auch da hat sich die Entwicklung mittlerweile, beschleunigt bis hin zum, zum Digitaldruck und ich weiß nicht was alles. Und auch da gibt es natürlich Leute, die, irgendwie dem Bleisatz noch nachtrauern und sagen- Ja. Also damals alles viel besser. Also das ist nichts, nichts, was auf, auf CSS oder auf, auf Webentwicklung beschränkt ist. Also ich fand ’n Bleisatz schon cool, muss ich sagen. Ja, gut, klar.

Aber vielleicht kann man’s so sagen, sagen wir mal so: Natürlich ist es immer noch möglich, damit zu arbeiten, aber ich würde vermuten, dass man als Entwickler, der sich eben auf dem Niveau nach wie vor bewegt oder da nicht, nicht, nicht sich davon wegbewegt, -

Sowohl auch jetzt schon als auch, in, in, in Zukunft ganz gewiss nicht mehr die spannenden Projekte entwickeln wird.

Das, das-

Ich krieg, ich krieg eben natürlich kriege ich, jemanden davon überzeugt, der vom Web keine Ahnung hat, dass ich eben, wenn ich eben der Enkelsohn von meinem Großvater bin, der eine Firma hat, dass ich dem, in meinem Hobby die Seite zusammenbauen kann und er dafür keinen, Profi engagieren muss, ne. Aber die Frage ist, das, das ist der Bereich, wenn ich einen Kunden...

Ich will sagen, ich zieh ihn übern Tisch, aber letzten Endes der weiß, der, der Kunde weiß an der Stelle gar nicht, wo, worauf's ankommt und, dem, der kriegt das Problem, was da unter Umständen entstehen könnte eben, davon hat er auch keine Ahnung. Und in dem Bereich, wenn's eben über die normale, eigene private Homepage mit drei Seiten, wer bin ich und, was mache ich und wo ist meine Kontaktadresse?

Wenn's darüber hinausgeht, dann ist es eigentlich, dann gehört's zum guten Ton, dass man, dass, dass man mit Standards arbeitet.

Eigentlich schon.

Und das ist eben, und das ist der Punkt, wo man sagt, ab bis zu einer gewissen Professionalitätsgrenze oder bis zum gewissen Bereich mag das alles funktionieren, dass man arbeiten kann, wie man will. Aber dann fällt irgendwo relativ weit unten und diese Schwelle wird immer weiter nach unten wandern. Der Hammer, wo man sagt, ohne einen gewissen Qualitätsstandard geht's einfach nicht.

Du kommst ja dann sehr schnell auch in Regionen, wo es immer noch irgendwer noch billiger macht. Also das ist einfach-

Immer.

Wirklich professionelle Webentwickler. Also klar, es, es muss auch solche Wegwerfseiten für die Dönerbude nebenan geben. Die soll in Gottes Namen irgendwer machen, aber derjenige darf dann nicht den Anspruch haben, mit den Fähigkeiten, die er da hat, an den Tag gelegt hat, an, an die richtig fetten Jobs, die dann auch entsprechend Spaß machen.

Ganz genau, das meine ich.

Das ist ja auch die Argumentation, in den Mike da teilweise eingeht. Und da muss man auch wirklich zwischen den Zeilen lesen, um, um herausfinden zu können, was er damit meint. Weil eigentlich sagt er, dass Tabellenlayouts wesentlich einfacher zu lernen sind. Und, wenn man jetzt CSS macht, ist es eben nicht trivial. Also die ganzen CSS-Hacks und Workarounds, sagt er, sind super, super, super komplex und da muss man schon richtig Ahnung haben.

Und, wenn ich mir jetzt ausmale, ich hab 'ne Agentur mit Leuten, die halt jetzt Webstandards machen und, die kalkulieren aber fünfzehntausend für 'ne Webseite und ich hab auf der anderen Seite jemanden, der ist mit zwei Leuten und macht nur HTML-Tabellenlayouts für 'n Tausender.

Klar, wenn ich da jetzt nicht die richtig argumentieren kann oder komme mit der Qualitatifschiene und qualitatives Handwerk und so, dann kann am Ende vielleicht nur die kleine Klitsche gewinnen, die Tabellenlayouts macht. Das ist eben die Krux an der Geschichte. Es ist einfacher, zu handeln, aber wie gesagt, ob's jetzt... Schwierig, ja. Und das ist genau die Krux, warum es eben diesen Artikel von Mike gibt. Nachdenken über diese Argumente, ja.

Weil eigentlich ja, Tabellenlayouts sind eben mal einfacher zu machen. Da kannst du auch 'n Praktikanten ransetzen, dem erklärst du das ein bisschen, der macht das, ne und kriegt's vielleicht sauberer hin, als wenn du den jetzt zwar, in Lehrgang für CSS schickst.

Da hat er, da hat er leider recht.

Ja, leider ja. Das ist, ja.

CSS ist nicht ohne. Also das eigentliche Problem ist ja, dass das W3C uns ja quasi per, Empfehlung oder per Standard, sehr viele Fähigkeiten von Tabellenlayouts, die sie nun mal haben, weggenommen hat, indem sie gesagt haben: "Ihr dürft das jetzt nicht mehr machen, Tabellenlayouts sind bäbä", aber sie haben uns nicht gleichzeitig mit CSS die Werkzeuge in die Hand gegeben, die 'ne, 'ne vernünftige Alternative darstellen würden.

Also es, es gibt wirklich tatsächlich, einige Dinge, die man mit CSS nur mit einem irren Aufwand, hinkriegt, die mit 'ner Layouttabelle tatsächlich. Und das ist wirklich 'n schmutziges, das, das schmutzige Geheimnis der, der Webstandard-Szene. Mit Tabellenlayouts wäre es tatsächlich einfacher.

Definitiv, ja. Also alleine schon, wenn ich mir jetzt drei Spalten nebeneinander hinklatsche, die einem dieselbe Höhe haben sollen.

Das, das zum Beispiel, ne. Also, -

Oder noch, noch 'n einfacheres Beispiel. T-treff, kommt mir irgendwie immer wieder unter den Hut: Die Leute können ein sonst wie komplexes Layout mit CSS-Tabellen,, nie mit CSS, mit, mit CSS erstellt haben oder sich irgendwo hergeholt haben. Sie wollen an der Stelle jetzt Inhalte eingeben und wollen auf gleicher Höhe ein Element links und ein Element rechts haben.

Mhm. Oh ja.

Die Standardantwort ist, die Standardantwort ist: Tabelle. Ne. Also was ist Float? Warum jetzt Floaten? Wie kompliz, wie, ne, wie schnell werden Floats kompliziert, wenn ich flexibles Layout, Rundungsfehler, die Dinger brechen um, die, die rutschen untereinander. Ja, erklär das mal jemandem. Dass das prinzipiell schon funktioniert und dass es die Lösung dafür auch gibt, aber die liegen eben nie aufm Tisch.

Das ist eben der große Denkfehler. Also Float war ja eigentlich nie dafür gedacht, komplexe Layouts zu bauen. Das war ja wirklich nur so 'n Mittel, um, Bilder irgendwie nach rechts und Text fließt drum rum zu kriegen.

Ja. Wobei es ist, ist die Frage, es ist richtig, sie sind nicht, sie sind in, in dem Kontext von CSS nicht dafür gedacht gewesen. Aber, es gibt durchaus genau so 'ne Ansätze, schon, schon viel, viel länger, um Benutzeroberflächen zu generieren. Auch wenn's jetzt, wenn's jetzt einf, oder billig klingen mag. Ich hab, früher für 'n Amiga programmiert, ne.

Der hatte schon immer 'ne recht vernünftige Grafik, da ging's schon immer, das ganze Betriebssystem hatte skalierbare Schriften, und dort gab's grundsätzlich, gab's Layoutbibliotheken, wo du wirklich, wo, wo du nix fest definiert hast, sondern du hast immer nur Bereiche unterteilt in ho-horizontal oder vertikal und hast gesagt, der Bereich ist linksbündig, rechtsbündig-, und das war's. Also das war schon diese Technik.

Floaten nach links, Floaten nach rechts, mehr gab's gar nicht und dann hast du die entstehenden Unterbereiche wieder hierarchisch unterteilt. Und auf diese Art und Weise dazu eben zu sagen, du gibst 'ne bestimmte Schriftgröße, m-mit, mit der legst du dein, dein, dein Layout an, aber prinzipiell kann der Nutzer machen, was er will und kann das auch aufblasen, hat das wunderbar funktioniert.

Es ist nur eben in der Tiefe gar nicht so in, in CSS reingerutscht, sondern in CSS war's wirklich einfach nur so wie du's sagst: Mal 'n Bild links im Text positionieren, mal rechts. Für so was war's gedacht.

Na ja, also im Prinzip, im Prinzip so wie's, wie's,, Quark und InDesign auch handhaben. Du kannst halt 'n Bild entweder im Text aufhängen und das, das fließt dann mit oder es ist halt irgendwo statisch auf der Seite positioniert und fließt halt nicht mit. Sind, sind halt ähnliche Denkmodelle. Aber, aber ein wirklich, sauberes Modell. Ich mein, gut, das gibt's, aber, da gibt's ja diesen einen Browser, der das alles nicht unterstützt.

Also es würde ja funktionieren, wenn, wenn, dann sich die Herren Browserhersteller mal drauf einigen würden, jetzt, letztes Jahr CSS3 zu implementieren. Das, das fehlt halt leider noch.

Ja, mhm.

Insofern sind die Mittel halt, die wir, die wir zur Verfügung stehen haben, wirk... nicht wirklich in der Praxis für komplette Layouts umsetzbar. Wir müssen nach wie vor, missbrauchen letztendlich, Sa..., Dinge, wofür sie eigentlich nicht gedacht war.

Jetzt kommen wir zu Punkt neun: Quick Website Wide Updates. Das hatten wir eigentlich schon. Im Prinzip, weil es nämlich darum geht, dass Maik sagt: „Wenn ich jetzt 'ne Änderung in CSS mache, kann ich die zwar, an einer Stelle machen und ich hab überall die Änderung.“, er argumentiert aber, dass man, mit einer Webseite, also Tabellenlayouts, die man jetzt wirklich gut durchplant, dass man das da eben, so schnell machen kann.

Würd ich mal stark bezweifeln an sich dessen, dass wir auch in der Agentur noch, zwei Tabellenseiten haben von, von großen Hotels, wo die, wo du jetzt mal nicht schnell 'n neues machen kannst, wo wir mit Tabellenlayouts arbeiten müssen. Und da Änderungen zu machen, das ist schon 'ne andere Geschichte. Aber wie gesagt, das haben wir eigentlich schon abgefrühstückt in unseren vorherigen Argumentationen.

Na, 'n bisschen was kann man noch dazu sagen. Wo das, das Problem wird schon wirksam und zu gewissen Teilen, würd ich das auch, sagen, dass es eben wirklich so ist, dass Tabellen, unter Umständen schon an der Stelle mehr Aufwand bedeuten. Denn das Problem bei Tabellen im Gegensatz zu CSS ist, bei CSS kann ich positionieren, ne. Ich kann sagen, Container nach links, Container nach rechts. Ich kann, also ich kann floaten, ich kann absolut positionieren.

Ich kann sie, ich kann verschiedene Container unabhängig von den restlichen Elementen des Sei..., des, des, des, der Seite irgendwo hin positionieren. Und demzufolge kann ich sie auch da wieder wegnehmen und wa-, was anderes damit machen. Und das geht bei Tabellen in der Regel nicht, sondern ich, ich, ich definiere eine Anzahl von, von Zeilen, von Zellen pro Zeile. Und wenn ich eine Zelle da rausnehme-

Bricht alles wieder.

Dann muss ich sie, dann muss ich sie wohl anders wieder einfügen und dann ist das so 'n System. Es gibt doch diese schönen Spielchen hier, wo so 'n Quadrat mit, mit sechs..., mit 25, Feldern, 24 sind belegt und dann kann man so, einzelne Felder immer hin und her schieben und immer eins frei får.

Mhm. Ja.

Genau das, genau das passiert. Also ich muss immer nur 'ne Zelle raus und automatisch, blö, blö, blö, blö, blö, ist 'n Rattenschwanz hinterher, den ich korrigieren muss. Das heißt, ich muss mindestens die Nachbarzellen anfassen und sagen, diese Zeile hat jetzt eine Zelle weniger.

Seine Argumentation ist, dahingehend auch sehr lächerlich, die von Maik. Denn auch wenn ich die Tabellenlayouts richtig gut durchplane und mir richtig 'n Kopf mache am Anfang, dann schau ich ein Jahr später drauf und muss 'n Update machen und sehe ein Tabellenwust, wo sich niemand zurechtfindet.

Und da jetzt mal wirklich diese Spalte rauszufinden, grade wenn du mit verschachtelten Tabellen arbeitest, da sitzt du alleine schon zehn bis 15 Minuten, bis du die Stelle mal gefunden hast durch Try and Error, indem du irgendwelche Buchstaben reinsetzt, um zu gucken: Wo ist denn das Ding jetzt? Also das ist nicht einfach.

Ja, das ist, das ist in der Tat 'n, 'n Argument, das zieht. Ja, keine Frage.

Ja, und das ist auch ein Argument, wenn ich jetzt noch mal in Richtung CSS gehen sa. Das ist auch das, was grade bei, bei 'ner Vielzahl von, von CSS-Frameworks, bei eben Blueprint und 960 GS, wo im Prinz... Die sind haargenau so aufgebaut, diese idealen Grids. Dort kannst du im Prinzip, das, Div, mit der Klasse für das entsprechende Brit, Grid durch, durch TD ersetzen.

Weil die genauso ohne, da gibt's keine hierarchische Gliederung, keine Schachtelung, dass du irgendwo ineinander Elemente verschachtelst und damit wieder irgendwo unabhängig kommst, sondern das geht wieder genauso links oben los und endet rechts unten. Und das ist genau wie: Ich nehm ein Element raus, der Rest rutscht nach. Ne? Das ist auch der große Kritik. Jens hat das, hat das in 'nem, Jens Gocha hat das in 'nem Artikel vor 'nem halben Jahr mal, recht schön aufgedröselt. Ne?

Und auch da müssen wir wieder gucken:, geht da CSS grade in die richtige Richtung, ne? Frameworks sind 'ne schöne Sache. Braucht ihr mich ja bloß fragen, ich, es erzähl's ja jedem.

Aber man muss auch gucken, was da für 'ne Technik dahinter steht, ob die wirklich die richtige ist. Ne? Und so schön Grids sind, aber wenn man sich denn, sich vollständig darauf einlässt, hat man Schwierigkeiten, genau dieses Problem dann wirklich zu umgehen. Weil es eben so nah verwandt, dieser, dieser Tabellenprogrammierweise ist. Es geht anders, ohne Zweifel.

Aber um es anders umzusetzen, um genau in diese Fallstricke nicht reinzukommen, - Brauchst du als, als Entwickler, musst du deutlich mehr, mehr Hirnschmalz reinstecken, um dort 'ne richtig funktionierende Struktur für so 'ne Seite dann zu finden. Ne? Ja. Da ist wieder die Frage: W-was leistet man, w-wie sieht das Idealbild aus und was leistet man sich, im Alltag? Wie weit geht man davon weg, weil man's einfacher haben will?

Dann kommt der, der Punkt, wo man eben, wo man eben wirklich sich das Argument auch gefallen lassen muss, dass man nicht besser ist mit CSS als mit dem, was man früher mit Tabellen gemacht hat.

Jetzt hab ich den Faden verloren. Sind wir bei neun oder bei zehn?

Wir sind bei neun und kommen jetzt zu zehn, und zwar: easier for teams to maintain.

Ah, schwierig. Auch ausgesprochen schwierig. Also grade so die Erfahrung in großen Teams ist, dass Style Sheets da schon die Tendenz haben, aus dem Ufer zu laufen, wenn nicht irgendwer quasi the master of the Style Sheet ist und irgendwem im Team den Hut aufsetzt und nur der bestimmt, was in so 'n Style Sheet noch mit rein darf.

Wenn also jeder, ich will noch nicht mal von Redakteuren sprechen, sondern auch, auch nur 'ne gewisse Anzahl von Entwicklern da irgendwie beliebig, beliebig im Style Sheet rumfummeln darf, dann, dann ist das hinterher ein, ein, ein Wartungsalbtraum.

Genau, kann ich vielleicht mal k-, direkt erklären: Bei Sevenload war's ja so, dass wir die, komplette Videoplattform auf 'm weißen Blatt Papier wirklich neu angefangen haben. Und, ich war der Herr sozusagen über das CSS. Und, das war genau nämlich das Thema.

Also wenn ich wirklich das CSS aufbaue und jeder dürfte im CSS rumfummeln, wie ihn beliebt, dann bringt das herzlich wenig, weil irgend 'ne Anweisung, die einer nicht so ganz verstanden hat, die überschreibt ganz andere Sachen und das haut dir später alles um die Ohren. Und schlussendlich müsste ich dann dafür geradestehen, dass es nicht funktioniert und das Ganze dann wieder fixen. Also das wäre ein unglaublich großes Fass, was irgendwann mal überlaufen würde.

Deswegen hab ich auch von ganz Anfang an schon gesagt, um den Entwicklern auch noch die Frei-, den Freiraum zu geben, noch mal eben CSS Styles selber nachzuschieben, bevor sie mich irgendwie drum bitten, da was zu machen. Das ist ja auch keine Lösung. Hab ich grundsätzlich erst mal alle Melde, vorgestylt und gemacht und das CSS festgelegt, den Entwicklern aber eine, Development CSS zur Verfügung gestellt.

Das sa-sah eben so aus, dass, die Development CSS zum Schluss als Letztes geladen wurde und sie dort ihre Sachen eintragen konnten. Dann war die Teamanweisung: Wenn ihr das getan habt und ihr habt das Ding ins SVM gepackt, dann bitte gebt mir Bescheid, damit ich das kontrollieren kann. Und ich hab mir das ganze Ding angeschaut und habe dieses CSS dann übernommen in die richtigen Style Sheets an der Stelle, wo's reingehört.

Und anders kann es auch nicht laufen, weil sonst haut es dir echt um die Ohren.

Mhm. Ja, guter Ansatz.

Wobei das hier, an der Stelle dann nicht mehr um CSS oder Ha-, oder Tabellen geht, ne.

Nee, nee, das ist ja auch das, was Thomas sagte. Also selbst CSS-

Nee, nee, auch, also, also das Argument dann hier von, von, von Mike Davis passt an der Stelle auch nicht. Es wird, es wird nicht pflegeleichter, wenn ich 'ne Tabelle nehme und sage: „Ich hau jetzt natürlich, ich kann da nichts mehr überschreiben, ich hab allen, allen Blödsinn dann in dem HTML stehen", ne. Das macht's aber nicht weniger, nicht übersichtlicher, sondern präs-, d-d, das Chaos sieht nur anders aus.

Ja, hast du recht.

Ja. Also es ist weder ein Argument pro noch contra CSS, sondern eher eigentlich für, redet miteinander und, und, und, legt eure Abläufe fest.

Ganz genau.

Das hat nix mit Layout-Tabellen zu tun.

Da hatte ich auch mal 'n Artikel bei den Web Kreuz geschrieben, wo's genau darum ging: redet miteinander, findet Standards und, bevor ihr mit der Arbeit anfangt, ja.

Mhm, mhm. Ja, das, das ist auch so, ne, dass, dass man also, wenn man dann mal nur fünf Minuten statt zwei Minuten nachdenkt, hinterher dann aber irgendwie paar Stunden oder Tage Arbeit, damit einspart.

Mhm. Gut, nächster Punkt: increased usability.

Keine Ahnung, was das soll.

Ich wüsste nicht, was, was das, was das, sagen wir so, wenn wir's mal auf das Layout runterbrechen, so viel Einfluss hat das Layout selber dann wirklich, denk ich mal, nicht, dass-

Ja, also er argumentiert's ja jetzt mit, dass, dass man da ganz einfach ein Fenster als Sheet machen kann, ja. Ja gut, bei einem einigermaßen komplexen Webauftritt hast du ja sowieso, irgendein System im Hintergrund, was dir diese, diese Printansicht in irgendeiner Form generiert, sei es jetzt, per CSS umgeschaltet oder, -

Oder vom System direkt, ja.

Ob System direkt.

Man das generiert.

Ja, und ich kann auch, aus 'ner, aus 'ner statischen HTML mit Layout-Tabellen und Font-Tag-Seite per CSS 'n Print-Layout machen und, und 'n bisschen JavaScript noch reinstreuen und dann funktioniert das auch mit Layout-Tabellen. Also auch das ist, jetzt nicht unbedingt so das, das Killerargument.

Ja. Ja, lassen wir. Mehr brauchen wir da, glaub ich, nicht so dazu sagen.

Nee.

More complex layouts and designs.

Nummer zwölf.

Da musst du selber, da musst du erst mal selber lesen, Nummer zwölf. Oder ihr sagt mal was dazu. Genau.

Ach so, ich les grade, ja. Er sagt also, gra-, mit Tabellen war's also kein Problem, flexible Layouts zu erstellen und er führt ja als Erstes an, wie lange das Dauer, doch gedauert hat, ehe beispielsweise damals, ich glaub, bei A List Apart war's, dieser, dieser Artikel The Holy Grail rauskam. Also wie lange hat's überhaupt gedauert, ehe man mit CSS wieder so halbwegs den Stand erreicht hatte von dem, was man von, von, von einfachen Komplexität einer, einer Seite machen kann.

Da redet man wirklich nur von einfachen Spaltenlayouts im Moment noch. Bis die Dinger wieder robust waren.

Mhm. Da ist was dran, ja. Also es gab ja wirklich diese Zeit, wo, so die, die, Webstandardistas schon nach draußen gegangen sind und gesagt haben, Layout-Tabellen sind bäbä und dürft ihr jetzt nicht mehr benutzen, aber, die, die, die Le-- CSS-Layouts, die damals zur Verfügung standen, noch nicht wirklich stabil waren oder noch nicht so durchgetestet waren. Und damals eben sehr viel CSS Lou-- Layouts noch mit, mit, Positionierung, und Ähnlichem funktioniert haben.

Ja, mhm.

Und dass das, trotzdem bei der kleinsten Änderung dann,, die damaligen Browser einfach damit komplett überfordert waren. Also da, da gabs schon so 'ne, so 'ne Zeit, wo, allen klar, allen, aber sehr vielen klar war, dass Layout-Tabellen jetzt nicht, mehr so der Stand der Dinge sind, aber die Alternative war noch nicht da. Das ist, aber ich denke, über den Punkt sind wir dann wirklich jetzt hinaus.

Also, ich denk mal, jegliches Layout, was man sich nur irgendwie ausdenken kann, geht auch irgendwie mit, mit, mit CSS. Die Frage ist halt nach dem Aufwand. Das hatten wir ja schon bei den-

Selbst da bin ich mittlerweile eigentlich der Meinung, dass es, in vielen Fällen, wenn man sich, wenn man nicht n-n-n total,, schwachsinnige Regelungen da kommt und, und, und seinem Kunden, das, der glaubt, der da sagt: "Ich will aber- -, das so und so haben, weil ich eben in Word von mir aus das so gestalten könnte", ne. Dann geht's in CSS nicht nur irgendwie, sondern dann geht es mittlerweile eigentlich, wenn man die Technik im Griff hat,, sehr, sehr gut.

So dass man wirklich dieses, dieses, Ei, dass ich sage, man, man braucht, es ist wa, es ist, man sagt nicht, es ist, es ist nicht unbedingt besser, ne. Besser wärs gewesen, wenns von Anfang an funktioniert hätte.

Und das hats eben nicht.

Das hats nicht, ja.

Aber es ist auch so mittlerweile, es funktioniert mittlerweile so gut und hat sich so gut entwickelt, dass man sagt: Heute brauch ich auch den alten Schrott nicht mehr, weil der ist auch nicht besser. Ne.

Mhm. Ja, Spacer GIFs. Verwendet die, verwendet die noch jemand?

Ich hab schon Ewigkeits nicht mehr gesehen.

Ja, also, ach, mag, mag ja sein, dass die von manchen Tools noch, noch, also Dreamweaver machts ganz sicher noch. Und es gibt sicher auch, aber da sind wir wieder in dem Bereich, Wegwerfseiten, ne. Also auf, auf, auf Wegwerfseiten für den Friseur oder die, die Pommesbude, klar, wirds sie sicher noch in, in Mengen geben. Aber ich glaub, bei, bei einigermaßen großen Auftritten oder so wird man die kaum noch finden.

Mhm. Aber auch hier Vorsicht beim Lesen von Mikes Artikel. Er sagt nämlich, dass Tabellenlayoute nicht unbedingt meinen, dass da Spacer GIFs drin sein müssen. Und, er zitiert hier den Jeffrey Zeldman, der, 'n Buch geschrieben hat Designing with Web Standards, indem er da sein erstes, eins der ersten Bücher, wo er eben Tabellenlayouts vorgestellt hat, wie man das richtig macht, aber allerdings ohne Spacer GIFs. Also Vorsicht beim Lesen. Deswegen wirklich zu Ende lesen. Komisches Argument, ja.

Na ja gut, und es ist ja, also er, er, das ist die, die erste

Web Standards von Zeldman, die ist, ist neun Jahre oder wann ist die das erste Mal rausgekommen? Weiß ich gar nicht. Die ist ja, die ist ja uralt. Also insofern, wenn ichs sehe, gerade 2003, ist es nicht noch.

Wahrscheinlich, neu aufgelegt oder so.

Ja. Ja. Also es ist auf jeden Fall, das ist ja, das ist ja eher so was fürs Antiquariat eigentlich, das Buch. Insofern, ist auch so 'n, so 'n, so 'n Unargument eigentlich.

Genau. Aber wie gesagt, also Mike gings da darum, diese Argumente von diesen, selbsternannten CSS-Evangelisten eben- -bisschen auseinanderzunehmen und zu sagen:, überleg doch mal, was hast du hier eigentlich erzählt? Und stimmt das denn wirklich? Hast du mal wirklich dir Gedanken gemacht, das, nachzurechnen? Und, das ist ihm gelungen, ja.

Auch, auch wenn durch komische Methoden und er sich Argumente an Haaren herbeigezogen hat, die nicht konsistent sind oder, wo er auf der einen Seite das und das erzählt, aber schlussendlich unter dem Strich, macht er auf was aufmerksam, wo auch wir kurz überlegen mussten und, denken: Ja, Mensch, eigentlich in St-Teilen hat er recht, ja. Also auch wenn das jetzt kein Pro-Argument für Tabellen ist, aber grundsätzlich, wenn ich so argumentiere, dann muss das auch so sein.

Mhm. Das sagt er auch ganz deutlich dann jetzt in dem Fazit, ne, dass es ihm wirklich nur darum geht: "Well, I find the level of discourse about CSS layouts low." Ihm gehts einfach nur darum, dass die, die Art, wie es im Augenblick argumentiert wird, einfach, vom, vom Niveau her einfach zu niedrig angesiedelt ist.

Mhm, mhm.

Zu viel, sich, sich so auf die, auf die Schulter klopfen und sich selbst gratulieren, wie to-- wie cool und wie toll man doch ist und so. Und aber die, die wirklich echten Argumente, fehlen noch. Oder es wird halt nicht richtig argumentiert oder an den falschen Stellen.

Es ist ja auch immer dasselbe, was, es sind immer dieselben Argumente, die auf den Tisch kommen und so langsam, muss ich jetzt, nachdem ich diesen Artikel gelesen habe, auch feststellen, dass viele haben das jetzt gelernt, wissen jetzt inzwischen, was, CSS-Layout sind und wie sie funktionieren und, und plappern diese Argumente aus dem Kopf einfach nur noch nach, ohne sich wirklich Gedanken darüber zu machen, was steckt denn technisch überhaupt dahinter.

Ja, und die Argumente können aber eigentlich nicht so überzeugend sein, also so, so, so zwingend überzeugend sein, weil wenn sie so gut wären, dann hätt-- wäre der Rest des Webs ja auch schon, zum Besseren bekehrt worden. Aber da dem nicht so ist, fehlen halt trotzdem irgendwo noch die, die, die richtigen Pro-CSS-Argumente.

Oder zumindest erreicht man mit, mit der Art, so wie der das mit seinen dreizehn Punkten und keine Spacer GIFs benutzen und, ist alles böse, böse, erreicht man nicht die Leute, die nach wie vor tagtäglich Mords ins Netz stellen.

Ja, ja.

Da fehlen einfach noch bessere Argumente.

Das ist ja auch die Quintessenz, was er am Ende rauswirft, in seinem Artikel, dass es eben-- ich glaube nicht, dass es ihm darum geht, das eine oder andere jetzt zu verteufeln oder wieder in den Dreck zu ziehen, sondern dieses, dieses heroische besser, ne. Besser, weiter, schneller. Und das passt eben nie, weil w-wir haben's ja jetzt selber gesehen. Wir haben dreizehn Punkte alle durchdiskutiert und, so ziemlich bei jedem Punkt findest du was, wo du sagst: „Recht hat er schon." Ne?

Vielleicht nie im Großen und Ganzen, aber in, in gewissen Punkten, du findest immer irgendwo was, wo du's eben nicht belegen kannst oder wo du, wo du sagen kannst, Tabellen natürlich hier und da geht's schneller, also ist einfacher, es ist weniger kompliziert und sonst was. Und deswegen kommt er ja auch zum Schluss. Es ist einfach im Moment was anderes.

Es ist eine andere Art zu gestalten und das ist aber, das ist die Weiterentwicklung, die das Netz in der, in den letzten Jahren vollzogen hat, dass man eben sagt, selbst wenn's momentan vielleicht auch seine Vorteile noch nicht vollständig ausspielen kann, ne, weil eben auch die ganzen verschiedenen Browser, mit dieser variierenden CSS-Unterstützung und mit den ganzen Bugs dafür sorgen, dass du, auch wenn du mit CSS gestaltest, immer wieder Kompromisse machen musst, ne.

Du kannst ja noch nicht mal alle CSS2-Selektoren benutzen.

Nee.

Ne? Das heißt, du, du, du kannst 'n Teil der Vorteile ja überhaupt nicht nutzen im Moment. Das ist also immer wieder irgendwo, man muss sich auf Kompromisse einlassen und da kann man genauso argumentieren: Ja, weil es eben diese Browser alle noch gibt, kann ich auch CSS gar nicht so benutzen, wie's eigentlich möglich wäre.

Was jetzt kein Pro-Argument für Tabellen ist, sondern ganz einfach nur 'n Missstand aufse, aufdeckt, dass CSS eben nicht perfekt ist.

Das ist der Unterschied zwischen Gummibärchenland und Realität, ne. Wo man einfach sagt, man muss damit leben und dass es eben die Vergangenheit gibt und auch CSS ist noch nicht so alt. Die anderen, die alten Browser sind auch nicht so, noch nicht so lange tot oder sind noch nicht mal richtig im Sterben.

Andere Geschichte, 'tschuldigung.

Ja, da-damit muss man sich einfach arrangieren. Ne, und deswegen ist es eben bei diesen, wenn ich so heroisch das rausblase, dass das alles so toll ist, automatisch und man sieht's an dem Artikel, macht man sich eben angreifbar und dann muss man eben wirklich die Argumente finden, die wirklich auch langfristig ziehen. Und da muss man vielleicht auch mal 'n Schritt nach vorne gucken.

Ja. Ja, ich denke, dann haben wir, zur Genüge diesen, diesen Artikel auseinandergenommen. Schlussendlich bleibt festzuhalten, dass auch genau das ist, worüber wir uns neulzeitlich zum Beispiel über 'n Spiegel aufregen, wenn die, versuchen, technische Artikel zu schreiben. Man sollte genug und genau recherchieren, und wirklich mal hinterfragen, ob zum Beispiel jetzt,, nee, diese Attentätergeschichte bring ich jetzt nicht.

Da gab's ja jetzt auch was, wo die Journalisten jetzt mal was rausposaunt haben, was nicht ist. Das gilt natürlich auch für Blogger. Das gilt natürlich auch für CSS-Evangelisten. Überlegt euch wirklich, ob das, was ihr erzählt, wirklich stimmt und beziehungsweise macht euch Gedanken darüber. Ich unterstelle mal Maik, dass das sein, sein Wunsch war- -, mit der Aussage.

Zumindest hab ich es so m-mit zwei Tagen Verspätung, also nach zwei Tagen kann ich das behaupten, dass ich den Artikel so empfunden habe. Das musste bei mir auch erst mal sacken. Aber schlussendlich, wie gesagt, okay.

Beteiligt euch an der Diskussion im Blog auf Technikwürze.de. Unsere Hörer kommen zu Wort.

Kommen wir noch zu einer Sache kurz zum Schluss. Wir sind ja auch deutlich über der Zeit, haben fast anderthalb Stunden. Eine Sache möchte ich unbedingt noch loswerden. Es gab ja in der letzten Folge endlich nach, langer Zeit wieder 'ne neue Folge und es gab komplett 'n Redesign. Und, da möchte ich an dieser Stelle mal allen danken, wirklich allen danken. Wir hatten, als Team super großen Zuspruch, allein dass wir 'n Redesign gemacht haben. Und es gab auch viele, viele Kommentare.

Also wirklich viele E-Mails kamen bei mir an. Es gab sehr viele Tweets über Twitter. Kommentare hatte ich gestern gezählt, hatten wir vierzig alleine auf der Seite, die um das Redesign gingen und 'n bisschen auch über die neuen Folgen. Ihr habt uns wirklich viel Feedback gegeben. Bitte nicht aufhören damit, denn wir entwickeln noch 'n bisschen was weiter. Möchte noch mal kurz erzählen, was wir so insgesamt, getan haben, was auf euer Feedback direkt zurü-zurückgreift.

Das waren die Metainformationen im Titel. Da stand ja, vierzig Kommentare, ein Trackback, zwei Moderatoren. Das war zum Beispiel nicht verlinkt. Das haben wir inzwischen verlinkt. Was wir auch endlich haben, ist die Querverlinkung der Moderatoren, denn auf jeder Seite war ja zu sehen, welcher Moderator, rechts oben diese kleine Box, war da und wenn ihr darauf geklickt habt, kamt ihr zur Teamseite. Aber jQuery hat eben nicht dafür gesorgt, dass euch der Moderator angezeigt wird.

Was auch nicht funktioniert hatte, war, wenn ihr jetzt 'n Moderator habt und ihr wollt diesen Link weitergeben, wie zum Beispiel, dass, alle kleinen Mädchen, die jetzt zuhören oder die großen erwachsenen Frauen, die finden jetzt, Dirk Jesses Stimme so sexy und wollen jetzt, noch mal gucken, in welchen Folgen hat er teilgenommen. All das ist jetzt zusammengefasst möglich. Querverlinkung funktioniert und, das, funktioniert auf jeden Fall super gut. Die Seiten haben wir validiert.

Da ist es in der Entwicklung mal eben passiert, dass da 'n Span gefehlt hat und schon hatten wir mal eben so vierzig Fehler auf der Seite. Sollte behoben sein. Typografisch haben wir sehr, sehr viel geändert, auch grade, für XP-User. Startseite haben wir noch geändert. Kommen wir gleich noch mal drauf ein, Dirk. Dann hab ich eingebaut eine Suchfunktion für die Kommentare. Und zwar, ist durch das neue Layout die, Sidebar recht schmal geworden, die Kommentare ziemlich schmal.

Und es gibt jetzt auch, in jQuery eine kleine Funktion, da drückt ihr drauf auf die Lupe und, das vergrößert sich über die ganze Seite. Vielleicht auch nicht ideal, müssen wir drüber überlegen, inwiefern wir das noch optimieren können. Auf jeden Fall, das ist drin. Visited Links im, Archiv, 'ne Suchfunktion ist drin und so weiter und so fort. Eine Sache, die ich noch kurz ansprechen möchte: Besonderen Dank an Matthias Schäfer.

Der hat mal kurz mit Regular Expressions, ausgeholfen, das ich brauchte für die Teamseite. Also wirklich, wir haben sehr, sehr viel Zuspruch bekommen für das Design, sehr viele Hinweise. Was wir noch verbessern können. Und wir möchten euch bitten, also wir bleiben noch dran, wollen diese Seite noch ausbauen. Dazu brauchen wir euer Feedback. Also was können wir dran verbessern? Oder gefallen euch die Farben nicht? Wenn ihr den habt, schickt uns das.

Wir wollen wirklich 'ne Seite bauen, an der ihr noch 'n bisschen Spaß habt. Tja, so weit von mir. Also herzliches Dankeschön. Okay, an dieser Stelle auch danke ganz explizit an Dirk Jesse. Du darfst noch mal Hallo sagen. Hallo. Und Tomas Caspers. Hi. Und noch eine Geschichte ganz eben, warum ich ein bissl ins Joggen gekommen bin. Dirk, du hast dich grade dafür bedankt, dass ich dich erwähnt hatte mit den, erwachsenen Frauen, die so heiß auf deine Stimme sind.

Ich hätte jetzt auch Thomas nehmen können, aber- Muss ich noch 'n Ironie-Tag drumherum machen? Den haben wir jetzt damit erwähnt. Okay, dann bedanke ich mich bei euch beiden und bei euch fürs Zuhören. Ich fand, es ist 'ne supergute Sendung geworden. Deswegen haben wir die auch total genannt.

Noch eine Stelle: Wenn ihr Technikwürze gut findet und wir geben uns ja wirklich reichlich Mühe, dann belastet es nicht dabei und schreibt uns 'n Kommentar, sondern erzählt es bitte auch euren Kollegen in den Agenturen oder wo ihr auch immer seid beziehungsweise anderen Freunden, die auch Webseiten bauen. Empfehlt den Technikwürze, die sollen mal zuhören und ebenfalls kommentieren. Dann machen wir vielleicht noch mehr Sendungen. Alles klar. In dem Sinne wünsche ich euch eine schöne Woche.

Bis dahin, bye bye. Vielen Dank euch beiden. Tschüss. Tschüssi.

Mehr Qualität im Webdesign durch Webstandards. Tipps und Tricks zur Umsetzung findet ihr bei den Webkrauts auf Webkrauts.de. Für ein besseres Web. Weitere Informationen und die Links zur Sendung auf technikwürze.de.

Ja, wunderbar. Dann sind wir durch. So, jetzt müssen wir noch 'n Quatsch machen für die Outtakes. Ja, schlag was vor. Was machen wir jetzt? Das, was ich grad gesagt hab, kannst du ja schon nehmen. Ja, das am Anfang, ne? Genau. Ich war letzte Woche schon dran. Da hast du mich schon mal, da hast du, da hattest du genau den, den, den Amazon-Link. Mhm. Ja, dass mir jemand Gummibärchen schickt, ne? Also irgendwas hast du da erzählt. Genau.

Deswegen kam mir's gleich wieder- Ja, wenn dir jemand Gummibärchen schicken will, dann, gibt's von Dirk den Amazon-Link. Genau. Ja, das soll jetzt keine Wertung sein, ne, dir gegenüber. Das ist eher die Wertschätzung. Ja. Wir könnten ja auch alle mal sagen für Tom, wir drücken die Daumen für Köln fürs nächste Spiel. Ja. Wer ist dran? Wer geht unter, Tom? Cottbus. Ah, alles klar. Soll ich das bringen? Okay. Ja, Cottbus ist nicht die Nähe hier.

Also 'n Dresdner interessiert das 'n Scheiß, was Cottbus macht. Hannover kann untergehen, ist mir egal. Ey, ehrlich? Ja, ja, ist mir voll egal. Ich steh überhaupt nicht auf Fußball. Ach so. Jetzt hätt ich dich jetzt gefragt, ob ich dir 'ne Karte mitbesorgen soll, weil da geht nämlich am Dienstag der Vorverkauf los. Ja, du, ich hätte, ich hätte gar kein Problem. Ich mag die Hannover-Jungs sowieso nicht, weil das sind alles-

Diese technische Störung wurde Ihnen präsentiert von Zeit.

Ich weiß nicht, wie die anderen alle sind, ja, die Spieler. Auf jeden Fall, ich, ich setze mich gern mit auf deine Tribüne, zieh mir dein Trikot an, wenn Hannover dabei ist und sage, ne: „Köln über alles", oder so. Wie machen das eigentlich die Berliner grade? Ich meine, die halbe Stadt mag Hertha nicht. Bitte? Die halbe Stadt mag ja Hertha nicht. Die halbe Stadt liebt ja Union, Union Berlin. Ja gut, aber das ist ja nur die eine östliche Hälfte, ne, Eisern Union.

Also, oh, ich glaub, die westliche Hälfte entdeckt grade den Fußball wieder, ne. Der war ja da so, wie, wann waren sie das letzte Mal Meister? Ich glaub, vor 78 Jahren oder so, ne. Da hat ja quasi die Stadt, das war ja, ja. So als das alte Stadion gebaut wurde, so ungefähr, ne? Ja, so ungefähr. Um die Zeit muss das ungefähr sein, ja. Ja. Ach ey. Ja, unsere Fragerei. Also sprich für dich keine, keine Karte für Hannover, okay. Erst mal nicht.

Aber wenn ich grade in der Nähe bin, dann komme ich auch mal mit. Nee, musst du sagen. Also wie gesagt, Dienstag ist Vorverkauf. Ja, aber wenn ich eh nicht zum Fußball muss, sind's ja Kölner weiter. Genau. Na ja, sagen wir mal so, ich, ich war noch nie im Fußballstadion und ich würd's mir unglaublich gern mal anschauen. Ja. Weil ich gehört habe auch von vielen, beziehungsweise, im Fernsehen siehst du's ja nicht wirklich, dass die Stimmung, während eines Spiels einfach sensationell sein soll.

Wenn die Kölner da sind, ja. Ja, das ist wirklich so. Also das jetzt, das hat jetzt nix mit meiner, mit meiner Liebe zu diesem Verein zu tun. Ja. Sondern, das, das hast du auch letztes Jahr, letzte Woche gehört, als wir auswärts auf Schalke gespielt haben. Du hast im Premiere nur Kölner gehört. Mhm. Also die machen wirklich zu jedem, die machen aus jedem Auswärtsspiel machen die 'n Heimspiel.

Das war jetzt auch, letztes Jahr war ich in Bochum, Ende des Jahres, mit, mit roundabout fünfzehntausend Kölner. Aha. Und das ist einfach, die, wir waren, wir sind dann mit 'n paar Mann, was heißt mit 'n paar Mann, mit 'n paar hundert Mann in das Vereinsheim des VfL Bochum. Und haben quasi den Laden da mit friedlichen Mitteln übernommen.

Mit unserer, mit unserer rheinischen Frohnatur haben wir das Vereinsheim des VfL Bochum übernommen, bis zu dem Punkt, wo der Wirt dann irgendwann aufgegeben hat und hat dann Viva Colonia aufgelegt. Sehr schön. Im, im VfL-Vereinsheim. Das war einfach, da haben die Bochumer mit, uns gefeiert, dass wir gewonnen haben. Super. Das ist einfach, also deswegen, deswegen liebe ich diesen Verein. Der ist halt genauso bekloppt wie ich.

Nee, ich würd's mir unglaublich unglaublich mal, gern mal anschauen, um das einfach mal gesehen zu haben.

Nee, ich wollte der, der, der Kollege Krupinski, ich weiß nicht, ob du den kennst aus Hannover.

Nee.

Nee.

Nicht vom Namen her.

Der, der war früher mal BIG-Berater bei diesem, bei diesem komischen Blindentestverfahren.

Ach so, okay.

Aus Hannover. Der wollte auch mitkommen und der ist aber, der ist aber-

Ach er, ja, ja, natürlich. Doch klar. Ja, ja.

Der ist aber, der ist aber '96er Fan. Also der-

Ach okay

... den könnt ich jetzt nicht mit in die Folge Ja. Gut.

Verstehe. Ja, wunderbar. Also-

Sonst nix mehr.

Nee-

War 'ne schöne Sendung, hat Spaß gemacht.

Find ich auch. Stell ich genauso online. Und dann, quatschen wir nächste Woche. Wünsche euch noch ein schönes Wochenende, ne.

Ebenso.

Ich auch.

Bis dann. Ciao.

Tschüssi.

Ciao. Licht anmachen. Hier wird es ja richtig

Wird schon dunkel bei dir, ja?

Sollen wir dir Licht ans Fahrrad machen?

Boah.

Passend zur Stimmung jetzt, wird dunkel.

Wir, wir wollten, wir wollten doch fragen, ob man dich Mister Slash T aussprechen soll.

Genau. Also w--, du schreibst da immer Slash T. Jetzt ist die Frage: Wie möchtest du genannt werden? Ist es Slash T? Ist es Schrägstrich T oder ist es Mister T?

Nein, das ist einfach-- Also meine, meine Kinder sagen zu mir blöder Papa. Nee, Thomas reicht. Also ja.

War auch nur 'n Scherz. Okay.

CSS-Hooligan.

Sehr schön. Ich nehm übrigens schon auf, das ist alles für hinterher.

Ah, okay. Machst, machst du so Outtakes, oder?

Ja, wenn ich mal alles mitschneide, dann schon. Das Blöde, also das Gute ist, wenn ich die normale Aufnehm..., die normale Aufnahme mit meinem normalen Programm mache, sage ich Start, dann ist der Beginn der Sendung und wenn ich Stopp drücke, ist die Sendung fertig. Das hat den Vorteil, dass ich nix mehr schneiden muss und bin superschnell mit'm Podcast fertig. Nachteil ist, es gibt keine Outtakes.

Ja, ist doof, ja.

Ja. Vielleicht gibt's die ja auch.

Oh, ich hab noch, ich hab noch was für die Outtakes. Ich hab grad eine Mail von meinem ganz speziellen Freund Oliver Thiel gekriegt. Da freue ich mich ja richtig drüber. Ach herrlich, von Stay Friends.

Oh, ach da-- Oh. Der Typ geht mir mal so aufn Zeiger.

Grüße an Oliver Thiel. Du gehst allen Leuten so dermaßen auf die Kackerne.

Genau, ich hab extra mal meinen Account mal gelöscht.

Ich auch.

Ich find es so, ich find es nämlich so was von dämlich, ja. Dass ich hab letztens von einem, den ich wirklich aus der Schule kannte, 'ne Nachricht bekommen, wo ich sagte: „Mensch, ja, bei dem hätt ich mich sowieso gern mal wieder gemeldet und jetzt hat der sich gemeldet und will natürlich auf Antworten klicken und das Progrämmchen sagt mir: 'Hier, überweis uns mal 'n bisschen Kohle, dann darfst du ihm vielleicht mal schreiben, dass du ihn kennst.' Ja. Und dann hab ich gesagt-

Dann kriegst du noch nicht mal die E-Mail-Adresse raus.

Da, da mich, da mir der Oliver sowieso aufn Zeiger geht, ich kick ihn jetzt mal. Und dann hab ich meinen ganzen Account da gelöscht. Ich hab da echt die Schnauze voll gehabt von dem Teil.