From: Eric Wong <email@example.com> To: Dmitry Alexandrov <firstname.lastname@example.org> Cc: Mateusz Loskot <email@example.com>, firstname.lastname@example.org Subject: Re: Default theme Date: Sat, 23 Feb 2019 02:50:23 +0000 Message-ID: <20190223025023.bma7yitttmgqhdkr@dcvr> (raw) In-Reply-To: <email@example.com> Dmitry Alexandrov <firstname.lastname@example.org> wrote: > Mateusz Loskot <email@example.com> wrote: > > On Fri, 22 Feb 2019 at 09:50, Eric Wong <firstname.lastname@example.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.
next prev parent 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] usercontent.pm: 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 publically 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: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: http://public-inbox.org/README * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190223025023.bma7yitttmgqhdkr@dcvr \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * 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 http://public-inbox.org/meta git clone --mirror http://czquwvybam4bgbro.onion/meta git clone --mirror http://hjrcffqmbrq6wope.onion/meta git clone --mirror http://ou63pmih66umazou.onion/meta Newsgroups are available over NNTP: nntp://news.public-inbox.org/inbox.comp.mail.public-inbox.meta nntp://ou63pmih66umazou.onion/inbox.comp.mail.public-inbox.meta nntp://czquwvybam4bgbro.onion/inbox.comp.mail.public-inbox.meta nntp://hjrcffqmbrq6wope.onion/inbox.comp.mail.public-inbox.meta nntp://news.gmane.org/gmane.mail.public-inbox.general note: .onion URLs require Tor: https://www.torproject.org/ AGPL code for this site: git clone https://public-inbox.org/ public-inbox