Why keep inuit design free? Why not just make a default design optional?

[jslegers]

I like your move towards OOCSS. The world really needs more OOCSS frameworks.

I do not, however, understand your choice to keep the framework design free. Why not provide typography, colors and other design related rules as optional modules?

Last week, I released my own OOCSS based CSS framework called Cascade Framework. By splitting the CSS rules based on their features, the code is organised in different modules. Only the core.css module is mantatory and everything else is optional. You can check it out at http://jslegers.github.com/cascadeframework/ .

I recommend a similar architecture for inuit.css .

[jahvi]

I just wanted to share how I've been working with inuit after 5.0, it's not directly related to the discussion but it's still relevant. Instead of including it in my projects like Harry recommends:

/**
 * Setup
 */
@import "vars";
@import "inuit.css/inuit";

// My custom styles

I just include the styles I want and replace the rest with modified versions that suits my style like:

/**
 * Generic utility styles etc.
 */
@import "inuit/generic/mixins";
@import "inuit/generic/normalize";
@import "jvs/generic/reset";
@import "inuit/generic/clearfix";
@import "jvs/generic/shared";

This for me is the best of both worlds since I don't have to edit core inuit files, still include it as a submodule and reduce the overall size of my stylesheets since I don't include the stuff I don't want instead of overriding them.

My point is that instead of leading a crusade trying to force my opinion into the project I chose to adapt the framework to my needs instead and call it a day.

[SteAllan]

@jslegers I'm confused. Are you trying to get people to use your own framework or are you trying to get someone to modify Inuit and make it more like your own framework for you?

Someone call Ethan Marcotte, he'll have a suitable GIF for this thread.

[michaelw90]

I'm just going to throw this out there. Harry, don't take this guy on board, he will fight tooth & nail for IE6 support, and thus essentially bloated code. No, quit it.

[jslegers]

@ csswizardry :

If it weren't for the willfully ignorant, hostile and prejudiced posts by kevva and jbeja, I would not have bothered about this thread after my last response to you two weeks ago.

Anyway, I apologise for the mess this thread has become. As you might have noticed by now, my social skills aren't exactly one of my strengths. I've always found computers easier to communicate with people.

.

.

@ nicoespeon :

When I started building Cascade Framework early 2012, Nicolle Sullivan's project hadn't been maintained for quite a while and basicly still in proof-of-concept stage. Inuit wasn't OOCSS based as far as I know. So there really was a void in the OOCSS realm that needed to be filled.

With the adoption of OOCSS and its design independence, Inuit and Cascade Framework have far more in common than any other framework. I guess it's a naive pipe dream, but in an ideal world see Stubbornella's project, Inuit, Cascade Framework and other OOCSS frameworks I might have missed evolve towards a single project and become the standard of how to write proper OOCSS.

Finally, I'd like to point out that LACKING a feature is a very silly core concept. ADDING a feature without it getting in your way if you don't need it, that's a core concept worth mentioning. And that's what I believe any solid framework architecture is all about : you have a whole bunch of neat features that you can use any time you need it and just ignore if you won't need it, with but a minimal amount of bloat in either case.

I know my attempts at getting my message across are half-baked at best and counter-productive at worst. I'm just trying to do what I can here with my limited social skills.

.

.

@ SteAllan :

I'm trying to explain how Inuit could be made more flexible and more modular. I'm trying to explain how it could attract people beyond its current niche audience by adding an optional default theme and how a modular architecture allows this to be down without impacing Intuit's design independence.

I'm using Cascade Framework as an illustration of how an optimal modularity can be achieved with pure CSS. Personally, I don't really care whether framework users adopt Cascade Framework or whether framework designers adopt parts of Cascade Framework into their own framework. The only thing I care for, is getting my message across of how some innovative techniques I used in Cascade Framework can help designers and developers alike write optimal CSS code.

.

.

@ michaelw90 :

You raise a valid point regarding IE6 support.

IE6 support was still relevant when I started writing my first CSS framework in 2011. I decided to keep supporting IE6 when I started building Cascade Framework because the boilerplate code I took from my first framework supported IE6 and there really is barely any bloat at all to maintain that support.

Still, I wouldn't support any browser older than IE8 if I were to start building a new framework today and would definitely not recommend any existing frameworks adopting IE6 or IE7 support if they don't support them at this point in time.

In fact, I am considering separating the IE6 and IE7 code of Cascade Framework into a separate module intended to be loaded only for those browsers as I've already done for the icons, considering these browsers are becoming increasingly irrelevant. That would reduce the already tiny size of the framework even further.