Tabellen fürs Layout: Alltag mit Trial & Error
Wer zwischen 1997 und 2005 Webseiten gebaut hat, kennt das Szenario. Kein CSS, das halbwegs überall funktionierte. Browser wie Netscape 4, IE 5 – jeder mit eigenen Macken. Also: Layouts mit Tabellen gebastelt. Zeile, Spalte, noch ’ne Tabelle rein. Dann die große Bastelstunde. Menüs, Spalten, Header. Immer schön mit <table> und möglichst wenig Hoffnung, dass es überall gleich aussieht.
Was fehlte? Abstand. CSS-Padding? Ging selten. Also: Spacer-GIF. Ein 1x1-Pixel, durchsichtig. In die Zelle gepackt, per width und height aufgezogen. Zack, Lücke im Layout. Hat funktioniert – meistens. Bis der Kunde das Menü zwei Pixel weiter rechts wollte. Dann: HTML auf, alles nachjustieren. Und hoffen, dass der nächste Browser nicht wieder alles zerschießt. Agenturalltag damals: "Können wir die Box noch etwas schieben?" "Nur, wenn die Tabelle nicht auseinanderfliegt."
Spacer-GIFs: Altlasten, die nicht aussterben
Spacer-GIFs waren kein Feature, sondern ein Notbehelf. CSS war zu unsicher. Die Folge: Jede kleine Layoutänderung bedeutete HTML-Anpassung. Kein zentrales CSS. Ein paar typische Nebenwirkungen:
- Jede Seite ein paar Requests mehr durch die GIFs
- Änderungen immer im Markup, nie zentral
- Die Logik fürs Layout steckt direkt im HTML
2026 sind Spacer-GIFs immer noch nicht ganz verschwunden. Irgendwo gammelt noch ein altes CMS-Template, das als "responsive" verkauft wird, aber im Quelltext Spuren von 1999 aufweist. Besonders nervig: Wer so einen Altbestand übernimmt, kann praktisch nichts ändern, ohne das ganze Konstrukt zu zerlegen. Einmal Spacer-GIF, immer Schmerzen beim Refactoring. In der Praxis: Zeitfresser, Fehlerquelle, alles was man heute eigentlich nicht mehr braucht.
Was bleibt 2026? Struktur schlägt Magie
Tabellenlayouts sind tot. Spacer-GIFs sowieso. Aber: Wer damals gebaut hat, weiß, warum die Sachen wenigstens stabil liefen. Es ging um Klarheit. Jeder wusste, was wie verschachtelt war. Heute? CSS-Grid, Utility-Klassen, Frameworks. Alles geht – aber kaum jemand findet sich im Code noch zurecht. Besonders, wenn nach zwei Jahren ein neuer Entwickler übernehmen soll.
Schon mehrfach erlebt: Ein CSS-Grid mit Flexbox für alles, Utility-Klassen bis zum Abwinken. Schick, solange der ursprüngliche Entwickler noch da ist. Nach dem Teamwechsel? Viel Spaß beim Debuggen. Wer stattdessen für Übersicht und solide Strukturen sorgt, freut sich später über schnelle Anpassungen und weniger Bugs. Wer nur Frameworks zusammenklickt, tappt schnell in die nächste Wartungsfalle.
30 Jahre Webentwicklung: Was sich wirklich auszahlt
Erfahrung aus vielen Projekten: Die Technik ist selten das Problem. Es sind die Leute, die meinen, jedes neue Tool müsse sofort eingebaut werden. Früher: Tabellen, heute: Utility-CSS, morgen irgendwas anderes. Das Ergebnis ist meist der gleiche Schlamassel. Wer solide Strukturen baut, muss beim Relaunch nicht alles neu denken.
Für Agenturen (5–10 Leute): Je weniger Zauberei im Code, desto schneller steigt der nächste ein. Relaunch geht schneller, weniger Stress. Einzelkämpfer? Wer noch eigene Kundenprojekte von vor zehn Jahren betreut, weiß: Verständliches HTML spart Nerven. Einmal ordentlich gebaut, kann das Design ruhig wechseln – das Grundgerüst hält.
Typischer Fehler: Framework übernommen, das nach zwei Jahren nicht mehr gepflegt wird. Plötzlich sind neue Komponenten nötig, aber das Raster passt nicht. Dann: Forken oder alles neu machen. Wer mit einfachen, nachvollziehbaren Strukturen arbeitet, bleibt flexibler. Selbst wenn CSS mal komplett umgebaut wird.
Fazit: Spacer-GIFs weg, Klarheit bleibt
Tabellenlayouts und Spacer-GIFs? Geschichte. Aber das Prinzip dahinter ist nicht totzukriegen. Klare, verständliche Strukturen sind auch 2026 die beste Versicherung gegen Wartungsfrust. Wer heute Webprojekte baut, sollte Frameworks nicht als Ersatz fürs Nachdenken sehen.
Immer noch ein Warnsignal: Alte Spacer-GIFs im Code. Wo die auftauchen, wartet meist noch mehr Altlast. Wer langfristig Ruhe haben will, setzt auf sauberes Markup, gezieltes CSS und ein bisschen Handwerk. Die Technik entwickelt sich weiter, aber das Prinzip bleibt: Wer versteht, was er da baut, muss die alten Fehler nicht wiederholen.
Noch mehr Geschichten aus der Zeit vor CSS, PHP 3 und Co.? Hier entlang: Webdesign 1998: Vor Google, PHP 3 und Flash – wie alles wirklich lief
bye
mo