First of all, I want to say that I like the vibrant colors, small size, and checkable buttons. Smaller (and JS-less) CSS frameworks is something that I've been crusading for for years now.
Secondly, I'm the creator of Min (http://minfwk.com), a fellow small CSS framework. Min is only 995 bytes - 5 times smaller. It also is more widely used, has feature parity with Bootstrap through the Min Bootstrap plugin, supports IE5.5+, is valid CSS, and doesn't have browser bugs. There's also an easy way to migrate from Bootstrap to Min (the Bootstrap->Min converter.)
Why would someone use Picnic.css rather than Min? I'd like to see the advantages of Picnic.css straight from the creator, since it seems you're answering questions in this thread. It seems one of the advantages you're touting is the "invasive"ness, which is a cool approach (I don't see Min taking that approach for various reasons but I think it can be a better choice for many use cases.) Another seems to be the grid naming system. What other things would make someone prefer Picnic.css for their project?
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.
* 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.
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.)
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.
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.
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.
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.
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.
* Keyboard accessibility is completely busted (other comments have pointed this out).
* Color contrast doesn't meet WCAG 2.0 AA (Bootstrap is bad here too).
* The <label class="button"> should have aria-role="button", tabindex="0" and a bit of JavaScript to trigger a click event when the space or enter keys are pressed while it has focus. This is for keyboard _and_ screen reader accessibility.
* The checkboxes and radio buttons need similar ARIA, tabindex and keydown tricks (because the inputs themselves are hidden [stupidly, in my opinion]). Again, this is for both keyboard and screen reader users.
Bootstrap commits a lot of the same mistakes with their button.js component (although it looks like it's improving). See this post [0] for details (disclaimer: I wrote it).
1. I opened the issue, this definitely needs fixing.
2. Can you share a tool (preferably online) where we can see the color contrast problem, please? How did you check that they didn't meet WCAG 2.0 AA (so I can check it and fix it).
3. Not really CSS problem
4. Not a CSS problem. Anyway, I think that something can be done with CSS though.
This is a pure CSS tool, so the html and javascript problems should be addressed by the people using the tool, not by the css itself.
So please, don't use it, or help me improve it until it can be used. If you see any other problem, don't hesitate to comment, open an issue in Github ( https://github.com/picnicss/picnic ) or just send a small push request fixing a problem at a time (I'm trying to address every problem by myself, which is daunting).
For contrast, maybe check out either HTML_CodeSniffer [0] or Vision Australia's Colour Contrast Analyser [1]. Also this Bootstrap issue [2], which references a couple more.
The problem with being pure CSS is that you're hiding inputs and styling their labels to appear (visually) as their replacements (against the labels' semantics).
If you're going to hide the inputs (in the three cases of labels with class "button", "radio" and "checkbox") and style labels against their semantics, you need to use JavaScript to fix the accessibility issues this introduces. I don't think there's a non-JavaScript, non-ARIA solution to the accessibility issues (other than not hiding the inputs in the first place).
So I think there are three options:
1. Hide inputs, style labels (status quo) and use JavaScript, ARIA, tabindex, etc to fix accessibility issues.
2. Don't hide inputs, remain pure CSS, avoid accessibility issues in the first place.
I'm with you on the point that accessibility should be a concern of framework developers, but none of those issues should be too hard to tackle for them. Therefore, filing an issue on the Github project would help (at least, more than commenting here), especially because the project is still young.
In my opinion, the only great thing about Bootstrap is the grid system and form styling, the rest is just useless cruft. As a front-end developer, I see the value in Bootstrap and I have used it before, but when installing it as a Bower component, it makes it harder to filter out the crap you don't need like button styling, header styling and other stuff Bootstrap includes that just bloats your CSS. To me, I find Bootstrap TOO opinionated, I spend a lot of my time overriding styles than I do setting them. In the real world unless it is your own project, you are being given designs and fitting the style of a PSD file into Bootstrap can be more trouble than it is worth.
These days I actually use Foundation by Zurb which I think is arguably one of the best front-end CSS libraries out there, it allows greater control and offers some awesome Javascript components. Not only that, it has a great grid system like Bootstrap, but it is by far, the least opinionated and most powerful front-end library out there.
Cudos for trimming the fat and offering an alternative for those who use Bootstrap. My only nitpick is those bevelled buttons don't look very nice and the classes for the grid system using fractions might be a little confusion for some who are bad at maths and fractions (like me). I prefer having the option of putting the number in the class like in Bootstrap: col-md-6 as opposed to using a class called "half"
The best thing about Bootstrap is that it's ubiquitous -- every frontender has heard of it and can easily jump on a project that uses it -- and that there are a lot of integrations with frameworks, like angular-bootstrap or react-bootstrap, that don't tie you to using the stock jQuery plugins.
This framework doesn't have anything that relies on JS magic, like button dropdowns, collapsing panes, etc, which are useful in real-world apps. I certainly wouldn't want to reimplement my own versions for every project.
Bootstrap's cruft is a non-issue if you use the customizer [0], or, better yet, selectively import the components using LESS or SCSS [1].
The JS components are a non-issue, I agree. However, the one problem with customising Bootstrap is if you're using a front-end dependency manager like Bower, as far as I am aware, you cannot easily customise the dependencies in Bootstrap if using Bower or Component. Sure, I could use a custom generated and downloaded version of the compiled CSS files, but then I loose the ability to change colours, fonts and whatnot using variables or the internal helper functions...
I've tried to keep it as tiny as possible with just under 3kb when gzipped. What would you change? What would you add? Any feedback or pull request is greatly welcome! MIT Licensed
Small nitpick, but you should conform your html to something more idiomatic; non-idiomatic code just screams isolation and lack of experience and those spaces between your equal signs jump right out and could scare the user off. Its silly I know, but :/
Fixed? I've always written code that way, even when working with more people. I'll try to correct it to adapt to the standard though. Thanks for the tip.
I wanted to hate on it but I dunno, I might give it a spin. :) I'm mainly interested in your grid naming conventions, as the become very cumbersome in bootstrap.
One thing I didn't see was the ability to add offsets to a grid item?
It was the first time I wrote a grid so they're not perfect nor complete. If you feel inclined, please submit the suggestion in ( https://github.com/picnicss/picnic/issues ) or feel free to push the edit.
Also, and mind you this is JUST my opinion but I don't think the buttons look very attractive. That might be something worth "sprucing up"? Anyway, definitely a cool project and I hope to give it a try.
Here is the thing I would like and maybe I could fork your and just try it and see how it looks. I really like attribute based properties for grid, I think this is great idea. Check it here. I think this could make your framework different from me-too frameworks. I think you could improve on it quite a bit, add optional modules for modal for example, maybe some other elements.
No, it looks fine in the versions of Chrome and Firefox that I'm testing, but not in every browser since this is the #1 issue I've received. I'll fix it within the next 24 hours.
Honestly for most "real" projects, I just use the Bootstrap LESS source files for the normalizer, grid etc. and just compile my own UI components. I believe that for any app to be unique, it has to have its own visual style and when you use the whole of Bootstrap (or just about any other framework) you just can't differentiate yourself. Don't get me wrong, I love these frameworks. I just think they're good for quick and dirty prototypes / open source hacks.
I am still waiting for a customer to tell me they don't like my application because it uses a common UI framework. Not holding my breath. Tech people care about this, but only barely and only very few.
A fresh and engaging UI with groundbreaking ideas and techniques could possibly win you lots of fans but for the vast majority of applications (especially lob or ent) this does not make sense.
Yes, I think web developers are inundated with bootstrap sites but if I am making a site for non-tech people, the odds of them having any clue what bootstrap is, let alone being able to identify its use is very unlikely. At least, that is my calculation.
> compile my own UI components [...] when you use the whole of Bootstrap (or just about any other framework) you just can't differentiate yourself.
If a person isn't able to very easily customize Bootstrap with a minimal amount of CSS, I wonder if they're able to competently create their own front-end framework that works perfectly in every browser on every platform.
As someone who navigates the web primarily with a keyboard, sites that use Bootstrap tend to be more usable than sites that use front-end frameworks that were built from scratch. For example, in my experience, most designers and developers don't use :focus selectors when using :hover selectors because they only think about mouse-based navigation.
> most designers and developers don't use :focus selectors when using :hover selectors because they only think about mouse-based navigation.
I evaluated Picnic CSS just now, and it doesn't use :focus selectors. This is what I'm talking about.
In my experience, usually when developers release a solution (e.g., a framework) that's advertised as a lightweight alternative to Solution X, the lightweight alternative isn't really an alternative for developers who understand why Solution X isn't lightweight.
I tried using Bootstrap and other CSS frameworks and (as mentioned in the comments) I felt like I was fighting the frameworks to get it to do what I wanted to do.
The problem with CSS frameworks is that they are invasive when it comes to writing semantic HTML. As someone who is working on developing semantic HTML and improving the skill, its annoying when you use a CSS framework which it encourages you to perform inline styling.
Layout should be separated from content.
Bootstrap and others is are great for making something quick and dirty. Semantic UI[1] is onto something decent but the issue of inline styling irritates me. Its good that Picnic is taking an approach to use better naming conventions for classes. I think this is a preference thing but I find writing button-one better than writing btn-1. I think its readable, can be understood quickly , easy to pick up if you have been away from development for a while, looks maintainable even for novice developers.
Shorthand has never been my thing, it just adds more complexity and nuisance by wasting time digging into someones documentation to understand whats going on. I would rather spend an extra two seconds writing out a full name rather than using shorthand knowing that its going to make my life easier in the future.
Great work, I'll definitely play with this when I get time.
Minor nitpick with your comments regarding the use of classes for the grid system making your mark-up non-semantic. If you use the LESS or SASS version of Bootstrap and not the pre-compiled version of Bootstrap, you can use the internal grid system functions in place of classes on elements instead, thus making your markup semantic.
I like the intent behind the Semantic UI project, but I feel like CSS preprocessors like LESS and SASS allow for semantic markup through the use of mixin functions out of the box without needing to use anything else.
I think you'd like the bourbon framework, which is basically a way to structure your css and doesn't get in your way. See their grid framework: http://neat.bourbon.io/ and their default style package akin to bootstrap: http://refills.bourbon.io/
I also recommend http://purecss.io/ from Yahoo. I agree that bootstrap is quite heavy and there's a learning curve. I liked purecss because it is simple and does what you set out to do.
I tried this kind of selectors for styling and I don't like it. I can explain why with a question :
What if you want a button that looks like a like and a link that looks like a button. In your case you will have to overwrite "button" selector, which is with very high specificiy and to override the main selector styles.
While it's true that sometimes you want a link to act as a button ( <a class = "button">Looks like button</a> ), I cannot think of the case when you want a button to look like a link.
May I ask, in what situation did you encounter this? I still think this is way too specific (I have never had to do something like that). Picnic lets buttons be buttons, and links be links OR buttons, just buttons cannot be links.
I think in this way you can achieve less bloated classes and better readability. I value that higher than allowing buttons to be links. That's just my preference. Thank you for the insight though, it's a clear and good explanation of Picnic limits.
I second drinchev's comment. You have no way of knowing what all potential contexts people are going to want to use buttons for. Applying styling to the bare element means frequently resetting those styles. It's always better to extend than to reset. I use button elements for any control that is handled via JavaScript. Only a minority of buttons I use are actually for form submission.
The bit with the checkbox then 2 radios is a bit confusing (chrome/android/nexus 5) - at the start there's no check in the checkbox, I tap and it checks, I tap to uncheck and it changes to a light grey check. That gives the impression this checkbox has 3 States and is really confusing. Worse, when I then tap, say a radio button, it goes back to unchecked. My guess is this is just a focus issue but it's definitely confusing as it is.
I'm reasonably sure this is because of the light grey check hover effect you have. I can reproduce on Nexus 7/Chrome in exactly the same way. I get the same effect on my laptop by leaving the cursor over the checkbox after unchecking - although then it's obvious because I've already seen the hover state.
My guess is mobile Chrome is using the hover effect to denote selected - which I guess kinda makes sense. I'd probably just disable that hover style altogether to be honest, Bootstrap doesn't use one and I think that's better.
My first impression of min is that it looks nice. Really, for it's goals, it's pretty tight.
As a branding thing, I'd change that URL. I get that it's short but minfwk.com doesn't really look like "Min Framework" to me. It just looks like a bunch of letters. A domain like mincss.com, getmin.com, minframework.com or something more legible would be better.
> My first impression of min is that it looks nice. Really, for it's goals, it's pretty tight.
Thanks! You have no idea how good that feels.
> As a branding thing, I'd change that URL.
I have had minframework.com for a while and still do, but it seems too long (Right now it redirects to minfwk.com) but I just got mincss.com and I prefer it quite a bit. I'll update Github accordingly. Thanks for the suggestion!
Picnic CSS sets the style of the default elements, while in Pure CSS you have to add them manually as classes. This means that Picnic just works out of the box while Pure is more flexible.
There are some other smaller differences:
- The <select> just looks nice with Picnic in Firefox.
- Picnic relies in class combinations, while Pure relies in long specific class names. Compare <button class = "primary">Test</button> vs <button class = "btn btn-primary">Test</button>
- Pure CSS is surely more solid; it's been created by Yahoo and tested by thousands of webs
Besides of the comment above, please use the one you prefer and fits better your needs. Clean html and out of the box options are Picnic strengths, flexibility and browser support are PureCSS strengths.
Just a comment about the buttons: It feels weird that they kinda "pre-press" themselves when hovering. I guess ergonomically speaking, a button shouldn't move down while it's not pressed. On the other hand, maybe a glow or a subtle coloring could do the trick?
Thats right and also fix a .1em bug that is bothering me when hover. So glow whiter when hover and move when pressed. They are now the way they are because it was based on http://tympanus.net/Development/CreativeButtons/ , but I will also improve it (I just opened the issue in Github).
I really like this, and am considering incorporating it in quite a few sites at this particular moment; so far so good implementation-wise.
A huge plus that makes up for the lack of pre-IE9 Internet Explorer support is the fact that this seems to fail gracefully; since it's "invasive", it leaves behind a relatively-normal-looking site should it not load (tested on lynx and Firefox). This makes me less nervous about deploying it on sites where the target demographic is more likely to use old IE versions (like my own hometown, unfortunately...).
A couple oddities:
* It would be really nice if the hamburger-mode menu pulled its background colors from the non-hamburger-mode menu and/or navbar; that was a bit of a hiccup when trying to change the navigation colors.
* I still can't figure out how to change the color of the hamburger icon. Where is that defined so I can override it and match the rest of a page's text? With a dark navbar background, it's kind of hard to see.
* The thresholds for hamburger v. non-hamburger seem too low; while my testing in Firefox resulted in proper responsiveness to the window width, the page loads as if it's a desktop site on my phone (HTC One M8, any browser), probably because of the high (1080x1920) screen resolution. I ended up manually editing picnic.css in order to adjust the thresholds accordingly (to 1100px for phones and 1200px for whatever's supposed to be the next one; the narrowest desktop monitor width in somewhat-common use nowadays is 1280, so I don't expect there to be very many issues caused by this...).
* Weirdness with font sizes on actual phones (as opposed to resized desktop windows) when font-size is set to 1em (probably a mobile browser quirk, not necessarily something wrong with Picnic); I added a max-width conditional to set these bigger on phone widths (while leaving them at 1em for desktops/laptops, where the screens are bigger and can handle the smaller text).
All in all, not bad. It's already likely going to see use in a couple of my own sites. For someone like me who cringes at the thought of trying to wrangle Bootstrap into doing something useful, this is a breath of fresh air.
Thank you for the interest. I am using it for rapid prototyping and for websites where personalization is not top priority.
* I know... I don't think that's achievable with the structure I'm using though
* In line 690, where it says `border-color: #333;` within `.burgermenu:before,.burgermenu:after{}`. This is due to lack of Android support for the font.
As for the burgermenu, I'll take a look at that; thanks for the pointer. I'm currently playing with this alongside Pure (which I'm also interested in for many of the same reasons - namely, the lack of JavaScript, the small footprint, and not being some giant clusterfsck like Bootstrap and Groundwork tend to be), and one advantage of Picnic in comparison to that is that the menu actually shrinks down to a burgermenu without the need for Javascript (as far as I can tell; with Pure, that doesn't seem to be the case).
CSS/HTML frameworks like these are very well suited for web interfaces running on embedded microcontrollers, where storage comes at premium and design requirements are moderate.
Looking forward to actually trying this in near future!
One thing I noticed missing (or that you should consider) is keyboard accessibility. If I tab through the page, I quickly get lost where I'm at (until I focus on an text input element).
An even lighter-weight alternative: forgetting about CSS "frameworks" altogether. Aside from propping up prototypes really quickly (an exercise made trivial with these help of these little style collections) I just don't understand why anyone would want them in a real app. I've spent hours upon hours fighting the likes of Bootstrap and its copycats. And to what end?
OK, and where do I start? How do I make a pretty blue border around a text input to subtly indicate focus? What's the best gradient / padding to use in such circumstances? What fade in time will looks good? There are so many questions I could ask just about the text input highlighting.
As a back end developer who needs to do bits and pieces of front end stuff, I can see this taking me months (at least) to learn JavaScript CSS, and design to make something as anywhere close to bootstrap. Or I could just use what they have done (and thousands have tested) and save myself a whole lot of effort. And if you have other developers joining the team, at least they will be familiar with whatever framework you are using, rather than some in house crap that someone wrote ages ago, and has now left the company.
I have not looked at the source code for Bootstrap, but if it was crap I assume there would be a ton of articles ranting about like there are for PHP.
So (with Bootstrap at least) I am getting pre-written, tested, understood code, documented code, probably of at least "reasonable" quality, with a community online to help with problems. Does you own code have that? I certainly don't have time to write that stuff myself .
The more experienced I get as a developer, the less code I try to write. People with the "code everything yourself" attitude remind me of when I was fresh out of university, and didn't realise how incompetent I was at the time.
If you're designing sites yourself, I completely agree with you. I haven't much of an eye for design myself and always rely on foundational CSS to take care of these kinds of decisions when I build pet projects; however, I've always worked on teams that have designers who hand me high-fidelity mocks (or at least high-level style guides) that answer these questions. The implementation itself is simple enough once you've worked with CSS long enough.
OK, and where do I start? How do I make a pretty blue border around a text input to subtly indicate focus? What's the best gradient / padding to use in such circumstances? What fade in time will looks good? There are so many questions I could ask just about the text input highlighting.
The thing is, if you actually designed web UIs professionally and didn't rely on these toolkits, you could immediately make a reasonable first guess at all of those things and you'd be doing it in the context of your specific project. The total time to refine everything over the entire development cycle might be a few minutes, and most of that would be cross-browser testing, which obviously for professional work you should be doing even if you're using a toolkit.
I've nothing against toolkits. They can be useful for quick prototypes. They do a competent basic job for in-house tools written by people who aren't front-end developers and just need something that works. But for high-end UI work? I have never written a major professional project that still used any of these toolkits in the final production code.
Most toolkits aren't sufficiently reliable that you can trust them without testing, so you've still got one of the biggest and most tedious jobs to do whether you use one or not.
Often attention to detail is lacking in significant areas. Using a big name toolkit is no guarantee of quality; many of them have absolute howlers on their own demo pages that are immediately obvious in at least one major browser, often just in the visuals before you even start interacting.
But more than any of that, for real projects, you're often going to have branding requirements that will mean extensive customisation. All those default colour and typography schemes aren't worth much. And some all-things-to-all-people toolkit that works great if you use its defaults might be hiding all kinds of limitations if you're not using a flat design, or if your layout requirements are more demanding than "simple responsive grid", or if you want something that works right on mobile or supports proper keyboard navigation or meets accessibility requirements or...
Toolkits are great for basic work, and for a lot of projects that really is all you need, but you don't design a Rolls Royce by picking wheels and bodywork from a catalogue.
People with the "code everything yourself" attitude remind me of when I was fresh out of university, and didn't realise how incompetent I was at the time.
Code everything myself? Unlikely. Code things myself when quality matters and off-the-shelf isn't good enough? Always.
Code normalization: that's the key. Once you've got everything working everywhere via a base scaffold -- the hard part -- then you can very quickly iterate on design changes, or design in general. Bootstrap et al are generally quite easy to tweak once you understand how all of the components fit, and i'm sorry but CSS just isn't fun to have to write from scratch, especially on bigger projects.
IMO, if I were to arrive on a new project and saw the front-end devs reinventing the wheel, it would immediately set off a red flag.
It's fine when you are targeting one browser with a specific version (e.g. developing an internal web application with IE8 baseline). However, when you are building a web application targeting various browsers and versions, there will be subtle differences that may 'break' your UI.
CSS frameworks like Bootstrap provides you with a tested baseline, so you can be confident that the front-end you created will look the same across a wide range of browsers.
Certainly Bootstrap won't be suitable for all scenarios, but starting from a framework is generally a good idea.
My general take on it is: if you find yourself "fighting" the framework, then you probably shouldn't be using a framework.
Many websites have a whole lot of overlap in terms of UI patterns (a nav bar, responsive grids, etc). Is it really necessary for every dev to hand-code that nav bar, or fight with CSS's terrifyingly bad grid support? Not really, which is why these frameworks are nice.
A framework is not only a good way to start. It's also a good way to uniform code, make things easier for new comers (larger projects usually have lots of new people that eventually write code), solve multiple common issues you'd fight by your own (e.g. browsers compatibility), community support and documentation. If you write your own you need to document well all things and things very careful how to arrange css classes to make code reusable and flexible.
Some of us like that you get cross-browser and device tested code that is super easy to use. You can choose what parts of Bootstrap to include in your app, so you don't bloat it.
Would you elaborate what you mean by fighting? Bootstrap is extremely simple to customize and I am no front-end guru.
In my experience, the fighting comes in when the designer (who generally has less understanding of the Bootstrap modules' intended roles) extends an existing UI concept that came out of the box. This is a perfectly reasonable ask on their part- it's a component on our site, why shouldn't we be able to customize it?
A specific example: Bootstrap expects dropdowns to be unordered lists with anchors as the top-level element, so having a fixed-position header as the first item while its children scroll is difficult. If this has been our CSS based on our markup, it would've taken fifteen minutes, because we could have gone in and done a bit of basic surgery on our module, making it more flexible. (This may not be the best example, but that's the general idea.)
But again, in a professional setting I would prefer Bootstrap any day. It looks well done, it's easy to customize, and it has a lot of pre-built components.
Weird, I have the whole Bootstrap kitchen sink on one site and the total CSS weight (including Bootstrap and my own styles) is a hair over 24k. If I actually took the time to optimize out the stuff I don't need, I could probably get it down even further - but I'd have to be in a serious yak-shaving mood.
There's a problem with the options on the dropdown [select] box so that the bottom border is missing when the dropdown is active. FF31.0 Kubuntu; didn't test/investigate further.
They look too out of place in some browsers while in others they look okay. So I tried to make them the same but apparently fail horribly. Now I'll try to fix it within 24hours or revert to default.
I have been looking for a fix and the current grid system is the best I could do. Instead of `pure-u-1-3` from Pure or `col-md-4` from Bootstrap I went for a clearer naming from my point of view: `third` to mean a third. There's no inherent grid system in html since grids are a presentation structure. To make it semantic you should use your own elements/classes and then give them the style, plus the responsive bit.
About the nav, you could make it completely semantic by using some JS or not making it responsive, however I thought the benefits of having a responsive <nav> would compensate for those 2 extra lines of code.
Secondly, I'm the creator of Min (http://minfwk.com), a fellow small CSS framework. Min is only 995 bytes - 5 times smaller. It also is more widely used, has feature parity with Bootstrap through the Min Bootstrap plugin, supports IE5.5+, is valid CSS, and doesn't have browser bugs. There's also an easy way to migrate from Bootstrap to Min (the Bootstrap->Min converter.)
Why would someone use Picnic.css rather than Min? I'd like to see the advantages of Picnic.css straight from the creator, since it seems you're answering questions in this thread. It seems one of the advantages you're touting is the "invasive"ness, which is a cool approach (I don't see Min taking that approach for various reasons but I think it can be a better choice for many use cases.) Another seems to be the grid naming system. What other things would make someone prefer Picnic.css for their project?