From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-4.0 required=3.0 tests=ALL_TRUSTED,BAYES_00 shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 778C320248; Sat, 23 Feb 2019 02:50:23 +0000 (UTC) Date: Sat, 23 Feb 2019 02:50:23 +0000 From: Eric Wong To: Dmitry Alexandrov <321942@gmail.com> Cc: Mateusz Loskot , meta@public-inbox.org Subject: Re: Default theme Message-ID: <20190223025023.bma7yitttmgqhdkr@dcvr> References: <20190222085014.mwvkf2mwrb6yeyrh@dcvr> <87a7in47yv.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87a7in47yv.fsf@gmail.com> List-Id: Dmitry Alexandrov <321942@gmail.com> 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 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: 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.