Show HN: Neat – Minimalist CSS Framework (neat.joeldare.com)

I wish CSS tools had unique names

https://neat.bourbon.io/

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!

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

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.

> 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.

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);
  }

...

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

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

Neat.

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.

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

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

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

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

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.)

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

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

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.

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.

> 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.

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

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