Mu/colors

[murvoy]

Hey guys, here's a new PR with a reduced number of changes:

• colors for light theme (still miss dark mode)
• a few tweaks for keycaps within text
• keyboard menu adjustments

I chose to let the color palette variables explicitly in the CSS files because I tend to prefer having this color abstraction.
In case we want to change the palette later on for instance.

Wdyt?

[murvoy]

Hey!

Finally took the time to handle the dark scheme.
I will now wait for you to review this PR prior to changing anything else (such as home page, etc).

[murvoy]

We can totally remove these font variables. Sorry for the noise.

[murvoy]

This section is for styling the geometry/characters selectors (I wanted to try something very light, w/o colors, with a nice CSS animation to highlight the selected one).

[murvoy]

This change is here to also load the css/icons.css stylesheet. Feel free to integrate it otherwise obviously.

[murvoy]

This change was aiming at moving the menu/links above the keyboard (instead of below the keyboard). Idem, feel free to reject that obviously.

[fabi1cazenave]

Hey, nice to see some movement on these stylesheets. :-)

I really like the light color palette, especially for the keyboard layouts ! Maybe we should use an external stylesheet for these SVGs, by the way.

As mentioned in your previous PR, I really struggle with unnamed variables such as --color-palette-{a,b,c,d,e}{,-dark,-light}. To me it’s a major regression, but I’ll let @Nuclear-Squid be the judge if that.

Accessibility-wise I think the palette lacks contrast on the various menus, and has too much contrast on keys. Let’s get through that.

Main menu: before/after

The new menu looks nice but I lack the visual indication for the sub-menu. The current pseudo-tab probably looks (very) outdated, but I thik it makes it clear that Presentation and Installation are sub-menus of the main Ergo‑L page. And I think we need such an indication — or maybe rethink the whole menu, but that would be for another PR.

Slightly related, I kinda miss some “accent” information for the table of contents.

Keyboard layouts: before/after

I’m certainly biased but ! prefer the older geometry selectors: thinner, slicker, impossible to miss.

I think the navigation menu should stay below the SVG. And though I agree using glyphes as icons is debatable, the main point is that it scales nicely with the button text: same height, same baseline.

Maybe a few SVG icons used as backgrounds could look nicer and still scale nicely along with the button texts? But again, that could be for another PR.

Keys: before/after{light}/after(dark}

These <kbd> look great and I think it’s a valuable addition for this website, but the contrast seems much too high. I’d be tempted to swap the dark and .light modes for these styles, WDYT ?

IIRC, in the current stylesheet these <kbd> elements reuse the same colors as the special keys in the keyboard layout SVGs, and I think tn makes sense.

[fabi1cazenave]

Long story short, maybe we should aim lower and focus on:

• the color palette, by fine-tuning the existing variables and possibly use a common external stylesheet for all SVG keyboard layouts
• the <kbd> look’n’feel, to make it more consistent with the SVG keyboard layouts.

If this helps us focusing on the color palette, menu icons and font settings could be another PR. But as usual, this is just a suggestion. :-)

[murvoy]

Hey! Thanks for reviewing that!

Color palette variable naming

I have no special attachment to these variables, it just helps prototyping the colors for now.
We can obviously remove them once we agree on the shades, especially if there is a way to use an external stylesheet in the svg (which I never thought about - and which would be, in my opinion, much better).

Main menu and sub menus

Totally agree on your remark about not showing clearly enough that the submenus are indeed related to the main menu above. I just chose not to deal with that for the moment, I just needed a white background to setup the color of the other elements (and get rid of the greyish tabs).

Geometry and characters menus (below the keyboard)

I found the original buttons too similar to the keyboard keys and I tried to propose something that clearly differs from the keyboard itself. But that was just an experiment.

Navigation menu (installer, tester, stats ...)

I now understand better why this menu was below. Originally, it was not clear to me that this nav was related to the keyboard widget. So maybe we need to think about a way to let the entire widget to appear as a whole, hence visually attaching the nav menu into the widget.

As for the glyphs, I just know I don't like the look and feel of unicode glyphs, not sure how we should do it anyway, and this could be another PR obviously.

kbd styling

Totally agree for less contrast (either reversing style or using different shades of grey - maybe a version common to light and dark would suffice?