Back-End Developers Hate Front-End: Creating Grids with CSS
It’s true. The 2 disciplines — while they coincide with each other — often cause a rift, because they are two different beasts that require different approaches and additional knowledge of quirks. Front-end takes an eye for design detail that in theory should be simple, but due to unusual CSS implementations and browser inconsistencies, becomes tedious.
There are dozens of CSS frameworks such as Bootstrap that try to solve many of these issues by providing some level of consistency, but can also be equally cumbersome to work with if you find yourself wanting to highly customize the styles, overriding the majority of the default CSS included. What it comes down to is simply understanding some of the most common CSS and why things behave the way they do (even if it makes no sense). The properties that I think everyone will have to fuss with at some point are display and alignment. It is the backbone of literally everything on the page that is being styled, and if one element is off, it can cause complete chaos… And then still manage to look different in another browser. While the days of torturous styling for IE9 and under are mostly behind us and mobile devices are far more capable of quickly rendering full websites, we are still met with the additional challenges of making styles display properly cross-platform — especially when considering responsive and/or media queries.
There are roughly 4 ways to make grid systems: float, inline-block, table-cell, and flexbox.
Float: Floats are pretty easy to use, however I don’t personally care for using it these days if there’s a less verbose way of achieving the same layout. Floats require additional markup or CSS to clear them, because otherwise you find yourself with elements falling outside of containers and other alignment issues. Floats are still handy when designing large layout blocks that don’t require equal heights and vertical centering. Eg: Using a main container block and a sidebar.
- Most common and well-known. Likely has the most documentation for adapting your templates to use this effectively and overcoming its bugs. Most grid frameworks use floats.
- No vertical centering
- Elements can’t be equal heights
- No source order independence
Inline Block: Inline block is a pretty handy solution to aligning many page elements — however I would not recommend it for laying out an entire grid. It works well and consistently across all browsers, with a caveat for IE6/7, which support it for some elements. However one of the primary quirks with inline-block is that because of the inline aspect (see WC3 documentation), the white spaces between elements are treated the same as white spaces between words of text, so you can get gaps appearing between elements. There are work-arounds to this, but none of them are ideal if you wish to eliminate it.
- Vertical centering — especially useful for something like navigational elements, or text and image alignment.
- No extra markup needed for clearing.
- Default whitespace. It can get a little messy when using it for a grid.
- Elements can’t be equal heights (still)
- Still no source order independence
- Provides you with vertical centering and equal heights
- When used in the CSS, the markup is lightweight. The CSS is also lightweight.
- Extra wrapper divs. You can only place grid elements in one row because you can’t push them on a new line via CSS. This means that for each row you need a new container element, and it becomes very inflexible for responsive designs.
- Adding spacing between table cells can be a little messy to create.
- Content can overflow its cells and it’s a bit hard to deal with (although there is word-break: break-all; which will force a word break at any character).
- Using media queries can become complicated.
Flexbox: The answer to our prayers, right? To be honest, I don’t fully understand how it works. And with that, it makes it a little annoying to work with. I’ve have to use it once to create flex-width tabs that can accommodate an infinite (although realistically about 10) number of tabs. They could not be fixed width, and when one of the tabs was selected, the full text had to be displayed and the other tabs downsized accordingly.
There are inconsistencies with this cross-browser, but if you literally do not care about most things outside of the latest Chrome, Firefox, IE, and Safari, then this might not be much of a concern. However, my limited experience with it leaves me skeptical and hesitant to recommend it. It’s still too early to say, but I would say play around with it, because it likely can solve some of your most complex layout issues.
- Source order independence. Could be of tremendous value for responsive layouts and eliminates the need for JS for this.
- Vertical centering
- Equal heights
- Extremely versatile with what can be done on the x and y axis..
- Boxes grow and shrink, can be columns or rows, fit to the available space however you wish to declare this.
- There are multiple ways to do the same thing with flexbox.
- Syntax is initially unintuitive. I bumbled through this quite a bit on first try as a seasoned front-end dev.
- Cross-browser inconsistencies… Even more unknown than I can tell you. I definitely recommend some experimentation with this before settling on it as a solution.
- Fully understanding it may take a while. Again, experiment with this.
- Doesn’t work on IE9. If you don’t have to support IE9, you’re fine.
- Possible performance issues. Don’t quote me on this.
Grid: I know I only said there were 4, but it’s worth noting that this does exist. However it’s only supported by IE10+ and Safari, so it’s obviously not worth your time. Maybe some day it’ll be better supported.
So what should you use to build your layouts? In my opinion — all of them. Play to the strengths of each where needed. That’s what the rest of us have been doing for years, so until there’s a widely supported single solution, expect it to not be a cake-walk.