Almond.css: Collection of CSS styles to make simple websites look nicer
github.com
github.com
$ curl -H 'accept-encoding: gzip' -I https://alvaromontoro.github.io/almond.css/dist/almond.min.css | grep content-length
content-length: 4198
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:
--font-weight-bolder: 700;
--font-weight-bold: 400;
--font-weight-normal: 200;
--font-weight-thin: 100;
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.
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.)
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.
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.
>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...
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.
https://stackoverflow.com/questions/52485803/mac-os-x-mojave...
- 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 :)
Certainly could stand to be elevated in the readme as it's generally the first thing people look for.
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.
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.
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.
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.
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 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.
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.
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.
unless you're Steve Jobs
*Depending on the kind of content.
We probably shouldn't have tossed nearly every internetworking content distribution idea into a giant bucket labeled browser.
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
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.
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.
Easy enough to change those, yeah, if you like the rest of it?
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?
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>
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.