Re: solarized

[Protesilaos Stavrou <info@protesilaos.com>]

Richard Stallman <rms@gnu.org> [2020-09-16, 01:05 -0400]:

>   > I agree.  It is practically impossible to design for accessibility using
>   > colours that are equally accessible on light and dark backgrounds, while
>   > also remaining fairly distinct between themselves.  The background has
>   > to be a given, so that all foreground values can be selected
>   > accordingly.
>
> I think you are right.  But this suggests an idea to me.  Would it
> make sense to design a color palette, in the same systematic way as
> Solarized, but with only dark backgrounds, and the other colors meant
> to contrast with those?
>
> And then invert it for light backgrounds?

So you mean to develop two distinct sets of colours?  One set consists
of dark backgrounds and appropriate variants of red, green, blue,
etc. that are meant to work well with those backgrounds.  Then another
set for the light version, again with bespoke variants of red, green,
blue, etc.

I think that is desirable if you plan to develop for a minimum WCAG
accessibility target of 4.5:1 colour contrast (as noted in my previous
message) without facing any artificial constraint.

If someone comes up with an implementation of such a new theme framework
that is sufficiently different from the current themes, I am prepared to
send feedback with regard to the choice of colour values.

* * *

On another note, do we really need to strictly conform with the
16-colour palette?  I understand this is the standard for terminal
emulators (maybe not all of them), but Emacs has more options than that.
Perhaps define an "extended palette" for GUIs and let the 16-colour
"base palette" for TTYs.

In my experience, 16 colours is too limited of a set to design bespoke,
usable, and pleasing interfaces that match the wide array of needs an
Emacs user has.  For example, you need a set of slightly accented
backgrounds that are not the same as the standard accented foregrounds
(red/green/blue/etc), such as to display diff buffers.  Inverting the
main background with the standard accented foreground "just works"
though it leads to too intense, too crude of a result, i.e. it is
sub-optimal due to an unnecessary compromise.  Then you need another
shade of such accented backgrounds to also paint refined (word-wise)
changes in diffs.  For Magit, if you use that, you may need a third
variant for the focused diff hunk…

Extend this to isearch's current and lazy matches, occur's matches which
should not be the same as isearch's to avoid conflicts (because you can
search in an occur buffer), the regexp groups of re-builder, the
numerous components of completion frameworks like Ivy/Helm, and so on.

To me colours are akin to a tool kit: use the right set for the job.
Keep the 16 colour "base palette" for terminal emulators and let GUI
have as many as would be deemed necessary in the "extended palette".

Even the Solarized theme for Emacs defines far more colours[0] than the
original 16 in Ethan Schoonover's work.[1] It thus is not a faithful
implementation of Solarized, strictly speaking (though I obviously am
okay with that).

[0]: https://github.com/bbatsov/solarized-emacs/blob/master/solarized-palettes.el
[1]: https://ethanschoonover.com/solarized/

-- 
Protesilaos Stavrou
protesilaos.com