Simple.css – A classless CSS framework
simplecss.org
simplecss.org
If you are into these simple classes, check out Drop-in Minimal CSS[2] and choose the one that fits your need.
Simple.css is from an interesting guy, Kev Quirk[3], whose 512kb[4] website was on Hackernews a while back (don't recollect if it was a story or a comment). Hi Kev, if you are around.
If you are spinning up a simple website with classless styles, perhaps it is a good idea to add a print styles and I like Gutenberg[5] for that.
1. https://oinam.github.io/oinam-jekyll/
I had absolutely no idea that you can have such a color picker with pure HTML. When I click on it, my browser's color picker comes up. This is amazing. I always had issues picking the right color picker or implement my own. I love the date input as well! Thank you!!!
If you give the colour picker a little more height than the one in that link then it'll display the selected colour as well, which you can see in the MDN one.
Thanks for all the feedback and comments here, folks. It really is appreciated.
I’m not a professional web designer - this just started off as a personal project that I ended up publishing as people I shared it with seemed to like it.
I’m taking on board the various feedback from people much more knowledgeable than I here, again I really appreciate it.
If you do have feedback/changes I’d urge you to log an Issue or a PR on Github[1].
Also great to see so many other minimal CSS projects that I wasn't aware of. I’ll have to add an alternatives page to the site, I think.
Anyway, I'm confused about what makes something a CSS 'framework'. I feel like I just want decent defaults more than a framework, and that seems to be what this basically comes down to. Is there anything else to it?
I would argue that “frameworks” like Bootstrap, Tailwinds and their ilk are more ecosystems than frameworks, but that’s just me. :)
There is also an open PR to add Simple.css to the list: https://github.com/troxler/awesome-css-frameworks/pull/85
https://developer.mozilla.org/en-US/docs/Web/CSS/:required
Client-side form validation - https://developer.mozilla.org/en-US/docs/Learn/Forms/Form_va...
Nice work.
https://news.ycombinator.com/item?id=29565438
Edit: also in here it’s a tool to quickly compare them all. I don’t know if one can mention a user so I’ll just link the comment.
<button onclick="window.location.href='https://example.com';">I'm a button with a link</button>
This code from the demo shows, why not using classes to style a website is a misguided idea.Maybe something like this would be a better idea if you absolutely must avoid classes:
https://jsfiddle.net/qa2cdj4v/
<strong><a href="#">Button</a></strong>
strong > a:first-child:last-child {
display: inline-block;
background: red;
color: white;
padding: 10px;
font-weight: normal;
} <form action="https://example.com"><button type="submit">Link button</button></form>
no need for JSThe worst part is that it's not just random websites doing this, this can be found on most FAANG websites as well.
Aside from that, the semantic styling for `header` and `nav` is really clever and well done. Looks good.
header h1, header p {
margin: 0;
}That aside, nice work! This could surely be useful as a default stylesheet for Markdown documents and the like.
[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ci...
Frankly, since the cite element has no implicit ARIA role and is normal flow and phrasing content, it’s roughly just another spelling of <i>. Don’t worry too much about its nominal semantics, they’ll probably tweak them again before long.
It's encouraging to see people still using new.css though, and I hope to work on upgrades soon!
1. they think it makes newer devs can feel safer
2. dev teams can simply agree on an pre-made modus-operandi for all css without having to have discussions/evolutions on it.
But for 1, it also gives newer devs a steeper learning curve, and it gives older devs Yet Another Framework to learn and then possibly discard in a few years. It's also often used like a crutch, where yes the newer dev may feel safer, but they're also not exposed to as many discussions or reasoning around well-organized styling, cleaner semantics, etc.
And for 2, it can also add overhead to dependency audits and often for the large frameworks with pre-made components you can end up spending significant resources fighting/working around the framework components when the inevitable unforeseen use-cases come up
I also agree with your other point that that is a benefit for having more bells and whistles in a single branch of dependencies.
But always happy to see more classless CSS options.
Disclosure: Author of MVP.css
I created my own classless CSS framework[1] in the same vein. It adapts to your system’s dark/light mode and is under 1kb minzipped.
I would recommend to check out the drop-in minimal CSS page if you want do discover new projects like these.
• https://meyerweb.com/eric/tools/css/reset/
• https://piccalil.li/blog/a-modern-css-reset/
• https://www.joshwcomeau.com/css/custom-css-reset/
• http://www.vcarrer.com/2010/05/css-mini-reset.html
Normalize:
• https://necolas.github.io/normalize.css/
• https://csstools.github.io/sanitize.css/
Starters:
• https://andybrewer.github.io/mvp/
Just curious about the thoughts since I have never dived the classless CSS train. Also am new to front-end.
Why not just use Tailwind? It, for example, essentially requires a front-end build step: it must read your source HTML files in order to know which CSS rules to bundle. (Without that it would have no choice but to serve a multi-megabyte stylesheet with all possible selectors.) Tailwind may be a good choice if you need more control over appearance, you are OK involving Node at pre-build, but you can’t write isomorphic GUI components—e.g., you’re providing server-rendered HTML with a non-JS back-end.
The emphasis away from semantic HTML and towards component-based frameworks with all the associated utility CSS classes has been a disaster for accessibility, and it's good to see projects that have all users in mind.
Granted you do see things like divs with click handlers used as buttons by people who don't know what they're doing, but I saw plenty of that in the jQuery days too.
we just need better tooling to write better CSS faster not necessarily including prewritten CSS.
I deeply believe this is where CSS going and this why I'm building https://intab.io to push towards that direction myself.
I'm afraid I don't understand the goal here. This is excatly what classless frameworks like Simple.css are doing, and classless is imo a much better solution than us all agreeing onto standard variable names.
For example, TFA says that simple.css uses a variable called "accent" to determine the color of links and buttons. If other styles adopt the same name, then you could just define the "color palette" in one place and have each library working as totally different "design language".
img, video { opacity: 0.6; }
Do not like. Not even for dark mode.Which I believe I found here on HN some time ago.
enjoy!
Maybe it’s possible to build something similar based on tailwind (with a lot of @apply), which would allow customization.
--sans-font: -apple-system, BlinkMacSystemFont, "Avenir Next", Avenir,
"Nimbus Sans L", Roboto, Noto, "Segoe UI", Arial, Helvetica,
"Helvetica Neue", sans-serif;
--mono-font: Consolas, Menlo, Monaco, "Andale Mono", "Ubuntu Mono", monospace;
Here are better stacks that achieve almost identical results for almost all users that haven’t customised their font stacks, but respect user preferences better: --sans-font: system-ui, sans-serif;
--mono-font: Consolas, monospace;
(If Mozilla would get on and fix <https://bugzilla.mozilla.org/show_bug.cgi?id=713680>, I’d ditch Consolas, though you won’t want to leave it at just monospace because of the stupid default monospace font size thing [that should really never have happened but should absolutely have been retired by a decade ago], so most people write `monospace, monospace`, though I like to shorten it to `monospace,m`.) /* Line height is set to the "Golden ratio" for optimal legibility */
--line-height: 1.618;
That comment seems disingenuous, especially given the `line-height: 1.1` applied to headings which shows an awareness of the issues. There is no single optimal value: it varies by font, by size, by line width, by reader’s eyesight… you can’t just slap a nice mathematical ratio on it and call it optimal. As it stands, 1.618 is decidedly on the high side, though not outlandishly so. I personally prefer 1.4. body {
overflow-x: hidden;
}
Please don’t. If this does anything, it’s a sign that you’ve written something the wrong way, and if it doesn’t, you should be scared that it will in the future, and will cut off some content and render it inaccessible, rather than breaking out of your site layout but leaving the content intact. In this case, it looks to have been done because the width limit was applied to the body element, but not desired for the header and so worked around, but the trouble is that you can’t do that correctly because CSS doesn’t have suitable units (vw and vh are fundamentally stupidly broken by design (the spec provided an esoteric way of unbreaking them, but only Firefox implemented it, so eventually they removed it), and always wrong, though the amount of error is sometimes tolerable for some restricted purposes). The width limit should rather have been applied to descendants of the body (main/footer); then you could leave the body overflow alone. @media (prefers-color-scheme: dark) {
img,
video {
opacity: 0.6;
}
}
Eww. Eww. This is a horrible idea to apply as a general rule: it’ll be suitable for some images (… by accident as much as anything), but ruin others; and a 40% reduction is excessive. But not only that, opacity is the wrong technique, being sensitive to the background (the most extreme example: put an image inside a <button>); a filter using brightness and/or contrast would be better.—⁂—
Although I’m not impressed with some of the stuff at the start of the stylesheet, after that it looks pretty solid. There are occasional points that I’d quibble over, but nothing major. I’ll stop here, this comment is already moderately long.
Hmm. I always seem to do some kind of review when these things come up here, can’t quite help myself; I should get on and finish starting that new section on my site for such matters (reviews, occasionally of projects, more of code, mostly CSS/JS/Rust).
It's for making simple, semantic HTML look decent. That's useful.
https://css-tricks.com/a-complete-guide-to-dark-mode-on-the-...
It's a nice idea, but I'm not sure how universal accepted this "rule" is, as it does wash out the image quite a bit.
A more conventional looking navigation similar to Bootstrap's would be nice.
Ah well.
And if I have CSS integrated in my build (using Next.js or something), importing it will add it to the build bundle size info.
It's homogenous and where I'd expect to find things.
There's of course no reason to start using npm wizardry for simple.css alone. That would be silly.
Will be using this for quick lightweight websites.
It's a bit like shared libraries in linux, you might just use the library that almost everyone has installed or you compile a static binary, both solutions have their pros and cons.
Cache keys are now tuples of (host, resource) so if you download and cache bootstrap.js on example.com, and then go to bootstrapsite.com which hosts the same JS file, you'll have to download it again because the cache keys are different:
example.com -> bootstrap.js -> cached as (example.com, bootstrap.js)
bootstrapsite.com -> bootstrap.js -> cached as (bootstrapsite.com, bootstrap.js)
(example.com, bootstrap.js) ≠ (bootstrapsite.com, bootstrap.js)