That is just it in my opinion. A bunch of extra stuff you will more than likely never use. Unless you learn the framework you will be using in and out and apply everything to every project, I think it is better to collect various snippets as I go that i find myself using all the time…
Though i will say i dabbled with Blueprint on a few projects and it really wasn’t bad at all. I just prefer keeping things a little more organized/cleaner.
I have used a bunch of frameworks and have been frustrated by the same issues as the rest of you. In particular, I was amazed by the lack of consideration for big screens as RWD seems obsessed with smaller viewports.
As a result, I set about making my own. [You can see it here.](http://ashloudon.me/respondo/ “Respondo”)
My focus was on keeping the learning curve as shallow as possible, avoiding bloat, maximising semantic elements and scaling **properly** across viewports. I also thought that we should have a touch-specific style sheet.
The downloadable version is uncompressed and well commented so you can jump straight in.
I use bootstrap when I’m developing a back-end without a front-end to plug into. I do more back-end work (developer, not designer), and I like output to at least slightly correlate with the desired end product.
Frameworks clearly have a use. I don’t think their target is experienced designers, though.
Normalize is practically indispensable. It takes care of many little bugs between browsers but still leaves the natural functionality of the browser in place. Resets like Eric Meyer’s “Reset CSS” make a big mess of CSS and remove all basic styling, it’s just not a good thing to do project time wise or load time wise.
Bootstrap has a lot of CSS it uses which can be heavy, but if you’re using LESS it’s easier to get what you want and then strip out the rest.
The 960 Grid System is also very helpful if implemented correctly. If you’re designing for a CMS then you can create templates for the clients and they can more easily format content when they have no prior experience with HTML and CSS.
It all depends on what your project is, but I would highly suggest Normalize and the 960 Grid System for every one if possible. I’ve built sites for companies all over the world and believe me it has saved me much frustration at times. lol
I have written a blog post on this topic as my opinions have changed quite a lot regarding frameworks over the past few months!
Feel free to give it a read: http://joshuajohnson.co.uk/blog/opinions-on-frameworks/
I like a nice responsive grid system like http://csswizardry.com/2013/02/introducing-csswizardry-grids/ and normalize, but that’s really about it
Now, I can’t say I’ve tried many frameworks. I’ve only really worked with Bootstrap, Inuit and Foundation, and so far I have found them all lacking in some way or another.
- **Bootstrap** looked like a great idea when it first came out, but working with it was a pain, not to mention the characteristic look. I migrated from LESS to SASS a while ago, so I haven’t had the chance to see if newer versions are any prettier. (To be honest, I’m a little reluctant to use Thomas McDonald’s SASS port of Bootstrap)
- **Inuit**’s certainly the one that has gotten the least in my way. It’s also about as extensively documented as a CSS microframework can be, which is a great thing. But, to be honest, as much as I have been beaten into admiration by Harry Roberts’ uncompromising blog posts, Inuit has done hardly anything to help me.
- And I’ve only had a brief look at **Foundation** before I knew I’ll definitely be using something else on my next project. The huge _settings.scss was the first thing that made me cringe, and then I saw that the whole thing, grids and all, sits on *goddamn ems*. Which is fine and dandy, I mean everyone loves those, right? Only if you’ve decided to ditch IE7 and provide minimal support for IE8 (not even grids!), why don’t you just get your sh*t together and use ***rems*** anyway?! They’re in IE9+ and every modern desktop or mobile browser imaginable for a reason, no?
The best way to do grids that I’ve ever seen anyone come up with, is the use of mixins. Only I couldn’t get Foundation’s grid mixins to work, at all. Those mixins were only one of the things that got me confused over my brief encounter with Foundation. The provided docs only made me more confused. And I value my time and my mental resources a little too highly to waste them sitting around being confused. All in all, Foundation seems to fall quite short of the promise made by its slick website.
Just picture this, just last week, as I was figuring out Foundation: I tell a h2 to be 12 columns wide, and suddenly the lateral padding becomes larger due to the h2′s larger font size, breaking the entire layout. (At least, unlike many others, they have the dignity (and common sense) to separate columns by padding and not by margins.) Apparently, this is why some folks recommend to use grid classes only as containers – but that’s a wee bit less flexible…
Less flexible? More like going back to the table age, I say! What is it other than replacing the occasional presentational class with tons of presentation-only, not to mention atrociously verbose, *non-semantic elements*? Who the hell comes up with these ideas, anyway? And if a grid column can’t seamlessly double as a grid container of its own, I’m outta here. How about being able to subdivide a nested container into the number of columns that it spans? I can kind of work without it, but is it too much to ask?
In principle, the concept of front-end frameworks makes perfect sense. They’re just libraries for the HTML/CSS/JS environment, right? What they (admirably) intend to do is bring DRY principles to the HTML/CSS world, which also makes ‘em a perfect fit for preprocessors (didn’t see many CSS frameworks before the advent of those, did we?). And, at the end of the day, every other kind of programmer is able to rely on libraries that have been put together by someone else, and reviewed by a community of experienced professionals. So why should we front-end devs miss out?
However, I am filled with great dread at the thought that the frameworks which I have experienced fail to achieve the above; even more, they are the complete opposite. Miserable documentation forces the developer to look for answers in the source code for even the most simple of tasks. Having CSS-only versions of prepro-based frameworks is another thing that just feels completely wrong to me. You have no reason not to learn a preprocessor already! And, most importantly:
I have found myself reverse engineering every framework that I’ve ever used in order to undo something that I don’t want it to do, just about as often as I find that said framework is missing some fairly common ‘trick’ which I need to do on a daily basis, which is however neither obvious nor easy to pull off.
So far my personal “framework” features Normalize.css and a clean slate. I liked Semantic.gs before I was wooed onto the SASS bandwagon, so I think I’m going to try my luck with Susy next. I have also been positively impressed by the featureset of Compass and Bourbon; it’s high time I saw which one would fit me better.
P.S. They do say that putting asterisks in swearwords is akin to covering one’s mouth with one’s hand while performing fellatio amidst a public space on a busy day. In order to prevent myself from falling victim to such a wicked simile, I am compelled to apologize for the asterisks — but not the word choice! — rationalizing their judicious application by my unfamiliarity with this forum’s policy on profanity.
P.P.S. And sorry for the rant as well. I’m, like, just some dude with an opinion, man.
In my opinion, the problem in general (and I say “general” more because I don’t think it’s restricted to CSS frameworks only) is that people more often than not misunderstand the use of frameworks. I feel like what happens is someone says, “OMG, *insert framework* is the best thing in the world and I’m going to use it for every one of my new projects!”. That may not make any sense for your next project, but we sometimes hammer at the square peg to make it fit the round hole over and over and over.
Wordpress frameworks can make sense for certain applications. They were at some point built for one specific project or evolved out of someone’s project niche, right? But there are WordPress designers that base every new project they have on one framework they liked.
I kind of mirror one of the guests of the Shoptalk Show when she said every time she heard ‘framework’ she internally cringed because to her each project should typically be unique because it doesn’t need the same stuff as the project before it.
Yes, frameworks usually have more than you need, but that’s because they’re built to solve multiple problems. Many of the frameworks we know are young, and need to do a better job of being customizable. I’ve used a few built on SASS and having variables and mixins to customize how you use the framework is a big plus in avoiding bloat.
Frameworks can be frustrating at times, I’ve been there too. To me, the benefit of using a framework far outweighs the reasons not to use them.
Ideally speaking there is no point in using a ready-made framework, you should study there code structure & identify at what particular situations you can use it. Other wise a lot of un-used code stays in your application. The application bloats.
What I’ve done is completely separated twitter bootstrap framework into multiple files. Eg. layout.css: has all the bootstrap width classes, typography.css: All default text styling provided by twitter bootstrap, alert.css: all alert messages css, nav.css: all css code which generates menus, table.css: there table formatting css code. & so on…
Now when it comes to integration If I’m to create tabs for a particular module. I take one parent element & append all classes to it. Eg. #sidebar .nav, #sidebar .nav li
This does increase the code length, but I can always optimize it later, cause I know which are the common elements.
So my suggestion would be not to use a specific framework as it is, but to break it & use it.
You must be logged in to reply to this topic.