Re: Default theme

[Eric Wong <e@80x24.org>]

Dmitry Alexandrov <321942@gmail.com> wrote:
> Mateusz Loskot <mateusz@loskot.net> wrote:
> > On Fri, 22 Feb 2019 at 09:50, Eric Wong <e@80x24.org> wrote:
> >> The way I see it is:  whatever color scheme I choose will
> >> make some people unhappy.  That's why I make sure it's
> >> customizable via user CSS and the CSS class names remain
> >> stable.
> >
> > I agree. Then, why not keep the no theme.
> 
> I guess, that was a matter of implementing semantic colour
> highlighting of diffs and code.  Alas, CSS is not Emacs themes
> and it doesn’t support calculating colours relatively, so you
> have to either (user-friendly way) make some reasonable
> assumptions about basic colours or (foolproof way) enforce
> them.

Right.  We've always supported quote highlighting (but maybe
nobody noticed), and recently, it got the ability to do diff
and code highlighting (which is a lot more colors).

IMHO, the diff and code highlighting are too useful features to
live in obscurity.  I've configured my MUA for diff and quote
highlighting for many years, now.

AFAIK there's no way of using relative colors from CSS like
from a terminal or I would've chosen to go that route.


And I've ALWAYS gotten a lot of flak from the way public-inbox
looks and don't expect that to change regardless of what I do.
There's really no way of satisfying everyone.

So I decided it was OK to use a dark theme by default on
public-inbox.org because Linux, FreeBSD, OpenBSD (and probably
all *nix-like OSes) default to a dark background at the boot
console.  I don't think it's an unreasonable aesthetic given the
target audience of public-inbox.

Power consumption is my other concern.  OLEDs are becoming more
common.  Like old CRT displays, OLEDs use less power for dark
areas.  On CCFL/LED displays, it's not a big difference either
way; but dark screens work better with less ambient lighting, so
power savings can be achieved through reduction of ambient
lighting.

> On the other hand, items of personal taste, such as
> undecorated links, I believe, got into the published
> stylesheet simply by mistake.

Not a mistake.  Underlining is redundant when colors are
available and makes some characters hard-to-distinguish.
Neither w3m and lynx underline links from a color terminal;
either.

> >> "prefers-color-scheme" media queries may be used to set
> >> to respect user preferences in future browsers.
> 
> FWIW, Mozilla implemented it a week ago.

Yes, I just noticed the nightlies support it and will be testing
it and making adjustments as necessary to public-inbox.org and
.onion mirrors I run.

> Also, there has always been a standard, yet pretty weird, and
> hence not widely used, way to choose a stylesheet for a given
> page among several alternatives: <link rel="stylesheet"
> title="…" …> + ‘Default-Style’ HTTP header.

Sadly, the title="" support is next-to-worthless because it does
not persist across different pages.  Fortunately,
prefers-color-scheme seems to be coming around so there's no
need to resort to cookies, either.