Milligram: A minimalist CSS framework
milligram.github.io
milligram.github.io
- 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
If you alter your approach you can still achieve the same effect by making use of
position:fixed
transform:translateZ(0)
will-change:transform
Your comment is a bit like sarcastically asking "what do we build C projects with these days? Make? Lint? Valgrind?"
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.
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.
Still, I like the flexbox-based grid.
Is 25kb for the single .css file or the .css and .js combined?
So, if you want to use bootstrap CSS + JS + jQuery, you're immediately looking at ~75kB worth of stuff.
Side note: I was recently dealing with this, and found Zepto to be a suitable jQuery replacement for small single page apps.
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.
Minify HTML (http://www.willpeavy.com/minifier/)
Minify CSS (YUICompressor)
Minify JS (Google Closure Compiler)
Enable gzip compression
Replace jQuery (29kB) with Zepto (9.6kB)
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
});
});
Use loadCSS to asynchronously load non-essential CSS after the page has been loaded: https://github.com/filamentgroup/loadCSS
Try out different CDN's - some CDN's have bootstrap.min.css around 30kb, and other services have it compressed to 19kB (CDNJS works best for me)
Use the following sites to find what's impacting load times/page size:
http://tools.pingdom.com/fpt/#!/dVQE7B/http://daviseford.com...
(I did look through the docs, but didn't see the kind of modular or "designed to be built on" philosophy expressed in frameworks like Pure CSS.)
This is just a light one, that is the point.
Neat.
https://github.com/milligram/milligram/blob/master/dist/mill...
Selected the 500+ lines of CSS, switched to my terminal window:
$ cat > milligram.css
[paste]
[Ctrl-D]
---
Result: Hate it. Everything is huge, and pink. A compact table that took up about 1/4 of the browser window is now spaced all over the screen.
$ git reset --hard ; rm milligram.css
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).
We are talking about this Skeleton hopefully: https://github.com/dhg/Skeleton
I am, anyway.
Some of my observations:
* 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.
Skeleton also seems somewhat dead.
> 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.
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.
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.
For all Skeleton users, the project was forked a few months ago and now lives on as skeletonframework, available here: https://github.com/skeletonframework/skeletonframework
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?
However when I published my own css library few recommendations popped up:
- Pure CSS [ http://purecss.io/ ]
- Min CSS [ http://mincss.com/ ]
- Skeleton [ http://getskeleton.com/ ]
- Picnic CSS (my own) [ http://picnicss.com/ ]
- Basscss [ http://www.basscss.com/ ]
- Tachyons [ http://tachyons.io/ ]
Sometimes I just want a page to display data. This works perfect for that.
Particular kudos for going with REM units. My overall preference is to set:
html { font-size: medium; }
A slight margin for reasonably-large mobile sizes (10" tablet here) would also help a bit.
I'm going to be remaking my personal website soon with this. Thanks for posting.
Fortunately, this seems more easily amenable to that scenario than the typical framework due to its smaller footprint.
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.
[1] getskeleton.com
<row>
<column ...
relying on ids makes creating components a pain in the ass