user/dev discussion of public-inbox itself
 help / color / Atom feed
From: Eric Wong <>
To: Dmitry Alexandrov <>
Cc: Mateusz Loskot <>,
Subject: Re: Default theme
Date: Sat, 23 Feb 2019 02:50:23 +0000
Message-ID: <20190223025023.bma7yitttmgqhdkr@dcvr> (raw)
In-Reply-To: <>

Dmitry Alexandrov <> wrote:
> Mateusz Loskot <> wrote:
> > On Fri, 22 Feb 2019 at 09:50, Eric Wong <> 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 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

> 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;

> >> "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 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.

  reply index

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-21 13:36 Mateusz Loskot
2019-02-22  8:50 ` Eric Wong
2019-02-22 20:39   ` Dmitry Alexandrov
2019-02-23  2:47     ` Eric Wong
2019-02-23 10:56       ` [PATCH 0/2] ensure user CSS always overrides BOFH CSS Eric Wong
2019-02-23 10:56         ` [PATCH 1/2] set "!important" to override BOFH prefs Eric Wong
2019-02-23 10:56         ` [PATCH 2/2] www: prevent '!important' in BOFH-specified CSS Eric Wong
2019-02-23 19:55       ` Default theme Mateusz Loskot
2019-02-22 20:53   ` Mateusz Loskot
2019-02-23  1:19     ` Dmitry Alexandrov
2019-02-23  2:50       ` Eric Wong [this message]
2019-02-23 10:49         ` Eric Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190223025023.bma7yitttmgqhdkr@dcvr \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

user/dev discussion of public-inbox itself

Archives are clonable:
	git clone --mirror
	git clone --mirror http://czquwvybam4bgbro.onion/meta
	git clone --mirror http://hjrcffqmbrq6wope.onion/meta
	git clone --mirror http://ou63pmih66umazou.onion/meta

Example config snippet for mirrors

Newsgroups are available over NNTP:

 note: .onion URLs require Tor:

AGPL code for this site: git clone