131–140 of 149 posts
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
I would make the shadow inside the input boxes lighter when the box is selected. It doesn't fit well with the green outline. Or maybe change the outline to an outer glow?
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 d…
* 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.
* Did you remember to set the viewport meta tag? http://webdesign.tutsplus.com/articles/quick-tip-dont-forget...
* Is it related to the last point? Can you share an screenshot, please?
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, support…
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 Pi…
Thanks!
> 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 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 that looks nice
Min 2.0 will likely have a 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.
Lots of accessibility issues here. * 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 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 check…
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 address…
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.
3. Ignore accessibility issues.
[0] https://squizlabs.github.io/HTML_CodeSniffer/
Earlier quoted context omitted.
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…
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/contras…
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, support…
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.)
Earlier quoted context omitted.
> 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 responsi…
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.
Earlier quoted context omitted.
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…
@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?
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.
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 d…
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. * Did you remember to set the viewport meta tag? http://webdesi…
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).