@yyp
The way you've described it, I've had pretty much the same vision for a while. "sourcehut-like", minimal, modular, etc.
I prototyped my server in Go. Nothing much yet.
We should definitely collaborate.
@metalune@fosstodon.org
Alright. I asked because I didn't want to presume. Perhaps I should have asked, are you in a dark room right now? But either way.
I find the contrast suitable personally.
Generally, darker shades need less contrast than lighter shades, since brightness is quadratic.
If there are guidelines, perhaps that's a better thing to follow. Though I still hold my opinions :)
@metalune@fosstodon.org
Just saw them. Looks great. If you want me to nitpick:
- Your blue tinge is gone. It was nice. #111 was a recommendation.
- The cards can be darker.
Color recommendations:
body #101316
section #16191c
@metalune@fosstodon.org
Some changes I'd make:
/* use a truer dark mode that actually helps eyes at night. "kinda dark mode" mode is a plague that must be stopped */
@media(perfers-color-scheme: dark) {
body {
background: #111;
color: #ccc;
}
}
Swap <div class="project-card"> for <section> or <section class="project-card">
section {
margin: 1rem auto;
padding: 0 1rem;
}
Otherwise, excellent website.
@aurynn @atomicpoet
I'd like to point out that what you're describing as services is also useful for many people who aren't bothered with and explicitly don't want to belong to any specific group, like me.
Also, I'd rather you use a different term than service. All servers are providing a service, technically. You could instead describe servers as community-oriented or general.
@musicmatze@mastodon.technology
the #hare style guide originally had "case" indented one level, but a lot of nested source code suffered from the extra indent. "case" also originally wasn't part of the langauge.
@musicmatze@mastodon.technology
#hare is expression-based. It has the yield keyword, and a context-free grammar.
Why in-depth image descriptions are not as helpful as you might think
Imagine you're using an online shop. What you'll typically see is a list of products where each list item has a small preview image, a product name and some other metadata.
Now imagine that the shop displays a long textual description for each product instead. This is what the timeline appears like to screen reader users if long image descriptions are used. And unlike people seeing the text, they don't have the luxury of skimming to grasp vital information quickly -- they have to wait for the screen reader to read it all.
In-depth descriptions are only helpful when the user has decided the content is interesting to them. Currently, most fedi frontends put them in the attachment's alt attribute, which is fine if the user is currently viewing a single post instead of the timeline. But on the timeline, it's much more important to have quick summaries instead.
In terms of the example above, it's the same difference as when viewing a single product vs. the product list. You're only interested in the details if a product is interesting to you.
Image description on fedi are a step up from having none at all, but they're still inadequate. Ideally, you could provide both a quick summary and an in-depth description, and the UI presents both in a way that's the most helpful.
Since this possibility doesn't exist, please consider keeping image descriptions short and putting the long description in the post body.
Libre software engineer with physics background.
Maintainer for @hare date/time.
.py .go .ha ...
en es ...
\t <dl> agpl posix 9p