Considerations about css frameworks

4 min read

Deviation Actions

thehappybit's avatar

As front-end developers, knowing the instruments of our profession is crucial.

As when developing, as in our daily fights with browsers discrepancies, just a little time should be devoted to all of those activities that are repeated, or that can be standardized.

This is also the case with CSS frameworks. There is plenty of them out there, most of them are solid and useable out of the box, none of them will probably satisfy you one hundred percent.

As good as a framework can be, it'll always come up short at suiting your specific needs and it'll likely have to be tweaked a little bit.

One question could then arise: why should't I build my own, then?

In programming, this is a bad practice. If other frameworks, masthodontic in size most of the times, are in place, they'll surely be more solid and mature than your newly born baby will ever be in the short term: reinventing the wheel is always a painful, expensive and unproductive activity.

In CSS front-end development though, this might not be the case.

The existing CSS frameworks are generally pretty light and we know that the industry is fairly young and it is based on a solid set of standards which aren't all defined and carved in stone just yet: in this scenario, no CSS framework has gained a clear edge of advantage over its rivals, nor can it be considered a milestone in the field.

This is why building your own CSS namespace of meaningful class names for repeated tasks such as grid design might not be a bad idea after all.


A good framework should reduce modifications to the structure of the master stylesheet to the very minimum.

Most, if not all, of the frameworks available today limit themselves to adjusting column widths, margins, and horizontal shifts, and only a few more things after that.

Most of them, for example, choose not to implement column containers elements, other than the one that defines the main grid width.
< div class="grid_container" >
  < div class="grid_1" >< /div >
  < div class="grid_2" >< /div >
< /div >

If you're thinking responsively too nowadays, you can instantly grasp the importance of having such elements at disposal, especially when considering about changing margin when a responsive context switch comes into play.

This is something that normally would go in the main stylesheet, but that can actually be left to the framework to deal with; this way, the master CSS would be filled only with the implementations of details, not the structure itself.

Most of today's frameworks force you to base your grid at a fixed amount of pixels, with a predefined set of columns.

The point here is that if you really want your framework to be flexible and useable in the real world, you should be designing it with a single word in your mind, straight from the beginning. That word is modularity.


CSS pre-compilers such as LESS (our choice) or SASS, immensely help the writing of your CSS code, as they enhance the concept of DRY, and allow for code reuse, modularity and a better maintainability throughout time.

The biggest advantage when using CSS pre-compilers, though, is that you can create a dynamic infrastructure, enabling you to define parameters such as grid width and columns number from project to project, reaching a level of flexibility you couldn't when using other frameworks.


The real implicit value of using this kind of approach is that it forces you to actually think about the way you work everyday.

Putting yourself outside the specific problems you may find in your coding routine, allows you to perceive your own workflow more clearly: you can analyze your markup, highlighting the elements most commonly used, and put them in the framework, developing hence your own semantic namespace.

This way, you will not only speed up many tasks, but also produce a better end result, still retaining full control over your markup.
© 2012 - 2021 thehappybit
Join the community to add your comment. Already a deviant? Log In