Fluidity CSS, State of the Union
This Project is now abandoned though the github is still around. Some folks were using it and/or forking it in some wordpress based publishing platforms and custom CMS systems so who knows might still be in prod somewhere. These days vanilla css has solved the vast majority of the problems this was aimed at. One thing is seeing css finally have a grid and embrace fractional units for it. At the time most css frameworks were baking their grid dimensions in at some number columns usually 9 and you had to do mental gymanstics to figure out how to get half the page. I digress... it's fun to look at now but don't use it.
WayBack Machine - FluidityCSS.com
I am the original author and main contributor to this open source css framework for the Stylus CSS preprocessing language called Fluidity - (github) It still picks up the occasional star or watcher and I still use it occasionally but, I have recently been experimenting with a smaller subset of the framework along with other tools specifically postCSS. The front-end landscape has changed quite a bit since 2011-2012 when I first created Fluidity so I think maybe there is some room to ruminate on what a css framework can and should be today.
I mean we all know it's not bootstrap or compass anymore... right? We've iterated on the front-end workflow with build tools from grunt to gulp, broccoli to web-pack we've gained so much more parsing and processing power these days what's the place for our much loved preprocessing languages in general? If we take away all things that we used to rely on these languages and their magical mixin powers to do, what are we left with? I mean I think there's still plenty, of course, but there are also some definite things that our libraries and frameworks don't have to do anymore and what that should mean is lighter frameworks or at least some different kind of frameworks.
As we move towards web-components presumably our needs for deep design decisions to be made inside our frameworks will begin to fade. Instead we'll likely be relying more and more on UI framework libraries that consist of nice looking components ( think googles material design). Our frameworks should become more clever at allowing us to build these types of libraries. We can worry less about browser pre-fixing and grid systems and more about what really matters designing beautiful and consistent user experiences one thoroughly tested and designed component at a time.
Just some thoughts... Here for nostalgia's sake is the original launch announcement for fluidity.
Original Announcement - From 09-24-2012
I have undergone a great deal of "eating my own dog food" as it were. As a result of all that rigorous real world use I hope to reap the refactoring benefits for this first release. It has gotten clearer than the current docs have it and may likely be a bit smaller in scope. I want this framework to be minimal yet functional enough to bootstrap an idea easily. After the initial bootstrapping it should then stay out of your way and let you design your site. I don't want to create or even use something as large as Bootstrap®by®Twitter®©. The first aim is for zero reliance on images and zero decisions on color and avoid any unnecessary javascript. Do it with CSS3 and HTML5. Do it semantically. And mobile comes naturally.
It is currently built on top of Stylus and aims to be as modular as possible. For instance you could easily use just the grid from Fluidity and get your mix-ins from Nib or you could use it as a much lighter weight and (less obfuscated in my opinion) alternative to Nib.