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 .

[iparr]

Please don't do this for inuit.ccs. The only reason I use inuit.css is it doesn't make any design choices for me (or my designers!). If you want a CSS framework with design elements then I'd recommend using one of several billion mature CSS frameworks that are laden with design stuff.

[Meroje]

Do you have a point for this, or is it just free advertising for your framework ?

[jslegers]

@ Meroje :

As I said, I believe the world needs more OOCSS based frameworks. I support Inuit's adoptation of OOCSS.

I do, however, see no technical arguments for not including design in optional modules. I also don't like a framework to make design choices for me, but some people do. By making design optional rather than leaving it out or making it mandatory, you can increase your user base and keep people on both sides of the fence happy.

@ iparr :

If you keep design OPTIONAL, there should be no impact whatsoever when you leave out design related code. You have the best of both worlds.

[kevva]

inuit.css isn't intended to be a full fletched CSS framework with theming included, may it be optional or not. This is merely a skeleton which users should build their theme upon, and that's what makes it good.

You could however build a theme upon inuit.css and publish it yourself rather than creating a whole new framework.

[csswizardry]

The problem/complaint with most CSS frameworks is that they’re not actually frameworks, they’re component/GUI libraries, and therefore require lots of deletion, modification, etc in order to get them how your project actually needs them.

inuit.css doesn’t (and never will) include a GUI layer, because any decent framework (in any language, I’d argue) does the repetitive heavy lifting, architecture and foundation layer, and then moves out of your way to dev on top of.

I am more than open to people building GUI layers on top of inuit.css (as a totally separate project hat simply includes inuit.css (something @sdmix and I were talking about just today)) but the whole point of inuit.css is that it doesn’t provide or dictate any design decisions.

Cheers, H

[jslegers]

@ csswizardry:

We're on the same page, here. Cascade Framework is built with the same architectural considerations. Not only does it not dictate any design decisions, it even lets you choose between eg. a semantic grid and a totally flexible presentational grid.

I just chose to add optional support for eg. typography and a color scheme for projects where you don't need a custom layout or need only minimal customisation. For projects where a fully customized design is required, you can just leave those out.

I see no technical reason why you shouldn't take the same approach with Inuit.

[csswizardry]

I see no technical reason why you shouldn't take the same approach with Inuit.

I see no technical reason why all cars shouldn’t have ejector seats, but ‘could’ and ‘should’ are two very different things.

Non-technical reasons:

1. I’m not a good enough designer to make it happen so:
   • I’d need to add someone to the project who:
     1. I can trust to write production-ready code
     2. Gets the core values of inuit.css*
     3. Can be committed enough to working in tandem and at the same rate as the framework
2. It would increase workload
3. It would mean more things are likely to go wrong
4. I just don’t want to.

* Ironically, that inuit.css should not dictate design.

More on point 4: the only reason inuit.css exists as it does is because I believe that a decent framework (note, not library) does’t impose itself. A CSS framework that provides design imposes itself a lot. Literally the only reason I made inuit.css the way I have is so that it doesn’t make any design decisions. I do not want to add any design to inuit.css.

[jslegers]

1. I loosely based Cascade Framework's default theme on Bootstrap's look-and-feel for that same reason. I'm considering adding other themes for future releases, though, to avoid people wrongly assuming it's just a Bootstrap clone.
2. Adding a theme + demos based on the theme does add workload initially, but can significantly reduce workload later on because it makes testing the framework a lot easier. Additionally, it makes your framework easier to learn, because a couple of demos often say a lot more about how something works than just reading the code.
3. Adding a theme + demos can make it easier both for yourself and others to spot errors.
4. I totally understand that you don’t want your framework to impose any design decisions. I couldn't agree more with you on that. I'm just saying that that strategy is perfectly compatible with offering an optional theme. I couldn't stress the word "optional" enough, here.

Anyway, it's your framework and thus up to you what you do with it. I'm not going to continue trying to convince you.

[stefsullrew]

Dear gawd - please keep bootstrap out of all this. I am SO happy to be rid of it. I love making my OWN theme, choices, and everything... here and now. Inuit gives me structure only. Thank you, Harry (and friends)! :) Let's please keep it that way. Anyone that would love a theme — please go play with @jslegers ... (Have fun kids! :))

[jslegers]

@ stefsullrew :

You just don't get it.

I also prefer to make my own project specific theme, choices and everything.... here and now.

That's why I made most features in Cascade Framework OPTIONAL.

Both Bootstrap and Inuit impose what's good for their users on their user. Cascade Framework gives them freedom. Cascade Framework lets YOU choose what YOU want when YOU want it. If YOU want a default theme, YOU decide to include it. If YOU don't want a default them, YOU can leave it out.

I recently did a fully custom design based on Cascade Framework, using only the framework's core module, typography module and responsiveness module, which comes down to a mere 3,9 Kb after minification and Gzip. Custom CSS ended up being no more than 2,4 Kb, making the entire CSS for the project smaller than 6 Kb.

Feel free to explain how Inuit can do better by not including a default theme.

[iparr]

Hey, also whilst you're at it can you make inuit.css a full CMS? I don't see any technical reason why not. It could be optional. People like CMS's. It'd be nice to have this option.

[jslegers]

@ iparr :

Every project has different requirements.

Sometimes you need a totally custom design (often the case for web sites) and sometimes a generic design is enough (often the case for web apps).

Sometimes you need a very specific typography and sometimes you can use your generic Arial / Helvetica / Vendana font.

I prefer to have a CSS framework that can be used on every project and let's me choose which approach I take. I don't want to choose between bloated projects like Bootstrap of Foundation that force me to overwrite every aspect of their layout if I need something custom or a project like Inuit that gives me no design whatsoever and forces me to look in the code just to get an idea of what features it has. I also don't want to choose between supporting old browsers or going responsive.

That's why I created Cascade Framework. Inuit seems to be based on a philosophy very similar to Cascade Framework, but offers less flexibility, less modularity and less freedom. I regret that, because I do really like the principles behind Inuit and would prefer to see both frameworks growing closer to each other rather than competing with each other.

[csswizardry]

Hey, did someone mention Cascade Framework? sigh

You made a thing, I made a thing. People use my thing for reasons outlined – at length – above. People use your thing for reasons you have outlined above.

I […]would prefer to see both frameworks growing closer to each other rather than competing with each other.

I really don’t know what you’re after, I’m afraid; you keep saying how your thing is great for your needs (presumably meaning that you use it…?) so why do you want my thing to be like your thing that you already have? Surely their difference is their selling points, so why try make a (currently) more popular framework similar to your own?

inuit.css shall remain design free, and no amount of Cascade loving will change that I’m afraid. The inuit.css community (albeit small) share my opinion, and most of the positive feedback I have ever received for the framework is that it keeps out of your way; I know I could add an optional design layer, but inuit.css does one thing and one thing well.

[sdmix]

Wow this seems to have gotten a little out of hand so it seems.

inuit.css at it's heart is fantastic and the principles that Harry has enforced on it are great. Adding themeing to this deters away from what inuit.css was built for. As I am more of a designer than a developer, I love the fact that inuit.css is a blank canvas allowing me to build my own designs on top of the structure the framework puts in place. As Harry has explained above the reasons why he has not incorporate a theme (optional or otherwise) into it is pretty clear and that adding a theme to the default inuit.css pack would cause a lot of disruption. In my eye's, it definitely wouldn't be worth it.

Saying that however, inuit.css is open source and free for people to fork and add their own stuff to, and there is nothing to stop anyone creating 'plug-ins' (I use the term loosely here, it would be an entirely separate project, which just uses inuit as the structure) for the framework. Like Harry said above, me and him had a conversation about doing this yesterday, something I will be looking into in the future.

Like it's been said above, every project does have different requirements and that's probably where plug-ins (again, used loosely, maybe the term bolt-on's would be better for what I'm trying to say) would be a much better way to go about this sort of an issue anyway, at least that way, people will be free to pick and choose the bolt ons they need for the project they will be using inuit.css for.

Anyway, I think its best if we all just agree to disagree on this one, everyone has their own opinions on what should be in certain types of frameworks and I don't think this is the best place to try to start convincing people they are wrong.

[jslegers]

@ csswizardry & dmix :

This cartoon is a good illustration of one of the things I don't like about open source. There are many people with good ideas, but everyone seems too myopic to collaborate with others who also have good ideas that are often very compatible. So, everyone just goes their own way and does their own thing, leading to thousands of plugins, frameworks and what-not that do the exact same thing slightly differently.

I started working on Cascade Framework a year ago because all of the frameworks at the time were lacking either in cross-browser support, flexibility and/or modularity. It was my way to show that you can both support IE up to IE6 AND support responsive behavior, you can both be minimal and feature rich, you can offer both a semantic grid and presentational grid, you don't need to force people to pick a grid with a specific number of columns, you don't need to force people to pick a specific design, etc. I wanted to show that optimal flexibility and modularity can be compatible with both feature richness and a small footprint.

During the year since I started working on Cascade Framework and the time it was released, I noticed a significant improvement in Inuit with its adoptation of the OOCSS framework. I see a very strong match between the design agnostic philosophy behind Inuit and the equally design agnostic philosophy behind Cascade Framework and think it would be much more reasonable to learn from each other's approach and evolve towards one another's approach than to compete.

We need standards for what a solid CSS framework should be like. IMO, Bootstrap and Foundation both fail as suitable candidates for reasons mentioned hereabove. IMO, an OOCSS architecture and design independence are two essential criteria and only Inuit and Cascade Framework offer that afaik at this point in time.

[csswizardry]

…everyone just goes their own way and does their own thing…

Yep, they create their own framework, kinda like you did…

I started working on Cascade Framework a year ago…

inuit.css is almost two years old, and you didn’t put Cascade on GitHub until last month. If you were all for the combining efforts you would have likely:

1. Put your work into the OSS arena far sooner, or…
2. Begun contributing/suggesting these ideas to other frameworks sooner.

I wanted to show that optimal flexibility and modularity can be compatible with both feature richness and a small footprint.

And I hope you are successful, that your framework gets its due credit on those merits, and that it can use them to set itself apart from less capable competitors.

During the year since I started working on Cascade Framework and the time it was released, I noticed a significant improvement in Inuit…

It is fair to say that inuit.css has only become ‘decent’ in the last 6–9 months or so, yes.

[I] think it would be much more reasonable to learn from each other's approach and evolve towards one another's approach…

Then feel free to fork inuit.css and add a design layer in a new offshoot of the project.

…than to compete.

Considering I do not want/am not interested in the additional feature(s) you are suggesting (nor are the inuit.css community) then I think that compete is all we can do.

We need standards for what a solid CSS framework should be like…

And I’m willing to bet you think that Cascade is ‘that’ standard…? You have to remember that neither of us are speaking from impartial standpoints.

…an OOCSS architecture and design independence are two essential criteria…

And inuit.css nails it; it keeps design well away from the framework. inuit.css is designed for people who design. Bootstrap and other GUI libraries (and, arguably, the with-design version of Cascade) are intended for use by developers who need a hand with the entire front-end.

---

I’m honestly not sure what more I can say here, so I’m afraid I will likely ignore any further activity on this issue.

Have a cracking day :) H

[jslegers]

@ csswizardry :

I started experimenting with designing the perfect CSS framework architecture in 2011 when Blueprint was the standard and Bootstrap and Foundation were yet to be released. As I'm doing this kind of stuff in my spare time, it took me two years to end up with Cascade Framework, which was preceded by the alpha-release of another framework about a year earlier.

My first attempt at making a CSS framework had the very purpose of merging existing standards rather than inventing my own. As I was doing my research, Bootstrap 1 was released. I decided it was a reasonable idea to merge it with jQuery UI's CSS framework.

I wanted to reduce the redundancy and eliminate conflicts when combining both projects, as well as add IE6 support to Bootstrap's layout. I released a very alpha-state version about a year ago and labeled it "jQuery Bootstrap". You can find the demo of the jQuery UI feature at http://jslegers.github.com/jquery-bootstrap/javascript.html .

I abandoned the project after Bootstrap 2.0 had been released. One reason was all the work it would take to update the project to the new features. The main reason, however, were the restrictions of both jQuery UI and Bootstrap at the architectural level.

I never like the idea of generating static HTML with Javascript, which jQuery UI relies upon quite heavily. Not only does this give jQuery UI a much too heavy footprint, it significantly restricts you in how you design your UI elements. And then, of course, there's its ridiculously verbose naming conventions.

Bootstrap was lacking mostly in terms of modularity. So was Zurb Foundation, which had been released by then as well. I very much liked Nicolle Sullivan's OOCSS and Jonathan Snook's SMACSS approach to writing modular CSS, but Jonathan never released a framework and Nicolle's OOCSS framework never moved beyond a proof-of-concept stage.

Cascade Framework is intended as feature rich framework capable of competing with Bootstrap and Foundation in terms of features, but with a fully design agnostic OOCSS/SMACSS architecture and cross-browser support up to IE6. I built is precisely because I didn't like the standards that were Bootstrap/Foundation and jQuery UI and saw no way to move towards a better standard without starting something from scratch.

And while I may be setting my own standards, I borrowed heavily from Eric Meyer's reset and Nicolas Gallagher's normalize.css, Chris Coyier's grid architecture ( http://css-tricks.com/dont-overthink-it-grids/ ), Nicolle Sullivan's grid architecture and media object ( http://www.stubbornella.org/content/2010/06/25/the-media-object-saves-hundreds-of-lines-of-code/ ), the semantic grid's grid structure, etc. From Bootstrap, I only borrowed some of its look-and-feel (which I still like).

Cascade Framework incorporates all the most interesting architectural feature's I've encountered ever since I started developing the framework about a year ago, which IMO gives you optimal flexibility, optimal performance, optimal modularity and feature richness while having but a tiny footprint of between 2,5kb and 10kb minified and gzipped, depending on which features you want to use.

As Cascade Framework shares a lot of architectural concepts with the current version of Inuit, I guess I was hoping for some way to collaborate... to share ideas... to grow independently towards a common standard.

From an architectural point of view, Inuit and Cascade Framework have more in common than what separates them.

[stefsullrew]

@jslegers So the thing is — it's awesome you did all that. I was doing the same thing when I happened across inuit.css.

After using Bootstrap (for the first time in my life ever using a framework—I used Bootstrap due to some time constraints), I was SO happy to rip it out of my project. Overriding the design decisions someone else had made was a real pain—and caused a lot of extra CSS.

While I understand yours are "optional" (awesome—seriously), I don't want that option. And more than likely, others that are here at inuit.css feel the same—thus the pushback. So we're not AGAINST what you've done, we just don't see a reason to merge it together with what we enjoy about this framework—it's a skeleton that gives us the ability to do ALL the design stuff ourselves.

That said, I imagine some people that would love design help have seen your posts here and are happily checking out Cascade... so I imagine your work here is done. :) Cheers and good luck!

[kevva]

sigh

[jslegers]

@ kevva :

sigh indeed.

I fail to see how you can possibly oppose more freedom, more modularity, more flexibility, less code bloat and more design independence... because THAT's what I'm arguing for.

[kevva]

I don't oppose anything. Less code bloat? That is your opinion. I saw plenty of it in your framework.

[jslegers]

@ kevva :

The version of Inuit used at the project's homepage is 13,7 Kb minified and 3,6 Kb with additional gzip. As far as I know, the framework is not supposed to be split up into parts and thus no leaner versions are available.

A minimal use of Cascade Framework (just the core module) is only 8,3 Kb minified and 2,6 Kb gzipped, while offering support for far more UI elements than Inuit.

The build I'd recommend for most responsive projects is 13,8 Kb minified and 3,9 Kb gzipped, It adds typography and default responsive behavior.

So basicly, the recommended version of Cascade Framework offers more feature with about the same size after minification... and the minimal version is 30% or 40% smaller than Inuit (depending on whether you use Gzip).

While I won't argue that Cascade Framework can't be further optimised, Inuit is definitely more bloated by offering less features and worse browser support with the same footprint.

[kevva]

I'm not talking about the size of it, it's not super important. I meant the code quality and structure wise.

[jslegers]

@ kevva :

Code of Cascade Framework is intended to be optimal for performance, size and modularity.

Size is important on mobile. Many mobile devices have but limited recources. Being able to cut down your framework size by 30% to 40% is therefore a very valuable improvement if you're targeting mobile browsers.

Nevertheless, I'm open to suggestions. Feel free to explain what makes Inuit superior to Cascade when it comes to code quality. I might learn something.

[kevva]

@jslegers, the size difference between 3.6kb and 2.6kb is trivial. There are bigger assets like images that should be the focus point when optimizing for mobile devices.

[jslegers]

@ kevva :

You're absolutely right about optimising images. Although this is an issue completely isolated from the framework's code, I should have used JPGs instead of PNGs for the pictures in my demos. I just fixed that.

And ideally, a production site should use responsive /adaptive images. Cascade Framework doesn't include them only because I want all components of the project to work locally, which isn't possible when using responsive images.

I fail to see how inuit does better, though. These issues are specific to the demo site only, whereas Inuit doesn't even have a demo site.

With regards to framework quality, you don't have a point whatsoever.

[kevva]

@jslegers, I was talking about images in general. You was making a point about how size matters. It doesn't, not when we are talking about a few kilobytes.

[jslegers]

@ kevva :

500 times a couple kilobytes matter.

Anyway, I still don't get your point. You were comparing both frameworks in terms of bloat after I said that Inuit is too bloated. You seem to be beating around the bush by picking the most completely irrelevant points.

[jbeja]

"inuit.css is designed for people who design", I think that you pretty much won the whole discussion with that statement :).Cheers Harry i love your framework.

[jslegers]

@ jbeja :

Cascade Framework is designed to be optimal for BOTH people who design and people who program.

Cascade Framework is designed for those who don't like to use frameworks because they're too inflexible and offer too little freedom.

I still fail to comprehend how less flexibility and less freedom are supposed to be the prefered choice.

[Anderson-Juhasc]

LOL

[jjcall]

I really dont understand the point of this thread anymore...

[jbeja]

@jslegers less flexibility and less freedom? Ok , then way you are still so hardly preaching your framework, let me be free , let people be free from this uneeded, pointless, absurd rant. Let me have the flexibility and freedom of choosing my own tools , you don't see to understand opensource at all, in fact your at like a hypocrite that try to monopolize it with your own twisted view. The more that you are promoting , defending and compering your product against others so blatantly, the less i even want to click the link to it. Cheers.

[jslegers]

@ jbeja :

Maybe I'm getting a bit too emotional here, but I find it utterly frustrating when people make totally uninformed and hostile statements like the one you made in your previous post and some others have made before you.

Having mandatory features is never a good thing when a significant part of your target audience rather goes without those features. Making those features optional is a way to please that part of your target audience as well as those who do care for those features.

This is the philosophy behind Cascade Framework. Cascade Framework puts YOU in control. It allows YOU to choose which features you include in your project and which features you leave out rather than making that decision for you.

Inuit does not grant you that freedom and my OP was merely a humble suggestion to provide that freedom with respect to a default design.

[jslegers]

@ jjcall :

The point of the OP was to suggest a feature based split of the code and an optional default theme.

The first is relevant to all, because it improves the modularity and flexibility of Inuit. It allows you to be more selective regarding which features you include or leave out in your project.

The latter is useful for people who want to make web apps and don't need much of a custom design. The common argument against this feature seems to be that those using Inuit are mosty designers who don't care for that feature. This is a pretty silly argument, though, as adding this feature really has no downside whatsoever for that target group while opening up the framework to a whole new target group.

An additional benefit of having an optional default theme is that the author can use that theme to demo the features of the framework. Many people prefer learning how to use a framework or library by studying the demos rather than reading the code. Some even prefer it to reading documentation. People who are reluctant to use Inuit due to the lack of both demos and documentation will also be more inclined to use Inuit with a bunch of demos to illustrate how it works.

So basicly, I'm suggesting two architectural improvements that have no negative impact whatsoever on the current use base while improving the framework's flexibility and its modularity as well as being able to draw in people currently disinterested in using Inuit.

[jjcall]

@jslegers based on all the reply's, its seems to be something the maintainers and users of inuit are not interested in. You created your fancy framework to address this problem... use it, no need to keep blasting this thread with why inuit should adopt some of your frameworks ideas.

[rawdiggie]

@jjcall Thx for that one.

[jslegers]

@ jjcall :

As I believe I've made my point pretty clear to those who aren't totally prejudiced towards taking everything Harry says as gospel, I would agree there's little left to be said.

I just have a lot tolerance for irrationality and ignorance. Folks like jbeja and kevva really get on my nerves with their obviously prejudiced and totally uninformed statements.

[jbeja]

@jjcall 1+

[Meroje]

Harry is the only maintainer, he said no. Why do you even bother with others ?

[jslegers]

@ Meroje :

... because his arrogance seems to blind him. Multiple voices are more inclined to sway his opinion than a single one.

[jbeja]

@jslegers Is scary how people can't even look themself in the mirro. If you have such tolerance for "irrationality and ignorance".Then why you are even addressing us like that? .I said what i need to say as all the replays above, even thought Harry the creator and only mainteiner of this wonderful tool lost all interest and atoned to all your questions, you still have the pointless idea of spamming this thread, who is being irrational and ignorant and RUDE now ?

[jslegers]

@ jbeja :

Call may me naive, but I still believe the power of reason is capable of convincing at least some individuals.

[jbeja]

@jslegers Yeah that right but only when you have the reason or atleast a well orchestrated lie. In conclusion all of this is caused by the fact that you are in the wrong place and time.Cheers

[jslegers]

@ jbeja :

I thusfar haven't encountered a single rational argument against the position I've taken.

I've only encountered highly prejudiced, irrational arguments.

This discussion reminds me of one of my favorite movie scenes ( https://www.youtube.com/watch?v=eJaIHQSOfgY ).

[csswizardry]

You suggest something, which you are fully entitled to do. You gave sound reasoning and explanation, which I (aways) appreciate. I declined, as I am fully entitled to do. I feel I gave adequate, polite and detailed reasons as to why.

Your reasons may have been sound, and your initial tone polite, but the features you suggested were not – I feel – in keeping with my ideals for my project. Although, in theory, more options are always nice, sometimes it’s better to do one thing, and one thing well. I don’t doubt that your idea(l)s are sound, but I do not think they are suitable, nor what I want, for inuit.css.

Since, you have beaten the same drum over and over and over and over until the point where I can’t even see any reason, I can’t take you seriously, and I completely gloss over any points you are making. You have undermined your own points by relentlessly repeating them to an audience who has made themselves clear. Further, your tone has become more hostile and, dare I say, offensive:

…his arrogance seems to blind him.

I, and others, have made my opinions clear, and if they aren’t what you want to hear then I apologise, but please… can you drop it now? I’m afraid if this gets dragged on any longer I will have to (work out if you can) block you from discussions on this thread/project; not because I want to silence or quash difference in opinion but because, seriously, I heard you the eighth time.

Best, Harry

Edit: May I also please quote you from over a fortnight ago:

Anyway, it's your framework and thus up to you what you do with it. I'm not going to continue trying to convince you.

[nicoespeon]

@jslegers - Are you guy posting on every OOCSS related open-source project to advertise your framework?

Considering all the points which has been explained above, I cannot understand why you persist this debate for any other reason than "speaking about the framework you did" by created kind of debates on other populars projects.

The thing is that inuit.css was build with a free-design vision. That's one of the (maybe THE) core values of this framework. This is the reason why I use it. It has its community, people who choose this framework because of its unique orientation. Hence, changing that fact by providing a design orientation isn't relevant. Even if it would be OPTIONAL, this is not the point with inuit.css.

The thing is, even if this discussion is quite interesting (different approaches for OOCSS frameworks), I found inappropriate the way you try to advertise your framework by opening issues and commenting others projects as you did the same for stubbornella's OOCSS project, for the OOCSS article of Smashing Magazine you commented and this issue.

Well, your framework, your project, is quite interesting. But I guess there might be better way to speak about it without polluting every popular projects pretending to create a debate as it doesn't make sense to ask others projects to do just the same you did. Keep your specific added value which justifies the need of your framework instead of inuit.css or Bootstrap, developers will do the choice of the framework which suits to their needs.

[cdibened]

@jslegers How hard is it to fork and add your own stuff on top on inuit.css? Please stop trying to instill your ideology on others. Harry has done a great job and has repeatedly stated why it is, how it is. No more, no less. He sure has shown a lot of patience towards you, as it seems like you are just trying to pawn your creation and might I add, a hint of trolling.

[sturobson]

@nicoespeon look at this - https://twitter.com/johnslegers/status/319815656478498816 - I think you may have a point about @jslegers reasoning for starting this issue

[tomhermans]

indeed sturobson, all the way down here, I thought "why is all this selfpromo still here" ? Is this a new way of forking ? Forking the userbase ? The reasoning of Harry WHY he doesn't add a design layer, is the only valuable part here.