I started paying closer attention to CSS Grid because layout work had always carried a small amount of compromise.
For years, building a page layout meant choosing between floats, inline-block, table-style tricks, toolkit grids or later flexbox. Each approach solved part of the problem, but none of them felt like the browser truly understood a page as a two-dimensional layout. We could make things work, and most of the time they worked well enough, however the CSS often described the workaround rather than the intention.
In 2017 that started to feel different. Grid support was moving into modern browsers and, for the first time, I could look at a page section and describe the rows, columns and gaps directly in CSS. That sounds simple, but it changed the way I thought about layout because the code finally started to match the conversation I was having during design.
Why Floats Always Felt Like A Compromise
Before Grid, I used floats for plenty of layouts because that was the normal way to get columns on a page. The problem was that floats were never really designed for whole page layout. They were originally useful for allowing text to flow around content, then web developers spent years using them to hold together grids, sidebars and complex sections.
That meant a lot of supporting code came along for the ride. Clearfixes appeared everywhere, columns needed careful widths and a small change in content height could affect how the next row behaved. None of this was impossible to manage, but it meant the layout was always being negotiated through indirect behaviour.
Toolkit grids helped because they provided a consistent pattern, however they also encouraged layouts to be described through classes rather than through the structure of the section itself. A row contained columns, the columns had classes and the HTML started carrying decisions that I would rather keep in the CSS.
Flexbox improved a lot of that, especially for one-dimensional layout. It made positioning far easier and changed how I handled navigation, cards and small components. Even then, flexbox was strongest when dealing with a row or a column. Full page structure still needed something that understood both directions at the same time.
Thinking In Rows And Columns
The first useful thing about CSS Grid was that it allowed me to describe the layout directly. If a section needed two columns, a gap and a content area that spanned a particular space, the CSS could say that without pretending the layout was a collection of floated blocks.
.layout {
display: grid;
grid-template-columns: 1fr 2fr;
gap: 24px;
}That code is not dramatic, but it is clear. The container is a grid, the columns have a relationship and the gap belongs to the layout rather than to margins spread across child elements. I found that easier to come back to later because the CSS explained the decision in plain terms.
It also made responsive changes feel more intentional. Instead of fighting percentages and clearing behaviour, I could change the grid at different breakpoints. A three-column layout could become two columns, then one column, without changing the meaning of the HTML underneath it.
Where I Would Still Be Careful
I would not have treated Grid as a reason to rebuild every existing website immediately. Browser support still needed checking, and some projects still had old browser requirements that made new layout features harder to justify. The decision was not just whether Grid was good, because it clearly was. The decision was whether it could be used safely for the people actually visiting the site.
My instinct at the time was to use it progressively. If the layout could fall back to something acceptable, Grid could improve the experience for modern browsers without breaking the basics for older ones. That felt like the right balance. I did not want to avoid better CSS forever because of old browsers, but I also did not want to make a client website fragile for the sake of using a new property.
This is where feature queries started becoming useful too. Being able to check for support with @supports gave developers a cleaner way to layer newer layout behaviour on top of older defaults. That made Grid feel less risky because it could become an improvement rather than a hard dependency in every situation.
What Changed In The Way I Built Sections
The biggest change was how early layout thinking moved into the CSS. Instead of designing a section, then translating it into a toolkit grid, I could start by asking what the structure actually needed to be. Did the content need equal columns? Did one area need to span wider than another? Should the order change on smaller screens? Those questions became easier to express.
It also made the HTML feel cleaner. I did not need as many presentational wrappers just to satisfy a layout system. When the CSS has stronger layout tools, the markup can stay closer to the content. That matters in real projects because HTML tends to get reused, edited and extended long after the original design is finished.
For me, Grid was not just another CSS feature. It was a sign that browser layout was finally catching up with the way websites were being designed. I still needed to think about fallbacks and support, but the direction felt right.
Retrospective Thoughts
Looking at CSS Grid in 2017, the important part was not that it made every layout easier overnight. The important part was that it made layout feel more native to CSS. For a long time, developers had been building page structure through tools that were never quite intended for that job. Grid gave the browser a proper language for the problem.
I think that changes how a developer feels when maintaining a project. Code that describes the layout directly is easier to adjust, easier to explain and less likely to rely on accidental behaviour. That matters more than it first appears, because most websites are not finished on launch day. They change, and the layout has to survive those changes.