From Tables to Responsive Design
There was a time when building layouts for the web felt less like engineering… and more like assembling furniture without instructions.
If you’ve only ever used modern CSS, it’s hard to appreciate just how chaotic things used to be. So let’s rewind a bit — back to what I like to call:
the dark days.
The Era of Tables, Frames, and <center>
In the early days of the web, layout wasn’t really a “system.”
It was… improvisation.
Want to position elements on a page? Use a table.
<table>
<tr>
<td>Header</td>
</tr>
<tr>
<td>Main Content</td>
</tr>
</table>
Need more control? Nest more tables inside those tables.
Want to center something?
<center>Welcome to my website</center>
Yes, that was a real tag. No, we don’t talk about it anymore.
And then there were frames — splitting your page into separate scrollable sections that behaved independently. It felt powerful at the time, but in practice it created:
- confusing navigation
- broken URLs
- bookmarking nightmares
It worked… until it didn’t (which was often).
When Browsers Were the Real Boss Fight
If building layouts with tables wasn’t already painful enough, browsers made things worse.
Each browser had its own:
- quirks
- bugs
- interpretations of HTML
What worked in one browser might completely break in another.
This meant developers spent a lot of time doing things like:
- writing slightly different code for different browsers
- adding weird hacks just to “make it look right”
- testing endlessly and still not being sure
There was no “single source of truth” for how things should render.
You weren’t just building a layout — you were negotiating with multiple rendering engines.
The Arrival of CSS (Finally, Some Structure)
Then CSS showed up and said:
“What if we separated structure from presentation?”
Instead of using tables for layout, you could:
- use HTML for content
- use CSS for styling and positioning
This was a big deal.
Suddenly you had tools like:
marginandpaddingpositionfloat
And while this was a huge step forward… it wasn’t exactly smooth sailing.
Floats: The “This Shouldn’t Work But It Does” Era
For a long time, layout in CSS relied heavily on float.
Which is kind of funny, because float was never designed for layout in the first place — it was meant for wrapping text around images.
And yet, we used it for everything.
.sidebar {
float: left;
width: 30%;
}
.content {
float: right;
width: 70%;
}
This led to:
- clearfix hacks
- collapsing parent containers
- mysterious layout bugs
It worked… but only if you knew the tricks.
Then Everything Changed: Responsive Design
For a while, most layouts assumed one thing:
“The user is on a desktop.”
Then smartphones happened.
Suddenly, fixed-width layouts didn’t cut it anymore.
In 2010, a web designer named Ethan Marcotte introduced the idea of responsive web design — a way to make layouts adapt to different screen sizes using:
- flexible grids
- fluid images
- media queries
This was the moment things shifted.
Instead of designing for a single screen size, we started designing for:
- small screens
- large screens
- everything in between
Media queries became the new superpower:
@media (max-width: 600px) {
.layout {
flex-direction: column;
}
}
And for the first time, “responsive” became the default expectation — not a bonus feature.
Looking Back
This era of web layout was messy, creative, and sometimes frustrating.
We went from:
- hacking layouts together with tables
- fighting browser inconsistencies
- bending CSS to do things it wasn’t meant to do
…to something that actually started to feel like a system.
But we were still working around limitations.
In Part 2, we’ll get into the tools that finally started to make layout feel intentional:
- grid systems
- flexbox
- CSS grid
- and the newer features that are quietly changing things again
Spoiler: it gets a lot better.