So about the themeing aspect of this PR, I see

ui/common/css/abstract/_theme.scss

@mixin metal-bg {
  @include to-bottom(hsl($site-hue, 7%, 22), hsl($site-hue, 5%, 19));

  html.transp & {
    @include to-bottom(hsla(0, 0, 0, 0.4), hsla(0, 0, 0, 0.5));
  }

  html.light & {
    @include to-bottom(hsl(0, 0, 96) 0%, hsl(0, 0, 93));
  }
}

@mixin metal {
  @include to-bottom(hsl($site-hue, 7%, 22), hsl($site-hue, 5%, 19));

  html.transp & {
    @include to-bottom(hsla(0, 0, 0, 0.4), hsla(0, 0, 0, 0.5));
  }

  html.light & {
    text-shadow: 0 1px 0 $c-font-shadow;
    @include to-bottom(hsl(0, 0, 96) 0%, hsl(0, 0, 93));
  }
}

resulting in compiled CSS:

.btn-rack__btn,.btn-rack form,#friend_box .friend_box_title,.button.button-metal,.button.button-empty:not(.disabled):hover,.button.button-empty.button-green:not(.disabled):hover,.button.button-empty.button-red:not(.disabled):hover {
    background: linear-gradient(to bottom, hsl(37, 7%, 22%), hsl(37, 5%, 19%) 100%)
}

html.transp .btn-rack__btn,html.transp .btn-rack form,.btn-rack html.transp form,html.transp #friend_box .friend_box_title,#friend_box html.transp .friend_box_title,html.transp .button.button-metal,html.transp .button.button-empty:not(.disabled):hover {
    background: linear-gradient(to bottom, hsla(0, 0%, 0%, 0.4), hsla(0, 0%, 0%, 0.5) 100%)
}

html.light .btn-rack__btn,html.light .btn-rack form,.btn-rack html.light form,html.light #friend_box .friend_box_title,#friend_box html.light .friend_box_title,html.light .button.button-metal,html.light .button.button-empty:not(.disabled):hover {
    text-shadow: 0 1px 0 var(--c-font-shadow);
    background: linear-gradient(to bottom, hsl(0, 0%, 96%) 0%, hsl(0, 0%, 93%) 100%)
}

on most pages I count more than a hundred of unused html.light or html.transp selectors. Does that mean we're adding even more for each theme that we would add?

Yes, there's a lot of unused selectors generated by those mixins/extends. We may be able to get rid of a lot of that, but I don't think it would buy us anything.

Matching selectors is a tiny slice of the time spent rendering compared to interpreting the rules and doing layout.

Make sure you compare render performance on the same host, I don't think you can look at lighthouse results from prod and compare them to lichess.dev. You'd need to checkout a commit prior to the theming on lichess.dev and run lighthouse there to get a good comparison of scores pre and post theme

So it does mean that all themes will be loaded for everyone, and that adding a new theme adds weight and selectors to every page. That won't encourage me to add a plethora of new themes.

Most new themes would just be different color definitions and make theme-all.css a bit bigger. If we needed different css, such as gradients, we'd need to make a separate rule in css.

But that's optional. I think for 99% of any themes we would add, we can just let the default gradient happen or slap the light/transp classes on as well and use those.

And yes, the idea is to keep all themes loaded for everyone. At least while the compressed size of all the css is comparable to what we had before (filtered by .ltr.dark.)

Not about themes:
our readme currently says that Safari 11.1 is supported. And indeed lichess.org works on Safari 11.1, I just checked on browserstach.
But lichess.dev doesn't. At all.

Safari 12.1 doesn't work either. And neither does 13.1.
The first version that works is 14.1. That's a big jump. We'd be looking at thousands of players thrown out.
Is there a way to avoid that?

Opera 55 is broken too. First version that works is Opera 72.
Also Firefox 67 -> 79.
Edge 91 still works.

Oh yeah, we can probably fix all of that.

That oughtta do it