Gridless
These days the web and how it’s designed leans heavily, for one reason or another, on grid design. This mainstream adoption is more of a recent development and as a design process it makes a lot of sense getting to grips with content flow and structural spacing. One glaring incongruity with the web and traditional grid design is that most grid implementations tend to be fixed, fixed on ‘paper’ whilst the Web, a dynamic medium, at it’s core is free and fluid in nature. For print the grid is determined beforehand, for the web the grid is only known after the content has loaded. The grid that follows would need to be fluid so that it will always fit regardless the given dimensions. I still see grid solutions that are not intrinsically fluid.
When we use classnames like '.rows' and '.columns' we are asserting a specific grid pattern before the viewport is known. A '.row' on a large screen might very well need to be a column on a small screen. In effect the grid is incorrectly implied within the markup and so we end up changing it after the fact with CSS and or JavaScript. This approach requires additional and superfluous effort in it’s implementation. Making it fixed, unfixed and fixed again on top of something fluid requires the site to be coerced with extraneous code. This kind of code for large and long living websites is a major problem. It's hard to read and even harder to change.
Transforming a '.row' into a column and not changing its classification is conceding that we're stuck in the past.
Visually we may observe rows and columns, however, with the modern web we need not explicitly name them as such. In fact, we certainly shouldn’t be doing that when we know what the design and or content needs to look like. Grid systems, responsive or not, are built with no regard for your content and only attempt to cover the most generic use cases. We end up writing intermediate code. Bloat is unavoidable.
Moving forward
So, if a predefined grid is a bad idea we need to start again with the content in mind and embrace the premise that browser content is inherently fluid in its representation. Web design is largely about content and allowing user to interact with it.
A truly fluid grid layout can be represented through patterns that are not predetermined by a set of underlying dimensions. Fluid patterns are formed by the underlying element structures and the direct relation of sibling elements. Alas, the web doesn’t yet give us the full control to make that really work.
The web is a flow (ie. cascade) of independent elements within a document. Each with its own sizing and visual properties that passively relate to each other by their offsets within the flow of elements. Elements don’t know or care (very much) about what’s going on around them, they just try to stay out each others way. This flow, left to right and down the page, is the reason why we needed styles and markup to create an explicit design. We need control because we like precision. The web does not yet offer us the means to create a dynamic layout with the ability to assign flow behaviour beyond the cascade. This lack of layout control has in my experience been the single most limiting factor in browser based UI development.
Thankfully this is rapidly changing as Flexbox, even though the browser implementations differ, is now a viable solution. The Grid Layout Module, an actual layout solution, is also picking up steam and may actually be usable in 2017. Fingers crossed.
Currently the Grid Layout Module is in play so we can add that to the Flexbox solution. Using Flexbox for layout is great when we intend to lay content out in a single line isolated from the surrounding elements. For most cases using Grid layout is your best option. In any case both of these solutions are certainly the next step up from float based layout and table based layout before it.
Flexbox’s dynamic nature is a perfect fit for fluid grid design because with Flexbox an element becomes a part of a dynamic group of elements in that it can easily be a row or a column and your markup doesn’t need to be explicit about it.
CSS
section {
display: flex;
}
section > article {
flex: 3;
}
HTML
<section>
<article> ... article content ... </article>
<aside> ... sidebar content ... </aside>
</section>
This is extremely powerful, because you can control the dynamic layout behaviour with a singular flex value. Effectively you only need to identify the elements that don't have a flex value of ‘1’, which is the default. Aligning content onto a grid is now mostly about margins and padding. When you compare this approach to, let’s say, Bootstrap, you can quickly see how verbose Bootstrap really is. The mountain of unused code loaded by Bootstrap because it doesn’t know what kind of content is needed is one of the major reasons why you should never build a long living site with it. But that’s a whole other rant.
Flexbox still has some issues and one of them is the lack of gutter spacing. In fact, CSS columns, grid layout and flexbox behave inconsistently from each other. So picking Grid or flexbox will depend on what you need to achieve. For example, a three column design with a two thirds and a one third column can, rather easily, end up with inconsistent column widths with each of these techniques. This may result in the author being forced to pick one over the other which is a shame. We want fluidity but we still need predictability and adding gutters to Flexbox may do the trick. Despite these issues Flexbox' advantages outweigh most of these concerns and I have embraced what it does well.
We've started to implement some of these simplified grid techniques for the Dutch ANWB website. Decoupling the grid implementation from the markup in this way will allow us to switch to CSS Grid Layout if or when we need to. It's starting to look like we will actually gain proper control over the page layout instead of hacking it.