mirror of
https://github.com/VSCodium/vscodium.github.io.git
synced 2026-04-10 20:50:00 -05:00
https://vscodium.com/ code snipets are poorly readable (pale text on pale bacgkround) #30
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @matkoniecz on GitHub.
Describe the bug
https://vscodium.com/ code snipets are poorly readable (pale text on pale bacgkround)
Please confirm that this problem is VSCodium-specific
It is about VSCodium website and "this site is open source" in footer linked to this repo
Please confirm that the issue/resolution isn't already documented
To Reproduce
Steps to reproduce the behavior:
Expected behavior
All text on website is readable
Screenshots
Desktop (please complete the following information):
Additional context
If "make all text in code snippets 100% black, potentially also make backgrounds closer to white" or "make background 100% black, make all text white" would be accepted and it is fixable by editing CSS file (without some extreme nodejs hell) then I can make a PR.
@stripedpajamas commented on GitHub:
I merged #25 -- what do you think of it @matkoniecz ?
https://vscodium.com/
@matkoniecz commented on GitHub:
@chadlavi It may be worth reporting as a new issue, this will be closed once this specific visibility issue is fixed.
@chadlavi commented on GitHub:
open source projects always struggle with accessibility, because they're often developer-led, small-scale/community efforts. It looks like the vscodium site has a lot of the common pitfalls.
altattributesoutline: 0for focused links. That breaks accessibility if you don't create some other visual identifier for the focused state of links. Links need a visible focus stateIf you aren't used to designing for accessibility, just try navigating the page with your keyboard only. You'll find a lot of low-hanging fruit that way. You can also use the Chrome dev tools "Lighthouse" auditor to check for accessibility problems.
@stripedpajamas commented on GitHub:
It's not useful... I'd like to get the dark red out of there.
@matkoniecz commented on GitHub:
Thanks, it is much better!
But is it useful or necessary to have this dark red color? On dark background it becomes poorly readable in turn and I see no benefit in readability from styling some parameters and
&&differently.At the same time this part of the text styled red becomes the most noticeable (I notice this letter group and later rest of the text) and less readable.
And if
&&and long style parameters (note in Arch Linux section that short style parameters are not getting such styling) should be styled specially maybe something less distinct from rest of the text and more distinct from the bacgkround would be better?