Hi there, I am the creator of Picnic CSS [1], a 5kb library similar to this one. I love the page and the logo, really minimalist and clean. A couple of tips for the library:
- Subtle animations. It doesn't take many bytes, but it makes it look much better
- :active status gives visual feedback that you are clicking the element
- The grid doesn't accept gutter nor reversing order by css, which makes it not really mobile-friendly for alternating patterns in a page. There's not really a single good solution in css for both [2]
- <select> looks just like a normal input without down arrow in Firefox
Why do I need npm or bower to install it? It's a 2kb css file. Now I do know what npm and bower are, however another web designer might not. So I think a link to the file itself would be handy.
While I agree a link to the file would be better, the frontend move towards npm and bower is due to greater professionalism in this area. It is fair easier to manage versions and automate installations by using npm and bower.
Yes, I know everyone's affecting to be jaded about JS tooling these days, but good luck downloading a package with webpack (build runner) or yeoman (application scaffolder).
Your comment is a bit like sarcastically asking "what do we build C projects with these days? Make? Lint? Valgrind?"
Except C actually NEEDS building whereas JS do not. But then using all of these command-line tools makes JS start to look more like a 'real' programming language and now any noob can't just walk in and take my job since I obfuscated the hell out of something essentially simple.
It is simple Machiavellian protectionism applied at rapid pace. Back in the day it was done within the purposely obscure UNIX environment (not just anyone can be sysadmin!) and now its being re-applied to web environment.
How selfish of us. I suppose we'll all go back to managing our dependencies by manually downloading them, 'modularising' everything as global variables, etc, etc.
And you're still missing the point. All these tools do different things (or rather, several different overlapping groups of things - build/compilation, static analysis, etc). C doesn't need to be linted. It doesn't need sophisticated memory profiling. Your code will compile without lint or valgrind. Yet these things might help. Both C and JS are full of opportunities for wanton self injury.
Nobody would pretend that the tooling landscape in JS is perfect - but surely this is just a side effect of a lot of very basic language affordances (modules, etc) being missing from the core language, given that it was designed in a hurry without a huge amount of ambition behind it. Very well, we're stuck with it, and get along as best we can.
I would love to be able to make a custom builds of milligram by shedding some of the modules I don't care about. This could also open it up to other modules being added like Modals or whatever.
For anyone keeping track at home, Bootstrap is 25KB, gzipped, with all modules included. If you don't include all the modules/stylesheets, you can easily get it down to half that. Milligram is 2.7KB.
Thanks, I found this same article when I was looking at making the switch! In my case, I'm running just a few operations on selectors, so the performance benefit of jQuery doesn't matter to me as much as a small footprint. Link to my project if you're curious http://daviseford.com/shittalk
With Zepto, the page size comes in around 80kB. I also had to rewrite some Ajax calls (base Zepto download doesn't include deferred modules), but since one of my personal goals was to have the page under 100kB, Zepto made sense for me.
Remove Bootstrap.js dependancy (usually, you don't need it)
Heavy reliance on async ajax calls (only load visible page content, load everything else on scroll using a function like below)
$(window).ready(function () {
$(this).one('scroll', function () { //only executes once
// call this data when a user scrolls down for the first time
// only do this with below-the-fold content
});
});
Make efficient database queries, bundle them together when you can.
This is an awesome list that will be really useful and mostly front-end or cross-(back-end) like gzip, which is awesome. Also the tools are a great plus, thanks (:
The use of bootstrap style CSS classes.l, but it's a strech. Seems like every new layer of abstraction that does more than one thing is now a framework.
The point of a framework is that you're supposed to build on top of it. Expectedly, color would be one of the first things anyone would change. Though the spacing issue itself might be difficult to address. Looking at the SASS files, _Color.sass has the values you'd need to modify in one place and _Spacing.sass might take care of the other issue.
I'm not going to tweak something that is "dead on arrival".
It has to be usable first with zero configuration; then the integrator gets excited and is inspired to weak.
What I like about this is the idea of a generic style sheet that just works with standard elements. It's successful in that basically it worked for me as designed; it applied its style to all the elements. Only, its idea of style is to make the fonts a bigger, and turn a simple table into something that needs scroll bars in both dimensions.
I would definitely like to try some other "just drop it in" stylesheet like this. Or maybe this one too, six months from now. Or its emerging forks (the project encourages forking).
Hmm, I agree that zero configuration would be ideal, but everyone has different needs. Design can especially be opinionated, with a person deciding "this is how this should be done." Of course picking a purple color doesn't help at all in that matter (I assume it's a reference to bootstrap's default color) and one person's minimal styling is another person's obtrusive styling. It's been a while since I've personally tried it, but Skeleton might be worth a try; it's quite minimal.
Okay; I took the Skeleton CSS and gave that a try. It had some issues but I plunged into tweaking. In the end, I got a good-looking result. But that end result could be obtained with probably some 20 odd lines of way simpler CSS.
* Didn't like the scatter-brained mixture of units used in this CSS. Some things are given in pixels, others in rem. This is annoying because when the user zooms, the pixel stuff won't scale, but the font-relative will.
* Elements are arbitrarily given display styles for no good reason. For instance, a checkbox is "block" displayed. I have some checkboxes in a table, and this caused them to align squarely to the upper left of their cell, not obeying the vertical-align coming from the table.
* Some elements are given spurious inner padding or margins, so they cause extra space. Tables blow up because of this. I had to hunt this down and kill it.
* Speaking of tables, the CSS has a rule for TD and TH that text is left-aligned. Firstly, why when that is the default? This caused a middle align given inline in the table itself to be overridden. I had to hunt this down and remove it to re-enable the middle alignment in a table column.
* The h1, h2, h3, ... guys were sized way too large. The author of Skeleton seems to think that the purpose of headings is to have a crescendo of font sizes, whereby h6 is normally sized, and things get geometrically bigger from that, culminating in h1 being a billboard on an interstate freeway. This is not the case. The h elements are for document structure. While you don't want h<n> to be smaller than h<n+1> it doesn't always have to be bigger. Styling can use other clues to indicate the hierarchy to the user, such as depth of section numbers or indentation. And who the heck even uses h6 and do they really still want that heading to be smaller than h3, h4 and h5? Needless to say, I had to tweak all those sizes.
In the end I got a nice appearance, but still with way too much left-over cruft for what is supposed to be a minimal CSS skeleton. So I put this into a branch for later contemplation, and reset my master branch back.
That later contemplation probably won't take place, and so this was a waste of the better part of an hour.
Which tends to confirm my earlier view: don't spend time tweaking something that isn't approximately right as-is.
Problems like eg: the docs dropdown not able to be fully viewed in landscape mode on my phone always bring me back to larger projects like bootstrap. Extensive testing across multiple devices, browsers, and oses is crucial to me.
I didn't want to be a dick, and milligram seems like a nice minimal grid which I don't think we have enough of, but it serms like they changed .btn-primary to purple and shipped skeleton.
It does seem so, but Milligram seems a lot more usable. It's written in sass and everything seems nicely organised. Skeleton is just a single css file.
I like skeleton. It has been ported to sass as well.
> it seems somewhat dead
The beauty of skeleton is that it still accomplishes exactly what it is meant to, without needing attention.
To be fair, it is only html and css, so there aren't huge security concerns or dependencies like a big project would have. But that is the point. You can make a super quick website without using a bootstrap and it is very logical and minimal.
That's true, but there are lot of issues and even PRs that IMO should be dealt with/merged.
Forms are another thing. They are a pain and it's useful to have something like this to form a base. But what if you only want the forms aspect and not the rest? Seems like you could do that with Milligram but not Skeleton.
Was fed up with a template-driven site I built a few months ago and was looking for CSS frameworks to base a redesign on.
Only downloaded Milligram the other day and have been having a blast getting it set up. Has a great mobile-first approach with absolutely minimal code in order to build fast, responsive sites with ease.
Looking forward to tracking its development but it already has everything I want to get a site up and running quickly.
Several comments mention Skeleton as possible alternative to Milligram. Unfortunately, as pointed out, Skeleton appears to be dead, i.e., no project activity for a year.
I've also used Skeleton in several projects though it required customization of UI element sizes, max grid width, etc. On the whole Skeleton worked well enough and sufficiently lightweight.
Hey, bug report: the page doesn't render correctly on iPhone, testing with iOS 7, the page height is many many times the height of the screen, it's miles of scrolling emptiness before I get to content.
Can't debug here but this usually caused by using the vh units in CSS: there's a bug with iOS that causes the vh unit to behave improperly. This may have been fixed in later versions of iOS
Anyone running a later version of iOS seeing the same thing?
I really like this. I was about to ask what makes it better than bootstrap, skeleton, foundation etc. But it's really straightforward, so I can focus on raw code instead of thinking of nice formatting.
Sometimes I just want a page to display data. This works perfect for that.
On my last web project (a couple years back now) I used GUSS
(https://github.com/guardian/guss) which I liked because it was light-weight and modular. But it hasn't had any activity recently and so I'm in the market for a new CSS framework. I was looking at Bootstrap 4, which certainly has a lot going for it. It has created a community - including template developers. But Bootstrap is big and it presumably still uses JQuery, which I've dropped from my toolkit. Milligram looks promising. Are there other similar projects?
Coming from a user/CSS perspective -- I'm hugely disillusioned with most current web design, but this actually Isn't Awful.
Particular kudos for going with REM units. My overall preference is to set:
html { font-size: medium; }
Then base subsequent sizes off of REM multiples. This ensures that users who do set default font size to something sane aren't suffering, while those who don't actually have a reasonable basis for zooming the page in and/or out.
A slight margin for reasonably-large mobile sizes (10" tablet here) would also help a bit.
This is awesome man. I hate how many frontend web frameworks require javascript to look decent on mobile and on desktop. There is no reason that a personal website serving static pages needs to be running anything on the remote end. This looks great on mobile and on desktop.
I'm going to be remaking my personal website soon with this. Thanks for posting.
Such is almost invariably the case with most CSS frameworks until you work with a designer that seeks differentiation. That's the point where everything generally falls apart, for better and for worse, depending on who's responsible for reconciling it.
Fortunately, this seems more easily amenable to that scenario than the typical framework due to its smaller footprint.
By default I reach for Skeleton[1] on side projects, which is similar in a lot of ways, but I really like the way the grid looks/functions in Milligram.
Also, defining pairs of CSS classes to accommodate the user rounding in either direction made me smile (ie .column-66 === .column-67).
Definitely going to try it out on my next project.
I like seeing CSS frameworks as a source of inspiration. Now that i'm using CSS Modules I can't really see myself using any directly. It'd be interesting to see what types of frameworks crop up with CSS Modules in mind.
One reason might be for styling. Otherwise you may have to resort to wrapping the label's text in a span or something to target the label's text separately. You wouldn't use the id for styling, just to link the label and the input for accessibility.
IIRC, the name attribute on the input element serves to tie it to its label as well as the id. I don't think that you need an id on the input element if you have a name.
I'm not a webdev, and the fascination with yet-another-framework for JavaScript is really cute, but I really really REALLY don't get this. It's it appears to be nothing more than a CSS stylesheet. So what?
Have you ever written any CSS? This sort of framework just does the basics for you, it's the first 500 lines you'd otherwise have to write (and CSS can be quite painful to get right). It's not really just a stylesheet, it's a solid starting point meant to be expanded upon.
- Subtle animations. It doesn't take many bytes, but it makes it look much better
- :active status gives visual feedback that you are clicking the element
- The grid doesn't accept gutter nor reversing order by css, which makes it not really mobile-friendly for alternating patterns in a page. There's not really a single good solution in css for both [2]
- <select> looks just like a normal input without down arrow in Firefox
Keep it up (:
[1] http://picnicss.com/ [2] https://github.com/picnicss/picnic/issues/58