56 comments

[ 5.0 ms ] story [ 128 ms ] thread
Cool, but what does it offer that Pure (4kb doesn't)?

http://purecss.io

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.

The grids are way nicer in cute. You just have to specify a grid container and the flex takes care of the rest.
Yes, but just one row at a time (it doesn't wrap). And with flexbox it's just 2 lines of CSS code anyway (unprefixed).
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.
PureCSS has been my go-to for small websites/web applications for a while. I only use Bootstrap for clients that:

1) Want to use it

2) Are already using it

3) Found a template they love they want to base the site off of

4 more kilobytes. :)
Here is a penny so you can by some more ram. You can keep the change.
Pure doesn't have any SASS/LESS support, from what I can see.
tbh, I've been keeping tabs on alternatives to Pure because Yahoo is circling the drain. It's nice to have it there just in case.
(comment deleted)
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.
This is something that interests me as well. I would like a bare-bones configurable SCSS library to use in my projects.
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 :)

For me, forms look microsoftish (maybe can be easily customized though) and BEM is hungarian notation of CSS.
What is "microsoftish"?
I suppose the forms are vaguely reminiscent of Microsoft's rectangular, solid-colored forms
That was my reading of it too. They do resemble the flat aesthetic of Microsoft's Metro.
Which is funny because that look has only been used by MS for the past 2-3 years. But yes, it's their current look. :)
Huh, I haven't even looked at MS in years. I just styled them this way for consistency in markup and display.
can someone explain the convention of importing a directory into a file of the same name (and same level) before main.scss. The structure is:

    src/sass/
        components/
        support/
        vars/
        _components.scss
        _support.scss
        main.scss

and within main:

    @import "components";

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.

In my opinion this is still the best option for CSS, especially in combination with React.

http://tachyons.io/

Most importantly it contains a ratio-based scale: http://tachyons.io/docs/layout/spacing/

Geez. Those selectors.. "<footer class="pv4 ph3 ph5-m ph6-l mid-gray">"
It is a bit weird to use at first but I highly recommend giving it a shot.

I've built some complex UI's with the same class name styles (Basscss). 99% of the time I'm reusing classes and I don't have to write anything custom.

Prototyping is great once you memorize the classnames.. Just write HTML, no need to switch to CSS files.

If you're working with global styles this is by far the most scalable CSS methodology as of right now IMO.

"...once you memorize the classnames"

I don't know which editor you are using, but for TextMate I've written a 20 line-plugin that greps the tachyons.css file and gives me code-completion.

http://postimg.org/image/tq038rwqp/

It's definitely weird at first, but the aim of atomic CSS is to not have a CSS file that just grows and grows and grows.

This article(written by the creator of Tachyons) helps to explain the issue: http://mrmrs.io/writing/2016/03/24/scalable-css/

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.

I love it, these are elements I can use. Now... I guess I should read the docs, how to make my own or compose them.
May I suggest susy grids and using fully semantic selectors, with zero CSS cruft?

It's a grid system, not framework, so it adapts to what you need.

Is it possible to use semantic class names then use a CSS processor to map those into tachyon classes?
Why would you do that?
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.
Read '8k' and thought we were talking about resolution, not kilobytes. Cool, but not as absurd as I was hoping for.
BEM may be effective for some, but it's a total turn-off for me simply because of the `__` syntax making my eyes bleed.
Had to look up BEM, this appears to be a good overview:

https://css-tricks.com/bem-101/

[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?

  <!DOCTYPE html>
  <html>
  <body>
  <style>
  div.menu > div {
    background: red;
  }
  div.menu > div:nth-child(3) {
    background: blue;
  }
  </style>

  <div class="menu">
    <div>Item one</div>
    <div><p>Also<br />an item</p>
    </div>
    <div>Item #3 and CSSv3
       <div>knows (still blue)</div>
    it</div>
    <div>Item #4 and CSSv3 knows it</div>
  </div>
  <div>wat</div>
  </body>
  </html>
I'm with you, those two concepts are mutually exclusive though.
(comment deleted)
No words about browser support?
It's IE10+, the flexbox grid is the only limiting factor.
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."
Thanks! Someone opened up a PR and it's merged now :)
Just throwing this in here in case anyone is on the look for other frameworks: http://semantic-ui.com/

So far this is my favourite!

I'm using this these days. I find it incredibly flexible.
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.

> bower install cutestrap

People still use bower...? Somehow I thought it officially(?) was dead.

What do you suggest to use instead?
npm.
Is style(src="/node_modules/foo/bar.min.css") really that superior to (src="/bower_components/foo/bar.min.css").

You could argue that npm is the better package manager, but the average user does care about the underlying semantics.

You can install it with either now, it's not officially dead at all though. Most people talk about it like it is though.
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.

What do you think?