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.
I think you're conflating two points there. Component-based frameworks and utility CSS are completely orthogonal to the use of semantic/accessible HTML.
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.
new.css developer here, thank you :) Happy to see people still enjoying it. I've been meaning to update it for a very long time, but have been working through a lot of coding-based anxiety and burnout for a while.
It's encouraging to see people still using new.css though, and I hope to work on upgrades soon!
Nice. Comparing with MVP.CSS, another class-less CSS framework, this has less feature (MVP has a way to create cards), but also seems to avoid two things that I don't like about MVP: centered block quote, and links without underline.
Im a firm believer in links being underlined. I also wanted it to be a little opinionated, as to started life as a personal project, yet easy to customise.
I can see straight away from the home page that there isn't enough margin before h1 > p in the case of the title, and the vertical rhythm is a bit off.
Aside from that, the semantic styling for `header` and `nav` is really clever and well done. Looks good.
I wish more designers would look at these minimalist frameworks and add helpful feedback like this. I feel like the aesthetics of a lot of them could be improved with more attention from designers.
I suppose you could argue it's really just a mind set.. I took from it the idea of classless. Which I've not really used.
It would mean you'd have to have a deeper knowledge of the tags that are available. Which as you said, would boil down to about the same as classes.
A lot of people like the larger, more thorough frameworks because:
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 see a bit of straw man here -- thorough frameworks are often liked _because_ they're thorough. Simple.css looks fantastic and I'll reach for it next time I make a simple personal site, but for a professional website with a hundred pages and design considerations that go way beyond "it should look pleasing", I need more levers, leverage, and turnkey components.
I certainly see your point that any unsatisfactorily complete benefit-drawback list is going to seem like a strawman. I meant to point out some of the more commonly stated benefits and contrast them to the less commonly considered drawbacks, but I would also enjoy seeing this thread evolving into a more complete list.
I also agree with your other point that that is a benefit for having more bells and whistles in a single branch of dependencies.
Well one advantage could be that you get the tooling around versioning in case you want automatic minor version updates or stuff like that. And I guess others might find value in inserting it using their bundler as described in the docs if they have other css-related tooling in their bundler like minification or linting.
This might sound like a good idea, but sooner or later you will need to integrate some third party library, and you’ll see that properly scoping your styles is better.
Now, all we need is to get to take these CSS libraries turn into "themes" for https://headlessui.dev/ widgets. Bonus points if we agree onto some standard set for variable names, so frontend developers could then literally just change the "import css" file at the top and have completely different styles.
> just change the "import css" file at the top and have completely different styles.
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.
It's not just because these are "drop-in" files that like these libraries can not be extended or have some variables overridden.
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".
I see that now, seems like the site should list out the variables that it uses, and which is used for each element. It mentions `accent` for links, but seems like a handful are defined.
This is nothing new, and it's a bad idea to use this in production. Component you import assume a certain set of default styling, if you overwrite the defaults it'll cause issues.
Same as for overwriting javascript prototypes
108 comments
[ 2.4 ms ] story [ 192 ms ] threadThe 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.
1: https://nicolasgallagher.com/about-normalize-css/
It's encouraging to see people still using new.css though, and I hope to work on upgrades soon!
[0]: https://watercss.kognise.dev/
[0]: https://vanillacss.com
But always happy to see more classless CSS options.
Disclosure: Author of MVP.css
Aside from that, the semantic styling for `header` and `nav` is really clever and well done. Looks good.
header h1, header p {
• 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://simplecss.org/
• https://andybrewer.github.io/mvp/
• https://watercss.kognise.dev/
• https://vanillacss.com/
• https://newcss.net/
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.
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.
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.
It's for making simple, semantic HTML look decent. That's useful.
Will be using this for quick lightweight websites.
https://simplecss.org/demo#links--buttons
https://simplecss.org/demo#other-typography-elements
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".
They try: https://www.w3.org/community/design-tokens/
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.