Portal Theme: Remove semantic color variables

[yvonnesjy]

1. Replace current blue- and grey- color variables with primary- and neutral-
2. Remove all semantic color variables I created in the light theme update. Replace them with the primary- and neutral- variables that they reference.

This PR is a part of the plan for new color system. design doc in progress: https://docs.google.com/document/d/1Eb0uixayVeEgO0AcIEjDO6J5555A_CA1BK0nZp1s-uk/edit?usp=sharing We're doing this refactoring first because it will make the legend work a lot simpler.

[robyngit]

@yvonnesjy this works in all of the metacatui themes I tested and looks good! I have some questions:

elements in map-view.css use color variables from the portals (e.g. color: var(--portal-col-neutral-00)). However, maps exist outside of portals: in the main repository's data catalog view, and eventually on dataset landing pages. I'm not sure it makes sense to use portal colors in these contexts. Should we create a new set of color variables for the main repository and use those in map-view.css? Do you have any suggestions about how best can best handle this as we try to improve metacatui's css and color theming in the future? (Same with portal color vars used in FeatureInfoView.js)

^ Silly me, I wrote this before reading your doc, which explicitly states:

CSS rules in map-view.css should not refer to --portal-col. --map-col only.

and

Other pages should refer to portal variables, then main repo variables (future), then default.

I like this plan! ✅ ✅ ✅

So the only remaining question is:

When and how should we remove the __deprecate css vars? Is this part of the plan for new color system?

[yvonnesjy]

Bahahha the doc is really just my scratchpad right now sorry you read through that! The notes are all from before we came up with the primary/neutral color concept, so it needs some updating.

CSS rules in map-view.css should not refer to --portal-col. --map-col only.

This will be no longer true, and

Other pages should refer to portal variables, then main repo variables (future), then default.

This will be true for all pages, including map!

When and how should we remove the __deprecate css vars? Is this part of the plan for new color system?

I think this will depend on the affected portals/main repos that rely on the default. It'd be best if we can first come up with a neutral enough primary/neutral palette. Then replace the __deprecate vars with --default-col-<primary/neutral>-x (if the affected maps are okay with the change).

[robyngit]

Ahh thanks for the explanation! Then I reinstate my initial question: Maps are not supposed to be portal specific, so how do we handle color theming in other contexts? I see the logic in "other pages should refer to portal variables, then main repo variables (future), then default", but as we add new contexts, do we keep adding to this list of fallback colors? Also, how do we re-use the styles from one context in another? e.g. how could we use the light map colors in the main data catalog repo?

[yvonnesjy]

as we add new contexts, do we keep adding to this list of fallback colors?

Besides the portal map page and main repo map page, what other context will we have in the future?

how could we use the light map colors in the main data catalog repo?

map-view.css currently doesn't consider main repo colors yet, but in the future, I imagine a set of --main-col-<primary/neutral>-x so map will use it as a fallback if the portal var doesn't exist (which will be the case on a main repo map). If we want to use the same light colors, we can just apply the same values to the --main-col-... set.

[ianguerin]

If you have a mapping from old -> new please share. My feature PR is going to run into come conflicts with this PR and I'll need to update the colors that I'm referencing

[yvonnesjy]

mapping from old -> new

The changes should be all no-op. You can find the root values of the color variables in your PR, and just replace blue/grey with primary/neutral. Feel free to make the update first since it'll be easier to look up, and I can wait to merge.