from grids to layout groups
Responsive is everywhere, the impact is tremendous. Wireframing, visual design and front-end development are all straining to cater to the needs of responsive web design. People are experimenting but nobody really knows for sure where responsive will take us. From a front-end/structural point of view, the first and most drastic impact of responsive on a website is the layout grid, so let's see how this may affect the html and css we write.
grids, columns, rows
Layout grids used to be one of the most important pillars of web design. They were the one component that didn't need to be semantic as its function was inherently visual. Grids are all about rows and columns and so our classes reflected that. Then responsive web design came along and it messed everything up.
When doing a responsive design, rows can become columns, grids can turn into lists and rows can become fixed floating element. Sure enough every responsive "view" is matched against a particular grid, but as the html structure for all those views is exactly the same we need to drop classes like .row, .col and .column1 as they make no sense whatsoever (unless seen in one particular view).
introducing layout groups
One thing responsive shouldn't be allowed to change is the logical grouping of content though. Content that belongs together should remain visually grouped, so rather than group elements in rows and columns, we simply need to find a different name for these layout container. While layout containers would be a decent enough option, I preferred the term layout groups as it highlights the grouping of several element without hinting at the html tag implementation.
<div class="layout"> <div class="group1"> ... </div> <div class="group2"> ... </div> <div class="group3"> ... </div> </div> Since these layout groups are purely added for visual structuring I use div-tags. In some cases you could substitute them with more semantic tags (like header, footer, aside, section, article) but that is bound to make reuse of the component in varying situations almost impossible. Choosing divs allows us to use this component everywhere we see fit. When an aside, section or any other semantic container is appropriate we can just nest those in the layout groups. This also allows us to group an aside and footer in one layout group if needed.
and now the tricky part: the css
The toughest thing about layout is related to source order. Sure enough you can turn a blind eye and structure the groups in such a way that's easiest for the css to layout, but that's just plain cheating. A good layout module is source order independent, meaning that no matter how the groups are ordered, you can make them turn up everywhere you want.
Additionally you should be able to play around with liquid and fixed columns as freely as you want. The toughest layout is the one where the three groups are laid out next each other, with the outer columns liquid and the middle column fixed. That's a whole lot of requirements, especially when you combine them together. It would take us way too far to inspect every different case in detail, so I just made an extensive test page where all the layouts are combined. You can check the css implementations on the page itself. Mind that the entire page is build using the same simple html structure that we defined above.
(To observe the liquid behavior of the columns you need to make your browser smaller.)
IE7
Once you start browser testing you'll notice that IE7 is not supported. There are two problems we are facing here. The first is related to a bug where IE7 has trouble computing percentages when the element's container has no explicit hasLayout trigger. This is easily fixed by adding a zoom:1 to the .layout class
There is a much bigger problem we are facing though. Like most other browsers of that era IE7 has trouble with percentages and rounding errors. 50% + 50% isn't just the full width of its container, it could just as well be 100% + 1px. In that case the float structure collapses and all our hard work falls down the drain. There are workarounds (using 49.9% for example) but those fixes need to be applied case by case. If you still need to take IE7 into account, I'm pretty sure your skills are adequate to work around these bugs when needed (depending on what version on the layout module you need).
what about flexbox
I also tried playing around with the css3 flexbox property a little. The fact that you can move around structural elements using ordinal-group would be a tremendous help for the source order independent requirement, but I couldn't find any way that would allow me to mix rows and columns using the flexbox property (for example, the first layout group would be 100% wide, group 2 and 3 would be evenly spread in the row below). As far as I can see all the elements inside the flexbox are either stacked as columns or rows. If I missed anything, please point me in the right direction.
conclusion
Responsive changed the way we think about layouts. Grids, columns and rows are still useful for designing one particular view, but from an html/css point of view these terms have lost their value. Instead we need to move to layout groups and enrich them with a css structure that allows for flexibility in source order and liquid/fixed behavior.
Once again: for more practical css tips check the layout test page