Where I work, we're using it on a new project and while it definitely requires a lot of learning(and just generally understanding CSS), it's faster to debug with, easier to take care of edge cases, and the total size for our app is incredibly small.
As others have said it's very strange at first. My co-worker introduced it to me a little over a month ago and I remember thinking "how is this maintainable?". After a few hours it started to make sense and now I can't imagine going back to BEM.
Being able to design UIs without opening a single CSS file has made HTML pretty fun and I've found I'm much better at componentizing the right things.
It would decouple your structure(html) from your display(css). The semantic class applied to your html could remain unchanged while you are changing the style. For example, you could switch from using a css library like tachyon, to swapping it out with a custom css without touching your html/templates. You're right though, it is an extra layer of abstraction that might not be needed.
From what I can tell, they have slightly different aims.
For instance, Cutestrap follows BEM naming conventions and uses KSS to generate its own documentation. KSS is a nice way of generating a pattern library of your own, as you start to extend your base CSS framework.
Also, one big difference is the way they handle grids. Cutestrap grids automatically stretch columns to fill up the horizontal space and allow you to provide weights. (This is essentially a very thin abstraction on top of flexbox.) Whereas Pure grids deal more with unit sizing, more like Bootstrap.
In general, Cutestrap is more opinionated (as its tagline implies) whereas Pure offers much more customizability. I'd argue that Pure should be used more like Bootstrap, as a way to prototype complex UIs before applying more custom styling, whereas Cutestrap should be more directly used as a base for your own, custom (and opinionated) styling.
Originally I had one class with grid, direct children were rows and direct children of rows were cells, but it turned into div soup pretty quickly, so I opted for one row at a time.
[ed: Having now read: http://mrmrs.io/writing/2016/03/24/scalable-css/ linked above, I can at least see where this idea is coming from. I guess I'm still thinking in documents with semantic mark-up, rather than UI widgets. I'm not entirely convinced throwing out all the cascading bits is the best approach, but I sympathize with that point of view.]
This is madness. Why work so hard to avoid how CSS selectors work? I mean, if you have a menu-structure built around divs, surely it should be enough to say that direct children of the div with class menu, should be considered menu items?
Semantic UI is far from a light-weight CSS framework. I was recently working on a project using semantic, and I saw that the CSS alone was around ~960KB. I'm guessing that something must have been misconfigured for CSS output to be that high just for the Semantic UI framework, but offhand I didn't see it. That didn't include the icon fonts or the JS with Semantic. I'm guessing with some work, that CSS payload could have been trimmed down, but I doubt it could be trimmed enough to be considered light-weight.
I prefer CSS frameworks to provide the bare minimum instead of the kitchen sink. The only exception I make is if I am working on a project that I know will not have design provided. If a project does have a provided design, overriding framework defaults is counterproductive. Just write your own styles when you need them.
Just curious why this is? I usually just import them directly into main, but I could understand if they were nested into the directory so they could be broken out. This structure doesn't make sense to me though as they are all flat & in same directory.
Hey! Usually I do exactly what you describe, but I laid it out like this so that if people want to include all the components, it's one line. Or if they'd want to include just the grid from components, it would still just be one line.
With something this small, it could be just into the one file, but I'm optimizing for that granularity.
I think it will need to follow Foundation style and offer mixin rather than hardcoding the classes. A library taking like .btn andothers etc is not something you'd want. Or maybe it's just me that don't like putting tons of classes in the HTML.
When I was originally writing it, I had the classes split out into mixins, but put them back into classes so it would be a little simpler to follow at first.
I want to build the project in a way that people would like to use it, so you'll probably see mixins brought back in a future release :)
What do you think of http://bulma.io? It's based on Flexbox, what it attracts me is that:
1) Quite feature rich out of the box.
2) Very nice-looking out of the box, than Bootstrap.
3) Much lightweight than bootstrap.
4) It's very easy to learn, even for a desktop-app-guy like me.
5) It's very interesting that Bulma has very little "global styles" - most of the time you need to explicitly reference a Bulma class. To me this seems like to way to go - you know, in the programming world we try our best of best to avoid global variables.
Small typo in the following paragraph on the front page:
"There are plenty of amazing front end framworks -> frameworks already, such as, Bootstrap and Foundation. If you're looking for something feature rich with loads of components, those are both great choices."
http://tachyons.io/
Most importantly it contains a ratio-based scale: http://tachyons.io/docs/layout/spacing/