Unless you're planning on inlining your CSS in the head tag, IMO the network difference between 7kb and 20kb of CSS is just splitting hairs. I've gotten far more out of optimizing my CSS for programmer understanding than network size (though the two tend to be correlated!).
As someone who sees CSS as a necessary evil, the simplicity and readability of Milligram really appealed to me. I tend to use Bootstrap out of habit (plus there are plenty of resources and answers out there) but as my skills improve I really can see the advantages of a minimal, tidy starting point that Milligram (and others) provides
This looks nice. I like the name. But poking through the code it seems to be more of a slimmed-down Bootstrap rather than a fresh/new approach to minimalist CSS. Which has it's uses no doubt.
I personally love http://basscss.com/ for a minimal and side-effect free (the real goal) CSS framework, as it has one of the best class naming schemes I've seen.
Each component is focused on doing one thing and one thing well. You basically build up the styles with each class you add to an element. Composed via a combinations of smaller pieces, unix style, rather than complex multi-layered components with deep nesting. Which is an interesting approach when you try to apply the same idea to your own CSS. See the Design Principles for more: http://basscss.com/v7/docs/reference/principles/
The code is also very readable and integrates perfectly with PostCSS. They also have a React version.
As for the second point, at least how I use it, is that I can create a higher-order class from those "atomic" classes like bold, etc. So I'd do in Sass:
Then apply that class on the paragraph. This way, the resulting CSS is very compact: the above gets compiled so that the higher-order class uses the same styles as the atoms that compose it.
I'm a big fan of Basscss also; since discovering it a couple years ago, I've almost exclusively used it (a custom fork of it) as the basis for everything I build on the web. It has a logical class naming scheme that easy to remember for me, and keeps things manageable (minimal inheritance) by composing atomic styles to build up higher-order styles. I use it for React applications, but have stuck with the Sass variant, to leverage the library of accumulated themes and "style modules" I've built up over time, which are based on the atomic design principle that Basscss naturally encourages.
I was just building a Jekyll blog and was saddened to see the SASS version of Basscss hasn't been updated in the last year. The maintainer in the docs said that PostCSS is the best way to go, but I was trying to avoid using Node. That might be impossible these days when doing front-end.
Regardless, I know managing OSS is tough but I hope JXNBLK keeps active on the project and other people help him out.
I just don't like mixing a ruby static site generator with node. I ultimately just moved to Metalsmith for site generation to use a purely node framework...
Apropos of nothing, but I just migrated a site to metalsmith, and I've really enjoyed the results and ease of building out any functionality that was lacking in the framework (though most needs were met already).
It's in a mature state, already at version 8. Given that it's a minimalist framework this isn't as much of an issue as it would be for Bootstrap or something similar.
I love stuff like this and it looks fantastic, but without support for at _least_ IE10 I would be loath to use it. IMHO the value proposition of a CSS framework is that it saves time and looks good without having to think about it. If I have to spend time fighting browser bugs and writing CSS hacks to deal with incompatibilities and/or layout issues, that's the opposite of that. Hopefully the developers will add support for some legacy browsers perhaps as an optional addition similar to how JQuery does it.
Fantastic work so far to the developers that said. I will be keeping an eye on this. Good luck!
They say that they support older browsers and, from testing it lately, I haven't seen anything odd in IE 10 and 11, except the way images scale in the card media sections, which isn't really an issue in my eyes.
With automatic windows update there aren't really that many users left who are using IE version lower than 11. Browser stats metrics show that only 0.1% of all users are on IE < version 11.
What really matters are the stats for one's own users but who's stats say <IE11 is less than 0.1%? NetMarketShare reports of global desktop browsers for April [0] says:
IE11 13.62%
IE8 2.25%
IE9 1.32%
IE10 1.06%
Wikimedia global all-device browsing for April says:
IE11 4.8%
IE7 3.0%
IE9 0.43%
IE6 0.38%
IE8 0.25%
IE10 0.23%
IE4 0.22% (! I don't know what this is about, maybe an old mobile version?)
I wish they could somehow learn about Firefox, which is still supported on Windows XP. Then it would basically be just the people with old phones and 6-7+ year-old Macs that would require fallbacks.
That's a very skewed audience though, web developers aren't going to be using a super-outdated browser and Microsoft's browsers have been an unpopular choice of that audience for a very long time.
The developer of mini.css addressed these concerns about IE support in a Hashnode story[0], raising some pretty compelling arguments about why it can't be done, not fully at least.
Interesting. The promise of making a small CSS is a bit overblown. With a build step or module mechanism, most frameworks can be smaller than this.
On another note, we had a great blast using http://tachyons.io/
It was a game changer for me, and made me remarry CSS. And spoiler alert, it was way smaller after a build step than 7KB, while not feeling like working in tight pants.
It's a CSS switcher for previewing minimal frameworks, which you can drop in to any page or site to quickly preview what it would look like in 50 or 60 different CSS frameworks (including mini, pavilion, basscss, milligram, and others mentioned in this thread). There's even a bookmarklet to preview switching the css on any site.
I feel this is wrong way to optimize:
First, bootstrap gzipped is <100KB after removing font. Check any reasonable site from youtube to amazon, they download ~ 1MB gzipped data on load and do just fine.
Second, if you are really concerned, you can just remove a lot of components from bootstrap to reduce its size. I do it for my project where i don't need for example the glyphicon, carousel, etc.
When using a framework, you want it to just work on all platforms. When I look at bootstrap issues, I see so many issues of the form X does not work on Y and then it gets fixed. These little kinks are hard to get right and I am not sure its worth reinventing the wheel unless there is a clear benefit other than size.
1. It actually loads very slow, takes me 5 seconds for the site to become usable on 100Mbit/s and a new fast i7, compared with google.com or hacker news which takes fractions of a second.
2. It is not the first site you go to with a shitty connection as the reason you go there is to watch heavy bandwidth videos.
3. It is essentially a single page app, once loaded, you will stay on the page for the duration of the video and the next video will be played on the same page without reloading.
> Check any reasonable site from youtube to amazon, they download ~ 1MB gzipped data on load and do just fine.
What's important is how much you need to download to be able to do the first meaningful interaction. Downloading 5mb of JavaScript and CSS for your cool dashboard graph might be fine, but you should not need to download that much just to get some reasonable layout or have a look at the possible menu alternatives.
Could I suggest adding 'use bootstrap properly' to this list (and perhaps link to [1] and/or the LESS/Sass source). Bootstrap is modular. There's no need for a 'light' alternative, and in many cases I believe using Bootstrap 3 from Sass/LESS source is still the better option compared to the majority of these mini CSS frameworks. More comprehensive, better browser compat, likely 1000s more hours of dev braincycles (just go take a look at all the Github issues for Bootstrap to see all the work that has gone into it).
This is what saved bootstrap as our goto framework in our shop. Every new project starts with most modules commented out and some early attention to setting the global variables and using the mixing. This keeps things small while new modules are a simple uncomment away.
Yep, exactly what I do, +1 for using bootstrap's variables as much as possible too, I don't think a lot of people realise how powerful bootstrap's variables are, and can greatly cut down the amount of CSS you write.
However, the framework says its responsive, yet the navigation menu doesn't resize on small screens. That's a bit disappointing. I'd like to have something that will give a chevron or hamburger navigation menu without resorting to Javascript.
Full disclosure: I've created Min. It's the world's smallest CSS framework and it has a hamburger menu that works without Javascript (which took a lot of work to make.)
IE is, after all, a discontinued browser. While I'd expect most public-facing websites to provide support for it given the longish tail of legacy users, it's reasonable that some applications may no longer require that support, and it's good that libraries exist to fill this use case.
Makers of new libraries are free to chose how far they go with testing and support in different browsers. Of course you might be forced, by you client base (or intended client base) to support other browsers and if so you have three choices: don't use libraries that don't support the browsers you need to work with, test yourself and maintain your own branch if changes are needed for those browsers, or try nag people to share your pain and support what you need them to support.
Option three is likely to fall on deaf ears as the decision of how much time is worth spending on compatibility testing has already been made, so unless you can give a really compelling reason the won't want to. Option two is only viable if you (or your team more generally) have both relevant experience and time, which is often not the case. So this library may not be for you...
Not supporting at least IE11 is rare currently in my experience but I suspect it is a condition that will steadily grow more widespread. You may find that everything in the library works well enough in IE11 and the developers try to not intentionally do something that would change this, but don't feel they have the time to test (and fix as needed) sufficiently be able to make such guarantees.
Of course existing libraries that support IE11 are generally expected to keep doing so at very least least up to the next major release.
They state that older browsers and versions might be supported. I've tried this in IE 11 and it works like a charm, except for a couple of minor features. The diagram is the browsers that are "fully" supported.
There's no such thing as 'might' be supported. Either they're supported or they aren't. They might work on those browsers, right now, but if they stop working or if there are bugs and the library makers aren't supporting them, then they stop working for good.
Maybe not today, but in a few months or a year, possibly. IE is dying and Edge is taking its place. Supporting IE just makes maintanance more difficult, doesn't it?
The time of CSS frameworks has really come and gone. There were four use cases, and all of those are more and more obsolete:
- "The Grid", which at this point has migrated to the browsers with Flexbox and (soon) Flex Grids
- A pretty skin replacing the browsers' default rendering of elements. These have improved, albeit only slightly. CSS has also become easier and you can easily do this yourself in 50 lines or so
- Fixing browser bugs/inconsistencies, which have diminished to a fraction of where we used to be
- "Components", which may the last remaining use case, but which have also become much easier to do yourself due to sane grid layouts
If you mean CSS Grid, and you can afford to target only modern browsers (with usable fallback CSS for the others) then you're good to go right now. Even Edge is working on bringing their implementation up to the spec right now[2].
I agree with your other points too. CSS frameworks don't bring that much, and end up clouding your ability to write and understand raw css IMO.
Consider stuff like wordpress, and other large programs that need an easy to re-use styling language. When you use something like bootstrap, and others know bootstrap, then you're making it easier for you and your customers down the line to build on something.
You can always write your own thing, and in many cases this will work, but then someone else is going to have to learn all of the quirks of your system before they can get up to speed and start using it at scale.
It looks neat but I'm left wondering what sets this one apart from the many others in what seems like a flavor of the week.
It's minimal indeed, but almost too minimal. In my experience working with CSS frameworks, the "there's a class for that" pattern is almost always not enough and it's much easier to write rules to handle customization. That leaves out both developers that aren't designers and designers that develop.
Applications aside, the semantics of some of the content is not up to date (for example <section> vs <div class="section">).
The semantics are reasonably outdated, but I wonder if part of this is due to certain things like using <section> might affect content placement and/or nesting (section classes are used only for cards so what if a card is inside a <section>?).
I am convinced now that these micro frameworks are not the way to go (in my very humble experience). CSS is super easy and simple. And unless you want to support IE, it's not nearly the main pain point, especially in contrast with JS which has room for much more trouble.
A week of genuine effort in learning the small nits and bits of CSS will go a long way.
What would you recommend as a learning resource? If you had a week, and wanted to dig in and learn CSS in the way you describe, what would your ideal curriculum look like?
A static website I think is a good way. The most important part is layout. Once you master flex and css selectors, everything else is a derivative one way or another.
It's probably not a good idea to focus an entire week on CSS alone. It's more economical and practical to spend a week's worth of hours in an otherwise broader project. That gives you real, practical experience in building real-world UI.
I agree with Achshar's post. I'd also recommend using caniuse.com to get a better understanding of what is and isn't supported in the various browsers.
It looks great at first glance. A big problem though is that it styles basic elements. If for example you want to use a <table>, <mark> or <nav> where it would make sense in a custom element you'll have to reset all the styles of the library before adding your own.
Sorry custom elements might have been the wrong term to use. I mean custom interfaces, say an image gallery or a realtime search box where you would use elements like buttons and input's in a different way then the usage this framework defines for you.
Using a nav both in your header and sidebar is a different example where these are not good defaults
Exploiting `radio` input for things like Tabs and Accordions [0] is surely a sweet trick, but I don't think it's a great idea to use it where more than a few people would maintain the code.
Not only that, it also breaks completely in anything below "modern browsers". I get that this framework doesn't target those browsers, but I think these are the kind of things Javascript is for. It shouldn't be done by CSS.
I have actually pulled that trick off a few times for things like nav drawers and in over a year we have never gotten a single complaint around one of those elements not working. Of course it's entirely dependent on your audience and what you are trying to achieve, but I have found it very safe to use radio buttons for this purpose in our content.
Has anybody here any experience with/opinions on/ W3.CSS ?
https://www.w3schools.com/w3css/default.asp .
It seems like the obvious first choice to me and has pretty much everything I might ever need.
How does it compare to the above and the other css frameworks mentioned here?
Why would I use this over Bootstrap 4 (if it's ever released)?
BS4 seems to include everything here and more (I can comment out what I don't need before building). BS4 also supports IE10+, where a non-trivial amount of my conversions come from. The flexbox grid/naming convention seems identical at a glance.
Without reading the docs in depth, there's a difference of about 142KB of render-blocking CSS. I'm sure the API and functionality depth is very different too.
People using Bootstrap end up serving a lot of CSS that isn't even used in the end. Using a minimal framework like that one allows you to have a solid skeleton without any extra features on which you can build.
I'm trying to come up with a situation where loading a 199kb css file would make a difference. Maybe websites that target an audience that is expected to have a slow connection (banks etc.) but this kind of rules them out by not supporting IE.
I really love how many things seem to be compatible with Bootstrap.
Most sites I've made in the past few years use Bootstrap—specially the grid, so I'd image this will really ease adoption if I'm not the only one who's used Bootstrap extensively.
Compare mini.css (https://github.com/Chalarangelo/mini.css/blob/master/src/min...) to Milligram (https://github.com/milligram/milligram/blob/master/src/_Form...).
Unless you're planning on inlining your CSS in the head tag, IMO the network difference between 7kb and 20kb of CSS is just splitting hairs. I've gotten far more out of optimizing my CSS for programmer understanding than network size (though the two tend to be correlated!).