Use CSS Variables/Properties instead of magic values

[fregante]

There are 23 instances of #202020 in the file. If GHD used variables, changing/customizing these values would be easier.

I'm trying to make it even darker (#000) but customizing the value forces me to copy huge selectors.

This for example would also allow #910

[the-j0k3r]

This for example would also allow #910

Syntax themes are being totally reworked to a simpler format which reduces duplication. See https://github.com/StylishThemes/GitHub-Dark/issues/910#issuecomment-601035542

The new design will automatically allow all themes here to work currently the design needs each theme to be constructed separately, while redesign you do only one set of color variable for the 3), Even then we are talking 35 colors as it stands now. if you want to add a custom theme, 35 colors is a huge taxation on the config menu. I fail to see how allowing custom gray colors ontop will resolve anything here.

I dont think allowing a multitude of colors to be customizable is a practical solution in addition to the existing options, + considering adding another https://github.com/StylishThemes/GitHub-Dark/issues/1094, you end up with huge menus in usercss config, besides syntax themes are a special feature of GHD that is quite complex with 3 different syntax themes for codemiirror, Github, jupyter, its not as simple as you suggest.

There are 23 instances of #202020 in the file. If GHD used variables, changing/customizing these values would be easier.

GHD is a complex theme, using generators for instance https://github.com/StylishThemes/GitHub-Dark/blob/ea8443d0e06294b5701bac1775e7e9bc97b4b5e6/tools/generate.js#L21-L23 will exactly chnage this https://github.com/StylishThemes/GitHub-Dark/blob/ea8443d0e06294b5701bac1775e7e9bc97b4b5e6/github-dark.css#L644-L884

So taking the syntax themes aside, what new config colors are you exactly proposing?

[fregante]

I never talked about options/UI, but literal CSS Properties, var()

Currently I'm overriding the whole selectors in my extra userstyle for GitHub. If GHD used variables I could just set:

:root {
	--level-0: #000;
	--level-1: #050505;
}

Such solution could also solve #1094 (if you removed the "secondary color" option and instead suggested users to create a separate stylesheet)

[fregante]

I mean, even the Code colors as they are configured now shouldn't be part of the stylesheet anyway, given the complexity they bring. They could just be additional stylesheets.

[the-j0k3r]

Yea we could use root values but separate stylesheets are used already as such we use different moz-doc sections.

The generator doesnt know about these diff moz-doc sections and doesnt generate CSS to these areas only to the main top moz section, and until it does, your design suggestion wont very well work as you have explained it.

I dont even know if the generator supports root values as is.

#1094 will only be solved by adding an extra config option or a separate style to override the current rules.

[fregante]

separate style to override the current rules.

Or, if var() was used everywhere, just a separate style to override the current variables rather than whole rules.

[the-j0k3r]

We cant have separate stylesheets, only @-moz-document sections.

And again IDK if the generator supports var(), for the sake of a darker style you can use this.

/* ==UserStyle==
@name         GitHub Prefer Color Scheme
@namespace    StylishThemes
@version      0.0.2
@description  Supports 
@author       StylishThemes
@homepageURL  https://github.com/StylishThemes/Feature-Override-Styles/
@supportURL   https://github.com/StylishThemes/Feature-Override-Styles/issues/new/choose
@updateURL    https://raw.githubusercontent.com/StylishThemes/Feature-Override-Styles/master/dark-mode-for-github.user.css
@license      CC-BY-SA-4.0

@var select media-query "Require system appearance" [
	"None",
	"Dark",
	"Light"
]
@var color darkC  "Dark background color"  #111
@var color lightC "Light background color" #eee
@preprocessor stylus
==/UserStyle== */
@-moz-document regexp("^https?://((education|gist|guides|help|lab|raw|resources|status|developer|support)\\.)?github\\.com/((?!generated_pages/preview).)*$"), domain("githubusercontent.com"), domain("graphql-explorer.githubapp.com"), domain("www.githubstatus.com") {
	if media-query == "None" {
		@media (prefers-color-scheme: no-preference) {
			html body, html .bg-white,
			html body .selected.reponav-item {
				background-color: inherit !important;
			}
		}
	}
	else if media-query == "Dark" {
		@media (prefers-color-scheme: dark) {
			html body, html .bg-white,
			html body .selected.reponav-item {
				background-color: darkC !important
			}
		}
	}
	else if media-query == "Light" {
		@media (prefers-color-scheme: dark) {
			html body, html .bg-white,
			body.selected.reponav-item {
					background-color: lightC !important
			}
		}
	}
}

Thats some thing I wrote and testing for resolving https://github.com/StylishThemes/GitHub-Dark/issues/960

But at this time its not fully ready it seem to be slightly buggy, though it will darken this style to whatever colors you set.

Also a smaller style can be done to overwrite what you want, I dont have anyhing ready and cant promise Ill make one, but you get the idea, its faster than waiting for a change you want is probably more work than its worth imo at this time.

[fregante]

What you wrote is a separate style. I already wrote one with 3 of the biggest selectors I copied from GHD, no additional options.

[the-j0k3r]

A separate style is faster at this time, the amount of work to do what you want and implement something I'm personally NOT prepared to undertake at this time.

Also It needs to work with generator, this is integral, I reiterate my latest thoughts.

As for your approach is not ideal, you cant just copy huge rules out because these are automatically generated, you need to keep up with changes, this style is not intended to be overwritten like you currently have.

The prefers color scheme just needs a few more selectors and will need to work together with this style to do what you want even though its not designed to do that. It immediately works and no copying or doing a ton of work manually tedious work and doesnt break the generator.

@silverwind should weigh in, hes the generator author.

[fregante]

As for your approach is not ideal,

That’s the whole point of this issue. Use var() (when possible) and my stylesheet drops to 5 lines

[the-j0k3r]

That’s the whole point of this issue. Use var() (when possible) and my stylesheet drops to 5 lines

PR's welcome

[silverwind]

var() would be nice, but we first need a solid naming scheme for the variables which is rather hard when you have like 30 shades of grey to name. Any advice/best practices for this? I guess we can reduce the number of shades a bit, but I estimate will still need around 15-20 total.

[fregante]

Naming 20 shades of gray would probably be a fool’s errand, that's why I was suggesting --level-N, starting at 100 for the darkest and going up by 10 for each. This also leaves space for anything in between.

This is approximately how most design system do it: https://primer.style/css/support/color-system

I guess we can reduce the number of shades a bit

This would also be good.

[the-j0k3r]

Using this http://www.css-color-extractor.com/ we can see pretty much all the colors we use, for first moz-doc section pasted in.

[fregante]

Excellent! I was looking for that tool exactly but couldn't find it.

Yeah there are a lot of nearly-identical colors that could be merged. I'm sure those with transparencies are also duplicate but to deduplicate them you'd have to use RGB colors everywhere (and maybe it's not necessary)

Also not all of them would have to be variables, maybe just the most common ones: either because they appear multiple times in the CSS (which would be useful to you) or because they appear often on the site (which would be useful for alternative styling, maybe in a second pass)

[the-j0k3r]

Also not all of them would have to be variables,

Well if this is indeed going forward leaving a mix and match is not my idea of a job done.

[Dorson]

No need to change the grey colors, they are grey in dark or light themes too :-)

mid-intensity rgbA colors with transparency are universal too.

Apart from that go for the CSS color variables !

The CSS rule for @media screen and (prefers-color-scheme: dark) { } would work, but it would enforce one color only, and for the users that have that rule ON already. No way to switch it ON, OFF during sunny moments. Or give it to all as a click-able option.

To resolve that, I did the hard work.

Made and tested the code for a CSS color switch with memory. Great for the night and evening time.

See live demo on GitHub page:

https://dorson.github.io/CSS-Dark-Mode-and-color-switch/

Have fun, feel free to fork, copy, adopt, port, etc...

[silverwind]

Regarding syntax rework, I think we should include a "base" dark syntax theme in the style and other syntaxes would be separate "addon" usercss files. That way we can get rid of the theme blocks in the variables and probably use default preprocessor that provides css variables.

[Gitoffthelawn]

@fregante Fredrico, is your goal in making it darker to decrease overall brightness, increase contrast, or something else?

[the-j0k3r]

This request is now pretty much handled itself now GitHub provides CSS vars.

Pretty much 80% of all generated rules arent needed anymore since all it takes is reassign colors to the GH existing CSS vars. IMO A generator is now overkilling the style with all the redundant stuff for GH domains.

Still some manual overrides are needed and some color properties still not Using CSS vars upstream but its less and less everyday.

[silverwind]

GitHub is already at something like 500+ css vars. I'd say they are overkilling it with making too specific vars and not sharing enough of them. I have written CSS-var based UIs in the past and can usually do with around 100 vars if I name them after the color, not where it's being used.

It'll still a continous maintenance requirement when they add new vars for every tiny thing in the UI.