InternationalScratchWiki / ScratchWikiSkin2

Skin for the Scratch Wiki.
https://en.scratch-wiki.info
MIT License
17 stars 16 forks source link

Make the dark skin more customizable #136

Open starlightsparks opened 3 weeks ago

starlightsparks commented 3 weeks ago

I propose we make the dark skin more customizable—Being able to change the header(which is grey).

Kenny2github commented 2 weeks ago

If by "accent color" you mean that of links etc., customizing that is not something we will support. It's too tightly tied to the rest of the design, and it's not customizable on light mode anyway.

The header color is not customizable on dark mode mainly to avoid users setting a header color in light mode, then switching to dark mode and finding that the header is unreadable due to the inverted text color. I'm open to allowing dark theme header color customization as long as it a) does not involve adding a separate color setting, b) guarantees that the theme itself and the change to/from it cannot cause unreadable headers, and c) isn't any more complicated than the current setting. If you have specific suggestions on that front, please feel free to share.

starlightsparks commented 2 weeks ago

Forget the accent color, I have removed it from OP due to your given reasons.

And as for the header; a) May you clarify?

b) Could there be a system where it automatically inverts text color on the header if the color is above or below a certain lightness/darkness? (I presume, if this was implemented, it’d be in light mode as well.) I believe this is possible, as I recall an extension for Scratch (not Scratch Wiki, but I’m using this as an example since code is code) does it—But I’m unsure if it’s hard or not. But regardless; Is it not the user’s own fault if they deliberately choose to keep the color an unreadable one? I mean, I feel like most people would connect the dots that “Hey, the text color is different in dark mode, so I could change the header color to a different shade for contrast”, including most children over the age of 8. However, the former (making it so that text color automatically inverts depending on the header color) is still a better solution then to leave it be cause of the latter reason, since it has other benefits, if possible.

c) Yeah, it isn’t unless the thing I proposed in my answer to b) is implemented. So I do still stand with my latter point in b), if my former point in b) is too complicated.

Kenny2github commented 2 days ago

a) By this I mean we will not be adding another field to Special:Preferences - the user must not be required to do anything new, such as having to choose the text color separately. b) I'd be open to a system that does the inversion you describe in compliance with WCAG guidelines. I'm marking this issue "help wanted" if anyone feels like trying their hand at implementing that.