doc: update agreed global style tags

[JakobVogelsang]

I am of the opinion that we need more that two accent colors for plugin authors. For me this started with having multiple accent colors in the code editor within the OpenSCD core component.

[ca-d]

When @JakobVogelsang originally suggested this idea I was immediately on board.

Now that I reflect on what this will do for plugin authors, two potential worries cross my mind (ranked by importance):

1. The plugin author has no way of finding out whether the primary, secondary, or error colors are identical or close to any of the accent colors.
   Do we see any potential problems with plugin authors unintentionally using a primary or error color in their UI?
   If so, the only real solution for distributors would be to choose primary, secondary, and error colors that are far away from all accent colors. Since there's limited space on the hue wheel, this will make designing a useful color scheme a lot harder. Also, OpenSCD's current color scheme would set quite a bad example, with all three distinguished colors coming from among the accent colors.
2. This will make it much more convenient for plugin authors to create a complete visual mess by thrusting upon them many more colors than are useful in most user interfaces.

The original idea behind OpenSCD's theming facility was that the design principles underlying the Solarized color palette are a very good way to get a human-friendly result by mathematical means. This enables companies who don't specialize in human-centered design to slap their own branding on the app without messing up the ergonomics: They choose one or two central colors and two tints for the two ends of the base colors and otherwise follow the Ethan Schoonover's method for constructing the entire rest of the color scheme to the letter. The distances in lightness and values and perceived color contrasts stay the same, the ergonomics are saved.

Maybe this original goal was too lofty anyway, as calculating CIELAB lightness ratios of different sRGB values is too big an ask for a company that just wants to enable engineers to configure devices and be able to tell at a glance exactly which company's devices they are configuring.

Do we care deeply about any of this? I'm honestly not sure.

On the other hand, the three "accent" colors primary, secondary and error are already well-established and maybe if a plugin needs more colors than those, it could just use hard-coded colors? In the Single Line Diagram Designer Plugin, e.g., we use OMICRON company colors, black, and white for some buttons and inside the diagram itself to delimit voltage levels and bays, while using theme colors for everything else (context menus, some other buttons, the plugin background). That's something that I feel worked out rather nicely, my current intention would be to keep it that way.

What do you guys think about all of this? Are you as torn as I am?

[ca-d]

Suggested change

	--oscd-accent-yellow: var(--oscd-theme-accent-yellow, #b58900);
	--oscd-accent-orange: var(--oscd-theme-accent-orange, #cb4b16);
	--oscd-accent-red: var(--oscd-theme-accent-red, #dc322f);
	--oscd-accent-magenta: var(--oscd-theme-accent-magenta, #d33682);
	--oscd-accent-violet: var(--oscd-theme-accent-violet, #6c71c4);
	--oscd-accent-blue: var(--oscd-theme-accent-blue, #268bd2);
	--oscd-accent-cyan: var(--oscd-theme-accent-cyan, #2aa198);
	--oscd-accent-green: var(--oscd-theme-accent-green, #859900);
	--oscd-yellow: var(--oscd-theme-yellow, #b58900);
	--oscd-orange: var(--oscd-theme-orange, #cb4b16);
	--oscd-red: var(--oscd-theme-red, #dc322f);
	--oscd-magenta: var(--oscd-theme-magenta, #d33682);
	--oscd-violet: var(--oscd-theme-violet, #6c71c4);
	--oscd-blue: var(--oscd-theme-blue, #268bd2);
	--oscd-cyan: var(--oscd-theme-cyan, #2aa198);
	--oscd-green: var(--oscd-theme-green, #859900);

I'd personally prefer these shorter variable names. What do you think about them?

Explanation:

With the hitherto provided variable names (primary, secondary, error, base2, text-font, etc.) my goal was to make them as short and snappy as possible for the benefit of plugin authors.

Had we created a full CSS design system instead of just theming tokens for a single app, we should have come up with some modular naming scheme like oscd-color-primary-100 oscd-color-base2-100 oscd-font-text-body-regular or something like that. I thought that level of verbosity wasn't needed here.

[ca-d]

In today's refinement we decided to drop this and stick with the three extant accent colors.