Separate :root, light-theme and dark-theme styles.

[isoos]

• The change only separates the variables into :root and .light-theme.
• Note: I'm not entirely sure that this is better, but wanted to propose it as an alternative.
• Previously, we had most of the variables under :root, and override them under .dark-theme. I think it may be worth considering the separation of :root to have only shared variables that are not redefined in later scopes, and the two theme have variables that are in both scopes.
• The benefit of this proposed structure is that we can reasonably test that if a variable is in one scope, it should be in the other scope too, while the shared variables must not be redefined in any other scope. The drawback seems to be more arbitrary test and rules to follow.

[isoos]

/cc @parlough too, not sure why I couldn't add you as a reviewer

[jonasfj]

So what if we ever need variables that are specific to dark or light mode?

(I don't mind tests enforcing this structure, but they should provide a good message when the fail, so that you don't have to figure out what the test does first).

[parlough]

I see value in trying this out, as the thought of forgetting to define a corresponding dark mode color did cross my mind.

The one downside is that there is no fallback if the class is somehow missing, so tests should likely also make sure each page is rendered with one of the classes added.

[isoos]

So what if we ever need variables that are specific to dark or light mode?

Not sure how that would work, maybe those should be in shared?

The one downside is that there is no fallback if the class is somehow missing, so tests should likely also make sure each page is rendered with one of the classes added.

Yes, this is a good point. I will add this test to this PR and add further tests for the variable splits as a separate PR.

[isoos]

An alternative idea: we could keep the :root rule, but still separate the variables into two groups: one that is checked that they should have a matching dark-theme variant, and the other that is checked that they don't have further overrides. It could provide the value of having tests and separation, but still doing a good fallback in case we miss something.