Its always good to have options. As much as I'm supportive of promoting your own work its a little bit in bad taste to smash and promote your project one a submission like this.

Whoops. I didn't mean it in a negative way - I was hoping that the creator could mention some other advantages of using Picnic.css that I missed. I've edited the comment to focus less on the downsides of Picnic and instead focus on the differences of Picnic and Min.

You mention IE5.5 support four times on your homepage. Nobody is using IE5.5 anymore, so that's not an attractive selling point, and slightly odd that you think it might be a selling point.

The Picnic thing has "subtle animated buttons" which may be appealing to some looking for a certain design edge out of the box.

Personally I roll my own everything, I don't use grids or bootstrap, so not sure why I'm even looking at this thread.

I'm not the typical frontend developer though apparently. Div class="row" is not something you'll see in my code, ever. I'm not going back to table layouts by faking rows and columns with divs. That to me is working against the grain of HTML and CSS. When you start working *with" the grain, with the native behaviour of HTML elements, suddenly a lot more is possible and easier to accomplish when it comes to responsiveness and compatibility. But anyway.. carry on with your "not table based" layouts!

> I'm not the typical frontend developer though apparently. Div class="row" is not something you'll see in my code, ever. I'm not going back to table layouts by faking rows and columns with divs. That to me is working against the grain of HTML and CSS. When you start working *with" the grain, with the native behaviour of HTML elements, suddenly a lot more is possible and easier to accomplish when it comes to responsiveness and compatibility. But anyway.. carry on with your "not table based" layouts!

Interesting. As somebody who loathes front-end development, I'm curious to know how you work against what I consider to be the shameful lack of support for laying out elements on a page in a coherent way (something which has been present in widget toolkits for fat clients since forever). I still remember with dreads the hacks necessary to achieve a three-columns fluid layout in a cross-browser fashion, and I'm certainly not going back to that.

There is no need to litter your HTML with non semantic div tags that just represent rows and columns.

I'm a big fan of using a framework like Susy (there are others as well) that just lets you assign the number of columns an element spans.

Something like:

.logo { span (3 of 10); }

nav { span(7 of 10); }

So you can get columns without touching your HTML.

Interesting, thanks.

Thanks for the feedback!

* Although "nobody" (if parts of China and governments are nobody) uses IE5.5, plenty use IE6, IE7, and IE8, which aren't supported by many CSS frameworks.

* Min also has subtle animations - only of background color though. I used to have more 3D-looking buttons but those were criticized for being too prescriptive - which I agree with; IMHO you shouldn't be able to tell what CSS framework a site uses by looking at it.

* You have a really interesting point about grid systems and table-based layouts. That's something I'll have to come back to when I'm slightly more awake.

@exodust I'm interested in digging into _with the grain_ web authoring as you say. Checked your profile but didn't find any links. Can you pass some along to share the approach?

I'll hold off sharing links but will give you something much better... my approach and whacky theories.

TL;DR - I focus on the creative layout potential of html documents. I avoid abstraction layers that force dependencies between unrelated components that may inhibit layout control and design. To use css grid frameworks in production is to me like leaving the scaffolding on permanently and calling it a feature of the building. It's like leaving your camera on fully automatic, never taking advantage of aperture.

I need confidence in the HTML/CSS foundations. When kept as a "single column" the whole way, with rows or bands of div modules stacked, and whose inner divs don't share vertical alignment connections with any other band or row, suddenly you have the freedom to explore ideas on the page with as much or as little inter-connections as you design. The requirement of course is that you enjoy the craft of HTML and CSS.

"Alignment" is not hard. You don't need to enforce new structural rules simply to get things to align. A lot of developers do like that grids do that work for them. But I don't, and it's probably a personal preference, and also depends on the project.

I find grids afford less scope for change later. Sure, you can "add new content" but with questionable precision in placement. If nobody cares, and it saves you time, then do it. I just don't do it.

It's how my brain likes it. And I really enjoy using divs in combo with positioning in combo with floats and fluid control. It's fun, healthy and good technical investment to construct the detailed behaviour of your responsive template, to own the template is to trust. Grids take away the fun of having page elements do exactly as you wish. Because you're permanently compromising, you cease to notice you're compromising as "the grid" becomes the norm.

There's a forever "don't forget the grid" question mark hovering over your shoulder, and over the designer's shoulder. "But we can't break the grid" is an awful discussion to have with designers.

There's personal preference at work here, and I prefer unlimited publishing and html design freedom. Not that my job in the corp environment always offers that! With incredible CSS technologies available, I don't want to cage them up.

Sharing an approach and "whacky theories" isn't better than simply showing your work. If it's truly as good as you describe, it will stand on its own feet.

Unless it's something your client doesn't wish to share I don't see why you're secretive about your work. Looking at your post it seems you're very proud of your creations.

And while using grid frameworks is restrictive it's absolutely not like leaving the scaffolding on permanently. If you do that it's immediately visible by any passer-byes. Layperson visitors will have zero idea that a particular grid framework was used even if they viewed a source code.

I'll codepen it sometime, as things should be clean to demo specific structure approaches. The corporate clutter that sits on top and within the pages I make may confuse analysis of the core point I'm getting at.

Besides, the website look and feel and even the way it responds is only a fraction of the point. Maintenance, expandability, developer accessibility, technical debt, complexity, dependencies, workflow. All come into play when it comes time to meet the brief, which might come from someone with big visual curvy, crunchy ideas and lots of money.

I'm not trying to sell you something, duckmysick. I'm rationalising my technical method which doesn't involve grids - even if the designer has used one. I understand I can't qualify anything here, I'm cool with that... just chattin. I'll make a note to send and add to my profile a a codepen of what I'm talking about. It's a template I like to call... it has no name because it's just HTML and CSS! Whoever made HTML and CSS can take the credit.

I'm fine with that. I'm not the kind of person who takes everything at face value. While written rationalization work on me to a certain point (you did intrigue me with your approach) I need to see, hear, touch, look under the hood, view the source, run a simulation, and play with a "thing" to be fully convinced.

But that's just me talking and it's selfish. If it works for you then it's fantastic! I'll keep an eye on your codepen because I'm still curious.

Nuts to those calling bad taste: if I had a competing framework I'd be making it part of the conversation, too. Besides being tiny, how does Min stack up against Picnic, owenversteeg? I expect a bias opinion, don't worry ;)

Thank you! At least one person doesn't think I'm a "complete tool" :)

Personally I think Min's largest advantages over Picnic are:

* more features (button sizing, messages, input addons, 12-column grid instead of 6-column grid) * vastly better browser support (not only does Min work on IE5.5+ but also it is tested across hundreds of browser and device configurations before each release) * Unprescriptive - it's incredibly easy to override Min's styles and turn it into something else while still making use of Min's extensive testing and features. With Bootstrap you have to use !importants and strange selectors; with Min overriding things is easy as pie. * LESS/Sass versions * An icon-set that works out of the box

Your points on Bootstrap customization - are those for v2 or v3? I have used v3 and customized I a lot by just overriding the variables and using the mixins.

Truth be told, I didn't know Min when creating Picnic, but I loved it when I saw it and will try it for sure.

The main point of creating Picnic CSS was to make a more complete and semantic version than Pure but not as large as Bootstrap. Also, adding some interaction like pushable and toggable buttons, hover states and responsive navbar which were traditionally done with Javascript.

These are the pros I think from Picnic over Min:

* <input> actually has some light validation. This is not yet in the DOC though.

* Forms are more consistent since I've styled all elements to look alike.

* Responsive grid (mobile first).

* Built on top of Normalize, so many of the elements have actually a lot of intensive external testing

* Default <select> that looks nice (couldn't find Min's one so I am not sure whether this is actually something better)

* The invasiveness main advantage is that, with one single line, you have Picnicss already working for you, while in most other frameworks you have to be constantly checking the documentation to see what class names to use.

* Under 1 week of development. This is not a final version, just a point where I wanted to stop and ask for feedback, so I showed it in HN and got better feedback I could ever imagine.

* [opinion] Encourage the use of Fontello instead of the old glyphs

* [opinion] The style in general looks more personalized with Picnic

* [opinion] Not supporting IE5 - IE7. Depending on your audience, this is a pro or a con. I consider it a pro since the statistics (for most America-Europe) tells us that there's almost no one using it, and it cuts a lot of code/testing and allows for using the latest improvements.

And the Cons:

* Buggy. It's a very young project so it's only normal that it has some bugs. I'm fixing them as fast as I can.

* Low browser support. While I wanted to support IE8 initially, I decided not to. This is because my audience is mostly 18 - 30 years old people. However this really depends on your audience so you must test it, but Picnic also degrades nicely in most of the cases.

* Incomplete documentation. There are some things that are not yet documented.

* Incomplete testing. Any help about how to test it on many platforms easily would be greatly welcome.

Note how some of the pro/cons are biased. However I couldn't see you mentioning any disadvantages or limits for Min. What do you think it's lacking?

Another point is variety. It's great to have many different options to choose, and I saved minfwk.com and will surely use it at some point.

PS, I have writen so many times the size of Picnic at so many stages that I've confused everyone. It's actually 2.7kb when minimized and zipped, so only 3 times bigger (;

> I loved it when I saw it and will try it for sure.

Thanks!

> <input> actually has some light validation

I toyed around with the idea of putting this in Min but I figured that with :valid's low browser support and the fact that it's invalid CSS I decided not to put it in Min and rather in a plugin.

> Forms are more consistent

In Chromium on Linux at least there are actually visual bugs with forms - the black dot in the radiobutton is misaligned and the <select> looks messed up in some browser/OS combos.

> Responsive grid (mobile first)

Actually, Min also has a responsive, mobile-first grid.

> Built on top of Normalize, so many of the elements have actually a lot of intensive external testing

Min is tested on several times as many browser combos as Normalize is.

> Default <select> that looks nice

Min 2.0 will likely have a <select> that matches the text field styling.

> in most other frameworks you have to be constantly checking the documentation to see what class names to use.

With Min the class names are extremely simple - .table for tables, .btn for buttons, etc. Fairly standard stuff (same as Bootstrap uses) I think invasiveness is useful for some contexts but I don't think it's the right choice for Min.

> The style in general looks more personalized with Picnic

With Min you have to override substantially fewer styles so I'd say that Min is substantially more personalizable.

Some of Min's cons:

* No Javascript plugins (which I consciously decided against, but many people like them)

* Unprescriptive design - bad if you're lazy, but something I chose to do to avoid the "yet another BS site" phenomenon

* Another commenter made an interesting point about the grid system, I'll have to find it.

I can't edit my comment now but thanks for letting me know the real size.

Anyway, great work for only a week. The invasive perspective is really interesting and I'll have to think about that more.

One reason could be: "Picnic's creator has better taste."

Sincerely, Picnic.css is selling itself better. Min's site doesn't look very good. People aren't even going to care if its semantic or whatever. This looks particularly bad: http://minfwk.com/download.html - a tiny textarea and a giant button piled up, nothing is aligned, etc. And you're trying to sell me grids.

(Sorry for being so hard - I'm trying (and failing) to find a better way to write.)

One answer might be that they sell it a bit better through site design and example.

I've got no horse in this race though

Thanks for the first actual answer! What don't you like about Min's site design?

I also really like what min aims to accomplish. These are my observations and recommendations to improve the site.

* h1 font-size should be around 2.2em. It's far too large at the moment.

* .contain width seems best around 1020px. You want a thinner width to improve readability.

* All buttons and clickables should not shift the page in any unexpected ways. Clicking on the buttons, for instance, go to the top of the page. One solution would be to onclick="return false;" on relevant elements.

* The "Min Basics" sections is a bit wordy. I think there's some superfluous information and I think the word count can be cut in half.

* The Download page doesn't cleanly separate the calls to actions enough for my tastes. I would prefer having a "CDN Delivery" section and a "Download" section. I believe most people who want a minimal framework will know the difference.

* The layout of the "GET CSS" button and the textarea seems...off. The button is too large and the textarea dimensions are, again, somehow off.

Other than that, I think you've done a great job explaining the benefits of your framework, have given a solid overview of is features and I appreciate the humor of the sea monster.

Keep up the great work!

On the docs page, everything looks really big. It's a bit of a nitpick, but I think - in comparison to Picnic at least - it doesn't bode well for the default attractiveness of a site using Min.

The "Docs" and "Download" buttons on the front page have different height and font sizes. (Chrome on android)

This is extremely tacky. Of course you meant to put the framework down - your first statement shows you think this is a competition, and you don't want to "lose"

Your edit is just to try and convince others and yourself that you weren't being a complete tool. (You were).

It seems you had no other intention in your comment than to belittle the authors work and puff yourself up. If you actually thought you could learn something from the author you would have treated them with some degree of respect.

First of all, I waited until two other people in the thread had mentioned Min before mentioning it. Second of all, I think this is an extremely relevant place to mention Min. Finally, I've edited my post more to show how I think Picnic is really interesting and has a cool approach.

Good now?

Oh go soak your head. Commenter points out what they likes about OP's tool, describes their own, and asks for a sales pitch from OP about why someone should use their (OP's) tool. There's nothing wrong with any of this-- why do you think OP posted their framework here if not to receive feedback & have an opportunity to sell their tool?

People complaining that bringing up an alternate CSS framework for compare/contrast in a thread on a new CSS framework need to chill.

Their edited-edited post is much more approachable. Bringing up alternatives is great, that's why I generally bookmark threads like this. Passive aggressive rhetorical questions are not nearly as conducive to productive conversation. I commend them for changing the tone of their post.