i collect these for fun! adding to my collection https://github.com/sw-yx/spark-joy/blob/master/README.md#dro...

more like this:

- https://andybrewer.github.io/mvp/ mvp.css

- https://yegor256.github.io/tacit/

- https://github.com/alvaromontoro/almond.css has thin fonts

- https://picocss.com/ Elegant styles for all natives HTML elements without .classes and dark mode automatically enabled.

- https://simplecss.org/demo 4kb incl dark mode

- https://watercss.kognise.dev/ Small size (< 2kb)

- https://github.com/xz/new.css (https://newcss.net/) 4.8kb sets some sensible defaults and styles your HTML to look reasonable

- https://github.com/oxalorg/sakura supports extremely easy theming using variables for duotone color scheming. It comes with several existing themes

- https://github.com/susam/spcss

Picnic CSS:

https://picnicss.com/

My own and one of the older ones, almost 10 years ago, see the original Show HN:

https://news.ycombinator.com/item?id=8315616

Oooh I was going to recommend you add Latex.css to your list (https://github.com/davidrzs/latexcss) but I see you have a fork listed with some pretty good additional features (https://latex.vercel.app/).

I use the former for my Zettelkasten and it looks very nice.

Shameless plug for Vanilla CSS

https://vanillacss.com

Nice list, thanks for putting these together! Do you think Writ belongs here? Just one off the top of my head that I liked, though it's a bit older now.

https://writ.cmcenroe.me/

> https://writ.cmcenroe.me/

yes! PR welcome!

Shameless self-plug: I recently created my own classless CSS framework[1] and would appreciate feedback.

[1]: https://github.com/zichy/fieber

Shameless plug; there is also mucss: https://github.com/BafS/mu, a 1 ko css file.

idea: a TodoMVC type thing but for CSS framework. A plain HTML file that contains all the common structures and you can plug any CSS framework in to preview its visual style, making it easy to compare & pick

An ancient site that started with that idea: https://www.csszengarden.com/

https://dohliam.github.io/dropin-minimal-css/ and https://github.com/dbohdan/classless-css do that.

this might be up your alley: https://github.com/dohliam/dropin-minimal-css

here you go: https://www.cssbed.com/

Great list! I'm going to lose a day looking through all of these :-)

Thanks for mentioning Sakura.css! <3

Sakura is my drop-in "I need a page" CSS file for some years now. Thank you for making it.

Thanks, super glad you found a use case for it! :)

i just make lists. you made the thing!

<3 Following you on twitter since years now! Been learning a lot from your tweets, thanks for sharing all the valuable insights!

Interesting, a few observations:

-It's really just a container, p, img, and button CSS framework (short of CSS's default flexbox)

-There are no components (Codeblock, quote, etc.)

-There is a semi-obfuscated IP tracker in index.html

While I find it noble in some aspects to create a simplistic blog layout, I also find it odd to post this project.

Interesting that you mentioned my counter. It exists only in the index.html file on the neat site and NOT in the neat.html file that you're supposed to use for your own. It also DOES NOT log your IP address, set any cookies, or do any other tracking of your personal information.

You can read more about that counter, which runs on a Raspberry Pi in my bedroom, at the URL below.

https://joeldare.com/private-analtyics-and-my-raspberry-pi-4...

> -There is a semi-obfuscated IP tracker in index.html

you mean that counter script, it wouldn't expose anymore information than a basic access log, I would assume it just makes it marginally easier to see which of his subdomains are popular.

But even a basic access most likely violates the GDPR and other regulations.

> one of the technologies that has lasted as long as the Internet is HTML

Nit: the Internet is a bit older. Internet as we know it started in 1983 when IPv4 was deployed on ARPANET (otherwise it's even older). HTML appeared in 1993, 10 years after.

Yes, I think the author meant to say the Web, which is often used to refer to what is built on top of HTTP, HTML etc.

Good call, I changed this to "the Web" as the other comment recommended.

I wish CSS tools had unique names

https://neat.bourbon.io/

This is s recurring complaint and I never understood it. Names are made to be memorable, not unique.

Our brains are not a hash table, where every entity would have its own unique key and we'd use it to recall the entity.

<putting on “actually” hat> Brains maybe not, but google search will probably return not the things you’re supposed to be looking for if there are names collision.

If, in real life, your searches are just single keywords like "neat", I'd love to have a peer session with you, I'm bringing the popcorn :D

I've just searched a more typical (for me) "github neat css" in DDG and the 1st result is just as expected.

In this current situation I would google “neat css <some rare problem I was not able to resolve myself>” expecting it show me SO answers or reddit discussions. Instead I’ll be getting information about old and deprecated CSS grid library for Ruby on Rails. I am not saying it’s impossible, just added my “two annoying pence nobody was asking for” :)

I agree. Our brains segment information by context. In this situation, we have 2 libraries with the same name in the same context. Now for both of these, I have to store additional context alongside each name in my brain.

Aren't they, though? My brain seems very much like a hash table. Duplicate names just make the hash key longer, which is not a big deal but harder to remember.

That would be a hashtable whose values are lists :-). The buckets are for dealing with hash collisions not key collisions.

Yeah but which one has greater specificity?

NPM forces package names to be different.

But do we really want a registry for CSS?

Thanks for sharing, I love minimalist CSS frameworks that are easy to digest. My go-to for the past ~5 years has been https://milligram.io -- mainly for the grid and basic styling -- although, the author hasn't updated it in a few years. I'm going to give yours a shot!

Another minimalist CSS framework, another review from me. :-)

> :root { color-scheme: dark light; }

The stylesheet is written with light values by default, and dark values in a prefers-color-scheme media query. Therefore, this should be `color-scheme: light dark` instead. As written, if no preference is expressed, your styles will be light, but UA styles will be dark.

> * { box-sizing: border-box; }

I personally am one of the rare contrarians that prefers content-box for the web (simplifying my position a lot: good responsive design bases sizes and such on content, not layout). But if you’re going to change it to border-box, you might want to consider changing it on pseudoelements (at least ::before and ::after) as well. Then again, you’re not using them. Then too, the whole box-sizing declaration seems no-op.

> * { color: var(--dark); }

That’s… um… courageous. No, I can’t leave it at that: this is a very bad idea. This will make custom styling painful, may ruin elements that have backgrounds set in the UA stylesheet (e.g. input, mark), and I detest links being the same colour as the surrounding text.

> :root { --light: …; --dark: …; }

I don’t like how these two variables are used: you’re using them as #defines (to use C preprocessor lingo) rather than what custom properties can be, and end up with significant duplication because of it. Consequently, every time you use --light or --dark, you have a counterpart the other way round in the tail @media (prefers-color-scheme: dark) block (except that input[type=submit]’s counterpart is just input; I’ll remark on that later). Here’s how you should do it:

  :root {
      --bg: #fff;
      --fg: #404040;
  }

  @media (prefers-color-scheme: dark) {
      :root {
          --bg: #404040;
          --fg: #fff;
      }
  }

… and then use --bg and --fg throughout, and need no more dark color scheme media query at the end. You could define two colours and have --bg and --fg use them, but because of how light works, you may not want to just swap the two colours—for example, you might want to darken both --bg and --fg in dark mode (it’s currently fairly bright for a dark mode; something like #eee on #333 would be more common).

> html { border-style: solid; border-width: 5px 0 0 0; border-color: var(--dark); }

Shorter written in the :root block before it and as `border-top: 5px solid var(--dark)`. As for what it represents, I don’t like it. It’ll tend to be an eyesore, especially on dark. If it was a colour, sure, but just --light or --dark? Nah, don’t like it.

> font-family: sans-serif;

Thank you for a sensible font-family.

> px

There’s quite a bit of not-great usage of pixels. Remember that the root em is not necessarily 16 pixels, so for correctness most px things should actually be defined font-relative. As a simple rule of thumb, take any px value, divide by 16 and change the unit to rem. (Single-pixel lines are about the only place I can think of where px is genuinely what you want, though even then it’s still not guaranteed to be a crisp single pixel, due to possible fractional scaling.)

> p { margin-bottom: 10px; }

This doesn’t do what you probably intended. Indeed, in the sample document, I think it does nothing: remember that most of your flow content elements have 1em block margin, which is (likely) greater than your 10px, and margin collapse applies.

> p { line-height: 1.4em; }

Dubious: now anything that’s not inside a <p> uses some other line-height. You probably want to specify line-height on the root element. Remember that line-height accepts a unitless value, too, to be calculated relative to each element’s font-size, whereas em fixes it. Me, I’ve actually started experimenting with this, to conveniently reduce otherwise-extravagant leading in headings:

  * {
      line-height: calc(1em + 0.5rem);
  }

That is, 1rem (16px) body text gets line-height 1.5 (24px), 2rem (32px) heading gets line-height 1.25 (40px).

> img { width: 100%; }

This needs `height: auto`, or else <img width=… height=…> (which you should strongly prefer, to avoid layout reflow as the image loads) will get a mangled aspect ratio. Also consider using max-width instead of width.

> button, .button, input[type=submit]

I’m not fond of various of the styling here. I reckon it could do with a hover/focus-visible colour change, and no `cursor: pointer`, among other things.

> button:last-child, .button:last-child { margin-right: 0; }

This kind of thing is smelly.

> ol { column-count: 2; }

This is a phenomenally bad idea. Some opt-in class, maybe. Numbered lists in general, no.

> .row .column:not(:last-child) { margin-right: 10px; }

Better, provided you’re OK with as low as two years (to the day!) of browser support (https://caniuse.com/flexbox-gap): `.row { gap: 10px }`.

> Put in four columns and you'll get four equally sized columns.

Not true, actually; put something too big in one column and it’ll cause the other columns to shrink. That’s what you get for using flexbox! (Grid, by contrast, is… well, more size-is-defined-by-the-parent-and-the-children-are-welcome-to-lump-it.)

Really, I don’t like the columns arrangement. I much prefer to use flexbox with flex-wrap and sensibly-chosen flex-{basis/shrink/grow}, so that the content defines when things can fit beside one another or wrap. The current .row and .column arrangement is much too fiddly, specific, and weird. Also the .column class name is superfluous, should have just used `.row > *`.

> input

I said I’d address this later, but I’ve taken too long on this. Suffice it to say that there are problems with how form elements other than buttons are handled in diverse colouring situations. Either override (nigh-) everything, or nothing. Never override just one of background and foreground colour.

Fascinating review.

It begs the question: is CSS beyond repair? So many footguns, so little time.

I recall browsing one of the websites collecting such CSS "frameworks" in a previous episode and was stunned by the mediocrity of it all. It is breathtaking. Basically, most of these things fail in various ways, like:

- gross display errors: it could not possibly be what the author intended, on plain current Firefox

- gross design errors: really ugly, like text outside the viewport or impossibly bad use of whitespace or colors

- responsiveness fails: becomes unusable or very ugly on a simple window resize.

That's without trying to actively find less obvious problems like things that will fall over in future, or past, browsers, in other browsers, or facing different user settings.

And this is the output of people who went out of their way to write and publish a CSS toolkit, thus presumably consider themselves competent, and maybe sell their malpractice for money to be deployed against users on the real web.

> It begs the question: is CSS beyond repair? So many footguns, so little time.

CSS has come a long way; unfortunately people get stuck on the CSS they learned 10 years ago.

As soon as I saw the width being specified in pixels and the use of custom properties like they were static like Sass variables, I was like “what are we doing?”

> font-family: sans-serif;

> Thank you for a sensible font-family.

Not sure this is sensible in 2023.

I'd suggest:

    font-family: system-ui, sans-serif;

After all, the purpose of system-ui [1] "is to allow web content to integrate with the look and feel of the native OS". Seems like a natural for something that's supposed to be minimalist.

system-ui [2] is supported by 96% of web users, so there's no reason not to use it.

[1]: https://w3c.github.io/csswg-drafts/css-fonts-4/#system-ui-de...

[2]: https://caniuse.com/?search=system-ui

system-ui is not suitable for general web content. Apps might have an argument for using it, but general web content should not use it. https://github.com/w3c/csswg-drafts/issues/3658 has some details (mostly by others, but I chip in towards the end), and I’ve written more in other threads here on HN too which you can search for.

(That `box-sizing: content-box` is a good default might be my most unpopular CSS opinion, but writing off system-ui is probably not too far off it. But I care more about it because it’s one that actually affects users, not just developers. Maybe I should get round to pestering browser makers to improve their defaults for the sans-serif generic family so that “proxy for a maybe-prettier sans-serif” goes away as a reason to use system-ui.)

> system-ui is not suitable for general web content. Apps might have an argument for using it, but general web content should not use it.

I emphatically disagree.

On most platforms, font-family: sans-serif results in Helvética or even worse, Arial, which weren’t created with with the web or screens in mind.

One could argue that a website that has any interactive elements is an app; in 2023, that’s a distinction without a difference. system-ui would work fine for an app or a website.

system-ui also gets a developer great typographical features—optical sizing, extensive internationalization support, small caps, ordinals, etc.—“for free” on current platforms without breaking anything and without downloading a font.

This is a weirdly contentious issue by web devs, but in my experience, system-ui is fine. It's used as the default in popular frameworks like Bootstrap[1], and most of the teething issues have been solved for a while now.

[1] https://github.com/twbs/bootstrap/blob/adf7b8dc4083b6ddc318e...

> I personally am one of the rare contrarians that prefers content-box for the web (simplifying my position a lot: good responsive design bases sizes and such on content, not layout).

This is interesting to me. How is content-box better for responsive design? Could you elaborate?

This stood out to me too, and makes me scratch my head a bit, because it is not in line with the otherwise pragmatic advice.

For projects that have a design made by a designer (with something like Figma/Sketch/XD) it is definitely _not_ better for responsive design. Almost all designs assume that the border is part of an element. It's the more intuitive option, plus the tooling around designs will show you the spacing _between_ borders.

Intuitive: In the real world, when I need measurements from you and you omit the conceptual borders of a thing, I'm not going to be very happy.

Then you also have the issue that many of the common idioms get hairy and intuitive. Say you put an element with a border inside a container. With content-box, your 100% values are now not respecting the border, meaning you'd have to subtract the border width in order to fit the element.

Lastly there is the philosophical argument about layout vs content. HTML/CSS does not in fact provide a meaningful and clear distinction of layout and content/structure. They do somewhat in theory, but that falls apart so quickly that you're better off just ignoring the theory and live with the practice. And on a human level, there is no clear distinction either. The letters, colors, images and shapes we put on the screen are all part of the same visual experience we try to communicate.

The notes I’ve written in my “I might eventually turn this into a blog post” file:

—⁂—

border-box is about layout, content-box about content. You should aim to design things around content, not layout: leave layout to the parent.

border-box is incompatible with ratios: you need content-box there.

border-box is only actually useful for things like making body fill the viewport.

See also what I wrote in https://news.ycombinator.com/item?id=29357636

—⁂—

Elucidating a bit more: there’s only a difference if you have border or padding, and I just find it increasingly rare for border-box to be in any way useful, because we’re generally separating layout.

Consider the row/column thing in Neat here: do you use margin on the children, or gap on the parent? Consensus is that gap on the parent is normally better: let the child be itself, and handle layout concerns at a higher level. That fits with why I say content-box is the better model for the web, the model that you should aim to think in terms of: treat border and padding as semantically part of a parent, automatically-sized component, and so if you are specifying your own dimensions, specify them relative to the content, because the border and padding are layout concerns.

Designers tend to prefer layout to lead content, because that’s what’s easiest for them. I prefer to have content lead layout, choosing dimensions to fit the content and letting the layout size itself around that.

All up, it’s still fairly nebulous, based around concepts and broad design patterns rather than concrete demonstrations, and that’s part of the reason I haven’t written it up more fully—I need to make a compelling case if I want to present it at all. (Another reason is that I just haven’t been doing any of them, really; my potential-blog-posts notes file has about 38 entries and 6,000 words, and I have another dozen or two drafts in my site, but I haven’t been focusing on that stuff recently.)

> border-box is about layout, content-box about content. You should aim to design things around content, not layout: leave layout to the parent. > border-box is incompatible with ratios: you need content-box there. > border-box is only actually useful for things like making body fill the viewport.

I get the contrarian thing, but this doesn't make a whole lot of sense.

Both border-box and content-box are about content; it's just a matter what's included or not in the width of a box. Sure, there's some truth about what designers expected, but they weren't the only ones who were confused about how a box's border and padding changed how content worked…

There's a reason why virtually every widely-used CSS framework starts by changing content-box to border-box.

It's one of those issues that if we could go back in a Time Machine, content-box would have been the default; this is the next best thing:

        html { box-sizing: border-box }
        *, *::before, *::after { box-sizing: inherit }

References

From 2012, which started it all: https://www.paulirish.com/2012/box-sizing-border-box-ftw/

Developers are so psyched, border-box has a holiday: "International box-sizing Awareness Day"—https://css-tricks.com/international-box-sizing-awareness-da...

CSS Tricks almanac: https://css-tricks.com/almanac/properties/b/box-sizing/

I’m aware of all the stuff. I just think (and have thought from the start) that it’s wrong and has missed the point, especially in a flex and grid world where (a) the difference should matter much less often, and (b) if the difference does matter, you could probably implement things better (in a way that would incidentally make the difference not matter).

If it bumps it up the queue at all: I’ve been wanting to read someone pitch this way of thinking for what feels like an age.

Personally, I went all in on border-box as agency work is always design-lead. When the work is “make this picture in css”, anything other than border-box will drive you insane.

But it’s been a few decades of us pushing responsive design, so I’m curious if content-box doesn’t have its merits. I still don’t quite grok it from your explanations here (though I will re-read them), so would love to read that essay.

> line-height: calc(1em + 0.5rem);

Even cleaner imho, at least in theory, if you dont use 'em' but 'ex' for the relative sizing, the x-height of the element's first available font.

Good looking leading is often more influenced by the x-height of a typeface than by cap height (try setting Verdana and Times with the same line-height). So especially if your design has more than one typeface, using ex makes it more consistent.

Caveat: If the metrics are not set correctly in the font file, FF on Mac, and the Windows browsers will freak out. Should not be a problem with system fonts, but if you use web fonts, keep an eye on that.

I usually also set a unitless fallback, at least on the html element.

I think you’re misunderstanding what my invocation achieves: reduced line height on larger text.

No, I am proposing you write

line-height: calc(2.5ex + 0.5rem);

instead. The effect is the same, but based on the x-height of the font used, which can be beneficial for the reasons outlined. Adjust the ex to taste, between 2 and 2.5 or so.

Ah, sorry, I missed that.

Hmm, dunno. Interesting idea, but I suspect the uncertainty of actual value might cause me very mild difficulties occasionally. I’d want to play around with it in various fonts. Its failure mode is probably worse than using em, seen in a font with particularly tall ascenders or descenders. But then again, I have a vague feeling such fonts might commonly just extend beyond their box, in which case it’s not actually any worse.

In other news, I really want wide browser support for the lh unit.

I thought that was worth drawing attention to, i hope you and project owner don't mind:

https://github.com/codazoda/neatcss/issues/29

Interesting critique. I'm curious if there's some other nice-and-simple framework you'd recommend?

Sorry, no. For myself, I prefer to start from scratch, and I’ve never been particularly satisfied with any of these sorts of ones that I’ve found.

I'm the same as you. I like resetting and adding styles to all the base UI elements to create a unique design.

I agree to everything you commented above and would have said the same. There's a couple of issues with the font, spacing and other fundamentals.

You should write this as a blog post...

And/or save their css file about an hour into any project and share it!

Author here. Thank you very much for sharing this list. I'll consider each of your points.

This seems a bit hyper-critical and OTT for a HN comment on someone's personal project. Maybe you could take these and raise as issues in OPs GitHub repository, that might be a more constructive way to feedback.

I can't agree. The comment above is extremely constructive, and I'd be glad to receive that much helpful feedback on a project I'd submitted. The advice is both well-informed and actionable. That's not something you usually get for free!

In what way are any of his points not constructive? He obviously speaks from authority and provided alternatives or feedback on all his points. I found it extremely interesting and would have loved to read even more.

> The body max-width is 800px by default. Research has shown that limiting the width can lead to better retention of the content itself, as well as a decrease in eye strain. A thinner column of text is more readable on very large monitors. This is simple to change by editing the max-width of the body element in your custom.css file.

No, edit the max-width of your _content container_. Not every pixel of a site is devoted to content worth retaining.

2KB without minification or gzip, almost fits entirely on one screen. Looks great on my iphone, too.

Would have gotten the point across better to just inline the CSS source on the landing page, or linking to the CSS file, instead of having to download a ZIP.

> Would have gotten the point across better to just inline the CSS source [...]

I agree. The way they're presenting this is truly burying the lead.

I'd suggest something along the lines of "Here are 135 lines of CSS that we like, and that we feel might be reusable".

It took me an inordinate amount of time to figure out that this was what was being presented to me here. Calling it a "Minimalist Framework" certainly pushed some buttons for me, because I'm all for minimalism, but militantly opposed to almost everything that calls itself a "framework", so as soon as I saw this, I had to go on a mission to figure out what this was, and why they put these two words in a sentence, and was then rather underwhelmed.

Yes, especially when the CSS source is already sitting in cache: https://neat.joeldare.com/neat.css

Yeah, I agree with you. I'm torn if I should use the Github release process or not on this. The "Getting Started" section lists my own preferred way to download these files. Maybe I should just get rid of this zip file. That would simplify my release process anyway, which I realize is far to complex for this little thing.

Thanks for the feedback.

Edit: I've reworded the page a bit based on this and other feedback too.

I enjoy these mini frameworks greatly. I've started to prefer minimalist, and sometimes brutalist, web pages. If I visit a page that's too noisy I switch to reader mode, so that feels like the target I'm aiming towards. The CSS I use for my blog[1] is smaller than this, but it's focused on one use case. I actually really like minimal CSS and HTML for authoring blog posts, it gets me out of the headspace of "what about this theme?", or "why is my blog build not working?" and into just writing. There's no build step, deploy is trivial, and if I need to pull in some custom JavaScript I just do it instead of fighting with some framework middleware.

HTML works really well for authoring text based content, which shouldn't be a surprise since that's what it was made for. If you've ever written web pages, then you already know the format. I write it a little different from the author and I think it looks OK.

p tags ~will self close~ can omit the end tag (thanks!)

    <p>
    A paragraph here.
    One sentence per line.

I feels like a slightly more verbose Markdown, except for lists. The best I've got is:

    <ul>
      <li>Item one
      </li>
      <li>Item two
      </li>
    </ul>

[1] https://alexsci.com/blog/improve-https-1/ as an example post. Try view source.

You don’t need </li> either:

> An li element's end tag can be omitted if the li element is immediately followed by another li element or if there is no more content in the parent element.

— https://html.spec.whatwg.org/multipage/grouping-content.html...

(Note also that “self close” is the wrong description; that’s the XML <element-name/> trailing slash feature, which doesn’t work in HTML syntax outside of SVG and MathML. This is end tag omission.)

This is interesting and I've seen others use this short syntax, but it's never worked for me. In the case of Neat, one thing I lose is the margin-bottom of my paragraph tags when I don't close.

There's lot of great feedback in this thread, however, so maybe if I apply some of that, the margin won't go away.

Yeah, I used a mix of px, em, and other oddities, because I'm a bit old school, I suppose.

Drop your list items down.

I aim to have one item per line in my frontend code. It makes a codebase much more readable at scale.

<ul> <li> Item one </li> <li> Item two </li> </ul>

The buttons and text inputs being virtually indistinguishable are a slight negative for me, but nifty otherwise. (Also the button appears to have no feedback on hover or click, that would suggest it's a button.)

Why don't buttons change on hover and/or click, like they do on both native and web usually?

Great framework. Unfortunately Apple hijack certain arrow shapes (e.g. the home button) and incorrectly display these as emoji. There’s a CSS override you can add to prevent this but I don’t remember off top of my head.

I get disappointed when a CSS "framework" lacks styling for semantic HTML too (header, nav, section, article, aside, footer).

Lookin kinda fire! I love those minimalist CSS frameworks, they are perfect for small pages

Which problem does it solve? Looks like a list of a few tweaks of some browser defaults.

Tailwind comes with a pretty nice base stylesheet that includes a number of browser tweaks and fixes.

They call it Preflight

https://tailwindcss.com/docs/preflight

Css is like sql. Doesn't need any kind of abstractions.

Inspires me to make my own as well. Thanks for sharing!

> The body max-width is 800px by default.

It should be 80ch (or 70ch), not pixels