It’s been over a year since I created Grid. The feedback from the community was amazing and I learned so much about what could be improved.
Today, I wouldn’t use Grid on client work, mainly because it was intended to be more of a learning tool than a standalone framework. After a year of learning, I realized I didn’t need an entire grid system for my projects. It’s better to create custom components as necessary and rely on more semantic naming conventions over generic class names like
- CSS frameworks are great for prototyping but not for production.
- Presentational class names like
.third, etc. become meaningless once a responsive layout changes.
- It’s better to control layout with CSS than with markup.
- Visual grid classes in the markup are not semantic and limit extensibility.
- Mobile first is better than desktop first.
A more semantic grid
It’s better to stay away from presentational names like
.half because they become meaningless once the layout changes. Think of it like this: a
.half column is no longer a
half on mobile.
It’s better to name your classes something more descriptive than
.column; choose a name that describes the purpose of the component, like
.calendar. To help with this, I’ve recently discovered the power of using the BEM methodology (short for block, element, modifier) for naming in my stylesheets.
BEM allows you to avoid using generic names by giving you a mental template to ease the naming process. Before you start naming your components, take some time to deconstruct them in your head or on paper. Start by identifying and naming the
block, which is the highest level of a component. An
element is a child of
block, and is contained within it. Finally, a
modifier changes the state of
By removing presentational classes like
.half from the markup and replacing them with more semantic and structured approach, we can simply control and maintain the entire layout with just CSS.
Sass is your friend
In Grid, I used plain CSS rather than Sass, which doesn’t give you access to features like variables and nesting. Without them, it makes your code harder to maintain.
Leveraging Sass gives you the ability to create variables you can use with media queries by defining
$large, etc. When coming up with variables names for breakpoints, use words like “small”, “medium” and “large” as opposed to “mobile”, “tablet” and “desktop.” This is much more flexible and doesn’t limit the breakpoints to specfic devices.
I originally built Grid desktop-first, meaning I started building the desktop styles before I built the mobile styles. You end up being forced to undo properties you defined for larger screen sizes and your code can become overly complex.
A better approach is to start with mobile styles and layer on styles optimized for larger screens only as needed. In other words, your mobile styles become the default and you no longer have to override them later, freeing you to progressively enhance your design.
Nested media queries
It is much clearer and easier to maintain your stylesheets when you keep your media queries near their respective components, rather than at the end of the stylesheet or in a separate document. You can easily achieve this by nesting your media queries within each component:
We can add our clearfix by using
@extend in our block element, which removes the need to have references to
clearfix in the markup:
If you’re curious to learn more, I wrote a Sass clearfix post about why this is more semantic.
After receiving tons of feedback on Grid, I realized just how much I had to learn. The community really pushed me to be better–even when it hurt.
If anything, I’ve learned that front-end design is constantly evolving and that it’s crucial to keep up with what’s going on in the industry to stay afloat.