Almond.css: Collection of CSS styles to make simple websites look nicer(github.com)
github.com
Almond.css: Collection of CSS styles to make simple websites look nicer
https://github.com/alvaromontoro/almond.css
52 コメント
Came to the comments because of this. Font renders very thin on my Android device (Firefox and Chrome).
Setting the default font size to 200 should strike every web developer as a questionable idea. It doesn't look "elegant" or anything like that to me, it just looks off and unpleasant for regular text, with the bonus of being hard to read.
Recently I had to implement a web design where the default font weight was 300. Same there, just seems like a bad idea to me.
Fads come and go.
Ultra light fonts mostly just feel like a signifier for poorly thought-out promo content to me. Reminds me of early 2000s print ads too. Don't mean to insult the author, the same description perfectly fits the site that I had to implement.
Setting the default font size to 200 should strike every web developer as a questionable idea. It doesn't look "elegant" or anything like that to me, it just looks off and unpleasant for regular text, with the bonus of being hard to read.
Recently I had to implement a web design where the default font weight was 300. Same there, just seems like a bad idea to me.
Fads come and go.
Ultra light fonts mostly just feel like a signifier for poorly thought-out promo content to me. Reminds me of early 2000s print ads too. Don't mean to insult the author, the same description perfectly fits the site that I had to implement.
Setting the default size to 300 should strike every web developer as questionable—outside Apple’s ecosystem (where it’s more likely to pan out), it’s just narrowly tolerable in some fonts, but in most it’s outright painful on (as probably the most extreme example) Windows with a low-DPI screen. For typical meanings of 300 weight, I’d generally say flat-out don’t use it below 20px.
200, on the other hand, is unquestionably bad for body-sized type, and no one sane will disagree.
(Useful related research work here: Accessible Perceptual Contrast Algorithm, APCA, is being developed to replace the old and terrible contrast ratio calculations used in WCAG; and it takes font weight into account! https://www.myndex.com/APCA/ lets you explore this and see it visually. I said a minimum of 20px for 300 weight; APCA will tend to be a little more lenient than me, and declares a minimum acceptable font size of 17px for 300 black on white.)
200, on the other hand, is unquestionably bad for body-sized type, and no one sane will disagree.
(Useful related research work here: Accessible Perceptual Contrast Algorithm, APCA, is being developed to replace the old and terrible contrast ratio calculations used in WCAG; and it takes font weight into account! https://www.myndex.com/APCA/ lets you explore this and see it visually. I said a minimum of 20px for 300 weight; APCA will tend to be a little more lenient than me, and declares a minimum acceptable font size of 17px for 300 black on white.)
I employed another questionable technique in that project to avoid the default font-weight of 300.
The specific custom font that the design required didn't have a semibold variant, only medium.
So I declared the "Light" variant as 400 in the @font-face declaration and put regular at 500, medium at 600.
So many more "requirements" of this client and my employer were terrible, I tried my best to improve or avoid them. Too many animations, huge images, stupid scroll-related effects etc. There are multiple stakeholders involved and I tried my best to voice concerns and positively influence decisions.
In the end I just have to move on and look for better work.
So many more "requirements" of this client and my employer were terrible, I tried my best to improve or avoid them. Too many animations, huge images, stupid scroll-related effects etc. There are multiple stakeholders involved and I tried my best to voice concerns and positively influence decisions.
In the end I just have to move on and look for better work.
Here's yet another macOS developer with that setting that makes all fonts too bold, and then creates websites with very thin fonts. They're everywhere.
https://m.imgur.com/cKqFxvV
https://stackoverflow.com/questions/52485803/mac-os-x-mojave...
https://m.imgur.com/cKqFxvV
https://stackoverflow.com/questions/52485803/mac-os-x-mojave...
I'm glad you're not doing my code reviews sheesh
I’m curious what you’re objecting to. Assuming it’s the font weights thing: I expressed it that strongly because what’s written there really is catastrophically, disastrously wrong, so that in any place where it fully takes effect (as I say, its dubious salvation is that most systems won’t do what was requested) all text will be extremely thin, with a fair chance of being genuinely illegible.
It does no one any good to water down code reviews. To be sure, human sensibilities must be taken into account, but prevarication is futile and dilution harmful.
It does no one any good to water down code reviews. To be sure, human sensibilities must be taken into account, but prevarication is futile and dilution harmful.
I just think if you're going to eviscerate someone's hobby project then you should at least have the tact to balm it with some encouragement.
>catastrophically, disastrously wrong
maybe it's a semantic thing, for me i wouldn't ever describe anything to do with html, css or fonts as being "catastrophically wrong". it's a subjective opinion.
that kind of hyperbolic language is not appropriate when reviewing someone's code, it could be someone who just recently started learning...
>catastrophically, disastrously wrong
maybe it's a semantic thing, for me i wouldn't ever describe anything to do with html, css or fonts as being "catastrophically wrong". it's a subjective opinion.
that kind of hyperbolic language is not appropriate when reviewing someone's code, it could be someone who just recently started learning...
> it's a subjective opinion.
No, it’s objective. Font weight 200 at body text sizes is unequivocally bad, and should never under any circumstances be done. It’s in the same ballpark as using #ddd on #fff for your body text.
As for the phrase “catastrophically, disastrously wrong”: yes, it is particularly extreme, and I didn’t use that in the original writing (nor would I be likely to) but only in qualifying the specific point in the reply, doubling down on my judgement, and I think it’s reasonable in that context, matching the definitions of the words—though certainly on the extreme side. The specific catastrophe here is that if the user’s fonts allow the style to have full effect, the page is rendered completely illegible. This is a catastrophe and a disaster for that user. It’s similar to putting aria-hidden="true" on your body element, which will be a catastrophe and disaster for your site for that blind user who needs to use your service. To be sure it’s not on the scale of a flood that drowns an entire city, but the words are not reserved only for events of such magnitude.
Sharing a thing with others in a way that indicates that you think it’s suitable for general use, especially encouraging such use, is an invitation for frank criticism. Most people that use such things won’t know better, which makes spreading such awareness more important.
No, it’s objective. Font weight 200 at body text sizes is unequivocally bad, and should never under any circumstances be done. It’s in the same ballpark as using #ddd on #fff for your body text.
As for the phrase “catastrophically, disastrously wrong”: yes, it is particularly extreme, and I didn’t use that in the original writing (nor would I be likely to) but only in qualifying the specific point in the reply, doubling down on my judgement, and I think it’s reasonable in that context, matching the definitions of the words—though certainly on the extreme side. The specific catastrophe here is that if the user’s fonts allow the style to have full effect, the page is rendered completely illegible. This is a catastrophe and a disaster for that user. It’s similar to putting aria-hidden="true" on your body element, which will be a catastrophe and disaster for your site for that blind user who needs to use your service. To be sure it’s not on the scale of a flood that drowns an entire city, but the words are not reserved only for events of such magnitude.
Sharing a thing with others in a way that indicates that you think it’s suitable for general use, especially encouraging such use, is an invitation for frank criticism. Most people that use such things won’t know better, which makes spreading such awareness more important.
I really like working with those class less css frameworks. Very nice for prototyping. Adding tailwind in later works too.
A favorite of mine is https://picocss.com/
Here is also an extensive list for more: https://github.com/dbohdan/classless-css
i keep a list of other "drop in" css frameworks here https://github.com/sw-yx/spark-joy/blob/master/README.md#dro...
This is quite nice! Shameless plug for my version of this (sakura.css [1]) which is
- much smaller (3.9kb / 1.9kb gzipped)
- looks more in-line with the default browser styles (demo [2])
- but does not use css variables yet, instead different themes are provided as different css files. My reasoning for this is that if you're using this you probably don't want to mess around with css too much :)
[1]: https://github.com/oxalorg/sakura
[2]: https://oxal.org/projects/sakura/demo/
- much smaller (3.9kb / 1.9kb gzipped)
- looks more in-line with the default browser styles (demo [2])
- but does not use css variables yet, instead different themes are provided as different css files. My reasoning for this is that if you're using this you probably don't want to mess around with css too much :)
[1]: https://github.com/oxalorg/sakura
[2]: https://oxal.org/projects/sakura/demo/
Thanks and you've actually got a demo
There is a demo for almond.css at the bottom of the second paragraph: https://alvaromontoro.github.io/almond.css/demo/
Certainly could stand to be elevated in the readme as it's generally the first thing people look for.
Certainly could stand to be elevated in the readme as it's generally the first thing people look for.
I think this is quite an opinionated version of nicer and better. I'm personally not a fan of the thin fonts. If it was framed as a class of CSS styles to make websites have that style of super-thin fonts I'd be ok with it. My issue with this is the framing of what the CSS library is.
There are some small unresolved issues with line, heading and paragraph spacing too (particularly around multi-line list items here).
Which is not to be overly critical because a lot of this stuff is art more than science, and it's hard to pin down precisely what is wrong without recalculating quite a lot, but I don't think this feels quite as balanced as it could.
Which is not to be overly critical because a lot of this stuff is art more than science, and it's hard to pin down precisely what is wrong without recalculating quite a lot, but I don't think this feels quite as balanced as it could.
I always tend to feel a bit agitated when the word 'nicer' or 'beautiful' is included in a headline or product tout. I get the idealistic idea behind this, but please tell me what is wrong with default browser rendering? It's consistent, fast and maintenance-free.
It might not be following the latest design trends. But why should that be a thing? Staying clear from trends is something that simple (informative) websites _should_ have.
It might not be following the latest design trends. But why should that be a thing? Staying clear from trends is something that simple (informative) websites _should_ have.
please tell me what is wrong with default browser rendering
I'll take that bait.
- The default font is Times New Roman. It's hard to read at the best of times, but on a mobile device it's truly horrible.
- By default the color scheme is black text on white with bright blue links. On a page that has links embedded in paragraphs the sharp contrast change makes the links stand out too much, making text less readable.
- Browsers make text expand to fill the window with an 8px margin. On a 4K monitor with a maximised window that means the margin is 0.21% of the available space and paragraphs are usually just one long line of text. Again, it's not very readable.
- Browsers don't apply 'text-rendering: optimizeLegibility;' by default, so the algorithm used for anti-aliasing makes the text (guess what's coming...) less readable, but it does render faster by a few milliseconds.
- Forms can layout very weirdly if you're not careful, with spacing around labels that makes it unclear what element the label applies to.
There's a lot more to add, but I'll stop there.
The fact is that browsers have moved on, display tech has changed, and there's a much wider range of devices used to view pages. There just isn't a set of defaults that works well any more. I'd argue that there isn't even a single set of defaults that could work - websites need to optimize the way content is displayed for the device being used. The defaults for a small mobile device should be very different to the defaults for an 8K HDR monitor. Relying on the browser to work out how something should work for a user just won't work now.
I'll take that bait.
- The default font is Times New Roman. It's hard to read at the best of times, but on a mobile device it's truly horrible.
- By default the color scheme is black text on white with bright blue links. On a page that has links embedded in paragraphs the sharp contrast change makes the links stand out too much, making text less readable.
- Browsers make text expand to fill the window with an 8px margin. On a 4K monitor with a maximised window that means the margin is 0.21% of the available space and paragraphs are usually just one long line of text. Again, it's not very readable.
- Browsers don't apply 'text-rendering: optimizeLegibility;' by default, so the algorithm used for anti-aliasing makes the text (guess what's coming...) less readable, but it does render faster by a few milliseconds.
- Forms can layout very weirdly if you're not careful, with spacing around labels that makes it unclear what element the label applies to.
There's a lot more to add, but I'll stop there.
The fact is that browsers have moved on, display tech has changed, and there's a much wider range of devices used to view pages. There just isn't a set of defaults that works well any more. I'd argue that there isn't even a single set of defaults that could work - websites need to optimize the way content is displayed for the device being used. The defaults for a small mobile device should be very different to the defaults for an 8K HDR monitor. Relying on the browser to work out how something should work for a user just won't work now.
• The default font is a serif, which on most platforms means Times New Roman. It’s not the greatest font out there, but it’s generally quite good for legibility provided you don’t shrink it too much. It’s not horrible in the slightest on a mobile device. You may just be used to sans-serif fonts.
• The default colours of #000 on #fff with #00e for links is excellent contrast that achieves precisely what is desired. Certainly it is a little more than is necessary, and I prefer to tone it down a little to #03d, but it’s not bad.
• Yeah, the full width body and 8px margin is not a default style that has aged well. You know how mobile devices took up the meta viewport tag and the text size adjustment algorithm, because sites were designed for larger screens? It’d be kinda nice, as a theory, if browsers would perform a similar intervention for large and wide screens (using the existing meta viewport tag as the signal); but in practice, few enough sites and people would benefit from it that they’re not going to do it.
• Please don’t touch text-rendering. On most platforms the effect is not noticeable with a side-by-side comparison even if you’re looking for it, and where there are differences, not everyone agrees about which is better. On slow devices that support the property (a mistake, they should just disable it), it murders performance on long pages. Just let the browser do its thing. There’s generally low-hanging fruit in text layout and rendering on websites that has a much more significant effect on readability. (Also, blame Apple for deliberately ruining text rendering for low-resolution screens some years back.)
• Forms: eh, they’re simple and clear enough, so long as you lay them out with appropriate line breaks, table cells or paragraph margins. Certainly a sequence of <div><label>…</label><br><input></div> will be confusing, but when you consider the scope of what base stylesheets like this cover, they don’t tend to change the situation on form spacing and grouping at all.
• The default colours of #000 on #fff with #00e for links is excellent contrast that achieves precisely what is desired. Certainly it is a little more than is necessary, and I prefer to tone it down a little to #03d, but it’s not bad.
• Yeah, the full width body and 8px margin is not a default style that has aged well. You know how mobile devices took up the meta viewport tag and the text size adjustment algorithm, because sites were designed for larger screens? It’d be kinda nice, as a theory, if browsers would perform a similar intervention for large and wide screens (using the existing meta viewport tag as the signal); but in practice, few enough sites and people would benefit from it that they’re not going to do it.
• Please don’t touch text-rendering. On most platforms the effect is not noticeable with a side-by-side comparison even if you’re looking for it, and where there are differences, not everyone agrees about which is better. On slow devices that support the property (a mistake, they should just disable it), it murders performance on long pages. Just let the browser do its thing. There’s generally low-hanging fruit in text layout and rendering on websites that has a much more significant effect on readability. (Also, blame Apple for deliberately ruining text rendering for low-resolution screens some years back.)
• Forms: eh, they’re simple and clear enough, so long as you lay them out with appropriate line breaks, table cells or paragraph margins. Certainly a sequence of <div><label>…</label><br><input></div> will be confusing, but when you consider the scope of what base stylesheets like this cover, they don’t tend to change the situation on form spacing and grouping at all.
> - Browsers make text expand to fill the window with an 8px margin. On a 4K monitor with a maximised window that means the margin is 0.21% of the available space and paragraphs are usually just one long line of text. Again, it's not very readable.
Disclaimer: I'm an old coot and my hardware is lagging behind, still on a single 22" display on my desktop, etc, etc, so I am most likely missing something, AND your overall argument here does appear sound, but I do found myself wondering:
why, if you have a 4k display and massive amounts of screen realestate, do you have a maximized browser window? I mean, with my crappy hardware I can understand why I am doing it, but I assume that I am the odd one/edge-case here, not you.
Disclaimer: I'm an old coot and my hardware is lagging behind, still on a single 22" display on my desktop, etc, etc, so I am most likely missing something, AND your overall argument here does appear sound, but I do found myself wondering:
why, if you have a 4k display and massive amounts of screen realestate, do you have a maximized browser window? I mean, with my crappy hardware I can understand why I am doing it, but I assume that I am the odd one/edge-case here, not you.
Because 99% of the websites I browse are optimised for wide screens and/or contain lots of information that legitimately fill my 4K screen. I'm not going to resize my entire browser window for that one special snowflake that doesn't use CSS on their blog, I'm simply navigating away.
why, if you have a 4k display and massive amounts of screen realestate, do you have a maximized browser window?
It's the job of every web dev to write code that works everywhere. If the user has chosen to run their browser maximised on a 4K monitor that's their choice. When you write code, saying "the user is using it wrong" is never going to be an acceptable excuse for shipping something that doesn't work well for everyone in my opinion.
It's the job of every web dev to write code that works everywhere. If the user has chosen to run their browser maximised on a 4K monitor that's their choice. When you write code, saying "the user is using it wrong" is never going to be an acceptable excuse for shipping something that doesn't work well for everyone in my opinion.
Where did you get that impression? Web developers aim to write code that works for most, most of the time. If you happen to be using netscape navigator or using an 8k monitor at maximum scale you won't be in a group that qa can cover. As more people get 4K more websites will support it.
>saying "the user is using it wrong" is never going to be an acceptable excuse
unless you're Steve Jobs
unless you're Steve Jobs
If anyone is browsing the web fullscreen at 4k and complaining that the web pages are too wide, I'm not sure the problem is with the stylesheet
> please tell me what is wrong with default browser rendering?
Default renderings, plural, because each browser's default is inconsistent with the next browser, and are generally regarded as ugly. You might disagree and think they are the height of informative minimalist beauty, but given that nearly zero websites use the default browser style, calling a "design trend" the use of CSS, is like calling a "fashion trend" this "wearing clothes" thing that people do these days.
Default renderings, plural, because each browser's default is inconsistent with the next browser, and are generally regarded as ugly. You might disagree and think they are the height of informative minimalist beauty, but given that nearly zero websites use the default browser style, calling a "design trend" the use of CSS, is like calling a "fashion trend" this "wearing clothes" thing that people do these days.
For better or worse (I think better) a little polish and minimal effort gives a huge amount of credibility/trustworthiness to a website.
Projects like this are even trying to make it so easy you don’t have to do much of anything.
“I’d like my website to not use this” is an odd criticism. You aren’t being made to use it in any case.
Projects like this are even trying to make it so easy you don’t have to do much of anything.
“I’d like my website to not use this” is an odd criticism. You aren’t being made to use it in any case.
Nothing.
*Depending on the kind of content.
We probably shouldn't have tossed nearly every internetworking content distribution idea into a giant bucket labeled browser.
*Depending on the kind of content.
We probably shouldn't have tossed nearly every internetworking content distribution idea into a giant bucket labeled browser.
Default font weight is way too low.
I honestly thought that went out of style about 10 years ago.
I ran a gallery page called unreadable.website that featured the worst offenders.
I had thought the problem mostly went away. Even let the domain lapse. Here's the code https://github.com/kristopolous/lowcon
I ran a gallery page called unreadable.website that featured the worst offenders.
I had thought the problem mostly went away. Even let the domain lapse. Here's the code https://github.com/kristopolous/lowcon
I'm a fan of Sakura[0] for this purpose. About the same size, different design choices. It hasa recently-added dark version, which can do the OS-choice switch without javascript.
[0] https://oxal.org/projects/sakura/
[0] https://oxal.org/projects/sakura/
Making something look good does not require a whole lot of CSS.
Over time, I learned that I did not need to use frameworks to make good-looking websites. I have adopted a philosophy of minimalism when it comes to overriding the default user agent styles. The fewer layers of overrides and indirections, the better.
Simply throwing border-collapse on top of a plain-ass HTML report can make all of the difference in the world.
I just checked the site.css for my most recent internal web project and it's sitting right at 1,148 bytes. That's un-minified, human-friendly bytes. Can't imagine I would need to tweak it much further from this point.
Over time, I learned that I did not need to use frameworks to make good-looking websites. I have adopted a philosophy of minimalism when it comes to overriding the default user agent styles. The fewer layers of overrides and indirections, the better.
Simply throwing border-collapse on top of a plain-ass HTML report can make all of the difference in the world.
I just checked the site.css for my most recent internal web project and it's sitting right at 1,148 bytes. That's un-minified, human-friendly bytes. Can't imagine I would need to tweak it much further from this point.
Non-insignificant part of my job is deleting css (and js)
i was looking at this earlier and thought it would make for a great starter kit for a personal design system. it has enough meat to it to feel like you're not starting from scratch, but not so much that you'd be fighting the defaults very much. i find the choice of hsl colors a little odd (and font weights a little light, as others have mentioned), but overall, it's a solid base. and it accounts for every html tag, not just a somewhat arbitrary selection of them.
i've been trialing some css frameworks (bootstrap, bulma, semantic/fomantic, tailwind) for a side project, and i dislike each for various reasons. bootstrap and tailwind encourage class soup, while bulma encourages div soup. semantic/fomantic have a pretty dated looking design language, though the semantics (ha) are much better.
so that led me to thinking about creating my own design system with something like almond.css as a base, so i don't have to deal with the analysis paralysis that comes with bootstrapping from scratch.
i've been trialing some css frameworks (bootstrap, bulma, semantic/fomantic, tailwind) for a side project, and i dislike each for various reasons. bootstrap and tailwind encourage class soup, while bulma encourages div soup. semantic/fomantic have a pretty dated looking design language, though the semantics (ha) are much better.
so that led me to thinking about creating my own design system with something like almond.css as a base, so i don't have to deal with the analysis paralysis that comes with bootstrapping from scratch.
I like this tool for previewing many drop-in CSS frameworks (doesn't look like Almond is in the list yet):
https://dohliam.github.io/dropin-minimal-css/
https://dohliam.github.io/dropin-minimal-css/
Thanks! Almond CSS has now been added to the list:
https://dohliam.github.io/dropin-minimal-css/?almond
https://dohliam.github.io/dropin-minimal-css/?almond
It would be helpful if there was a website with demos available.
beyond the demo that's linked in the readme?
https://alvaromontoro.github.io/almond.css/demo/
https://alvaromontoro.github.io/almond.css/demo/
Very nice-looking! When I read the title I was skeptical about YACSSF (yet another CSS framework), but this is absolutely a worthy addition to the canon. Well done.
But blue titles? Blue for hyperlinks, surely. Also, the buttons don't look like buttons.
Alhough I disagree about the buttons, and don't think blue titles are a big deal, I do think those are valid criticisms.
Easy enough to change those, yeah, if you like the rest of it?
Easy enough to change those, yeah, if you like the rest of it?
> By combining some "not-too common" HTML attributes with some CSS variables, we can generate a series of widgets without the need to use JavaScript or HTML classes.
This sounds suspiciously like abusing semantic attributes for display purposes. At which point, surely it would be much better to use classes?
Come to think of it, what is behind the design goal of avoiding classes?
This sounds suspiciously like abusing semantic attributes for display purposes. At which point, surely it would be much better to use classes?
Come to think of it, what is behind the design goal of avoiding classes?
> This sounds suspiciously like abusing semantic attributes for display purposes.
You don't need to be suspicious. The code is right there to evaluate at the bottom of [the demo](https://alvaromontoro.github.io/almond.css/demo/). The circular progress widget shows this:
You don't need to be suspicious. The code is right there to evaluate at the bottom of [the demo](https://alvaromontoro.github.io/almond.css/demo/). The circular progress widget shows this:
<div role="progressbar" aria-valuenow="33" aria-valuemin="0" aria-valuemax="100" style="--value: 33"></div>
Maybe with pseudo elements (::before,::after) and gradients?
HSL and HSV are terrible color representations for theming like this. You are just asking for chroma issues. LCH and Lab (along with OKLCH and OKLab) are offered in the CSS4 spec. If you can't support CSS4, it's better off having users specify the whole color.
is it worth the complication of learning about the different color space options for the average developer? why aren't hex values 'good enough'? it's unclear (as a non-specialist) what problems those options are trying to solve.
I wouldn't say I disagee with you which is why I mentioned just allowing a full color, be that hex, rgb, hwb, lab, etc... including color() which lets you define in absolute terms in various color spaces.
The demo has a <input type="date">, but it seems to have suppressed the normal html date picker, without using any javascript. I'm using windows/chrome. How it is doing that?
List of classless CSS frameworks:
https://github.com/dbohdan/classless-css
https://github.com/dbohdan/classless-css
Not exactly related to the CSS, but to the demo. I had not realized that (desktop) browsers actually had functioning date and time pickers now, without JS. Fantastic!
The fonts are so thin, what is wrong with you
This is the third classes css framework I've come across on HN. Please everyone realise this is a great tool for prototyping or projects you want to deploy, deliver and forget about.
Any serious application that you expect to expand on, that needs some level of customisability or needs to import/use third party components(!) like a datepicker should not use classless css. it's a prototyping tool. It's highly incompatbile with everything besides what you write yourself, because it overwrites the defaults, it's inflexible.
Having classless styling has been possible for as long as css has existed, and it's for good reason that this is not in widespread use in usual application development.
Having said that though, I really like how this one looks it's an improvement without going overboard on anything, good job.
Any serious application that you expect to expand on, that needs some level of customisability or needs to import/use third party components(!) like a datepicker should not use classless css. it's a prototyping tool. It's highly incompatbile with everything besides what you write yourself, because it overwrites the defaults, it's inflexible.
Having classless styling has been possible for as long as css has existed, and it's for good reason that this is not in widespread use in usual application development.
Having said that though, I really like how this one looks it's an improvement without going overboard on anything, good job.
Looks like they slipped past their alleged limit and didn’t notice or didn’t update their documented target. My observation with this kind of stylesheet is that they normally do slip like this.
I would also say that 19KB/4KB gzipped is not particularly lightweight for this type of stylesheet, though in its defence it is more thorough in its element coverage than most (… which just means that the significant majority of it will be dead code on most pages).
For the rest, I’m not going to go into it (nothing stands out as particularly good or bad) save this one point that offends me greatly:
These figures are offensive. 700 is bold, 400 is normal, 300 is unpleasantly thin at 16px on most platforms and most fonts (macOS under default configuration being the exception, as they perform glyph dilation that no one else does), 200 is illegibly thin below maybe 30px, and 100 is hairline, not to be used below around 50px. The font stack of `Helvetica, Arial, sans-serif` is the dubious salvation of these weights (a dodgy font stack too, by the way, better simplified to just sans-serif), as I think (but certainly don’t know) that all platforms will by default resolve this to a font that does not possess a lighter weight than 400. But if someone has it resolve to a font that does contain a weight below 400, you’ve just wrecked the page for them.