Default theme

Default theme

[Mateusz Loskot]

Hi,

I've noticed the theme has changed, from light to dark,
while browsing public-inbox.org archives.
Is that permanent change?
Is there any way to switch back to light theme as default?

I mean, other than the colors customization via CSS.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net

Re: Default theme

[Eric Wong]

Mateusz Loskot <mateusz@loskot.net> wrote:
> Hi,
> 
> I've noticed the theme has changed, from light to dark,
> while browsing public-inbox.org archives.

There was no theme before, just browser defaults.  I mainly use
w3m with a dark terminal, so it was always dark to me.

> Is that permanent change?

I don't know, yet.  I've considered making it random, but that's
probably too disruptive and confusing.

I wouldn't say public-inbox.org itself is permanent, though,
either :>

> Is there any way to switch back to light theme as default?
>
> I mean, other than the colors customization via CSS.

"prefers-color-scheme" media queries may be used to set
to respect user preferences in future browsers.

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.

Note: public-inbox installations do not have a default color
scheme right now.  So it's up to the admin to configure it.

Re: Default theme

[Dmitry Alexandrov]

[-- Attachment #1: Type: text/plain, Size: 1123 bytes --]

Eric Wong <e@80x24.org> wrote:
> Mateusz Loskot <mateusz@loskot.net> wrote:
>> I've noticed the theme has changed, from light to dark,
>> while browsing public-inbox.org archives.
>
> There was no theme before, just browser defaults.

Pardon my unasked advice, but IMHO, that was a very wise choice.

> The way I see it is:  whatever color scheme I choose will make
> some people unhappy.

Why to choose any then?

> That's why I make sure it's customizable
> via user CSS and the CSS class names remain stable.

Via overriding *author* CSS, you mean.  A user stylesheet is supposed to serve as a defaults with a lower preference.

Indeed, designers of the today’s Web completely reject an idea that you know better, which typefaces, sizes, colours, line height and width, etc make it easier for you to read text on your display, as something ridiculous; so if you to disagree with them, you have to write and test numerous overrides for every single website, instead of specifying it once and for all.

And I was quite disappointed to discover that even owners of public-inbox.org now joined them.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Default theme

[Mateusz Loskot]

On Fri, 22 Feb 2019 at 09:50, Eric Wong <e@80x24.org> wrote:
> Mateusz Loskot <mateusz@loskot.net> wrote:
> > Hi,
> >
> > I've noticed the theme has changed, from light to dark,
> > while browsing public-inbox.org archives.
>
> There was no theme before, just browser defaults.  I mainly use
> w3m with a dark terminal, so it was always dark to me.

I see. I prefered the no theme.

> > Is that permanent change?
>
> I don't know, yet.  I've considered making it random, but that's
> probably too disruptive and confusing.

If there is a default theme at all, a minimal yet convenient
would be to offer dark or light switch.

> > Is there any way to switch back to light theme as default?
> >
> > I mean, other than the colors customization via CSS.
>
> "prefers-color-scheme" media queries may be used to set
> to respect user preferences in future browsers.
>
> 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.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net

Re: Default theme

[Dmitry Alexandrov]

[-- Attachment #1: Type: text/plain, Size: 1185 bytes --]

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.  On the other hand, items of personal taste, such as undecorated links, I believe, got into the published stylesheet simply by mistake.

>> "prefers-color-scheme" media queries may be used to set
>> to respect user preferences in future browsers.

FWIW, Mozilla implemented it a week ago.

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Default theme

[Eric Wong]

Dmitry Alexandrov <321942@gmail.com> wrote:
> Eric Wong <e@80x24.org> wrote:
> > That's why I make sure it's customizable
> > via user CSS and the CSS class names remain stable.
> 
> Via overriding *author* CSS, you mean.  A user stylesheet is
> supposed to serve as a defaults with a lower preference.

Oops, I think "!important" in userContent.css will fix that.
The documentation and sample CSS will be updated with "!important"

> Indeed, designers of the today’s Web completely reject an idea
> that you know better, which typefaces, sizes, colours, line
> height and width, etc make it easier for you to read text on
> your display, as something ridiculous; so if you to disagree
> with them, you have to write and test numerous overrides for
> every single website, instead of specifying it once and for
> all.

I sympathize with that, since bright things hurt my eyes.
Unlike the rest of the web, public-inbox is intended to be
fully forkable/mirror-able and will always be.

> And I was quite disappointed to discover that even owners of
> public-inbox.org now joined them.

Choosing any theme at all for public-inbox.org was not an easy
decision.  But I think it was necessary given the new features
(another response coming to your other message) and the overall
goal of fighting against centralized communications platforms
and services.

UI preferences/colors is not as important as fighting against
centralization.  So if my color preference puts people off and
encourages light/un-themed mirrors to spawn, then it's a win :)

Re: Default theme

[Eric Wong]

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.

Re: Default theme

[Eric Wong]

Eric Wong <e@80x24.org> wrote:
> Dmitry Alexandrov <321942@gmail.com> wrote:
> > Eric Wong <e@80x24.org> wrote:
> > >> "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.

OK, adjusted public-inbox.org config and all the .onion mirrors.
No code changes were necessary.

The "ui.systemUsesDarkTheme" integer pref in FF 67+
"about:config" can be used to set/override the dark theme detection:

	0: light
	1: dark
	2: unspecified, dark with the following config

The relevant part of ~/.public-inbox/config looks like this, now:

	[publicinbox]
		css = /path/to/public-inbox/contrib/css/216dark.css \
			media=screen
		css = /path/to/public-inbox/contrib/css/216light.css \
			media=print

		; added this line for FF 67+ users:
		css = /path/to/public-inbox/contrib/css/216light.css \
			media='screen AND (prefers-color-scheme:light)'

("!important" sample patches on the way)

[PATCH 0/2] ensure user CSS always overrides BOFH CSS

[Eric Wong]

First, ensure our sample CSS includes "!important" to override
what the BOFH set.

Then, make sure BOFHs can't set "!important" to override
what users set in their private CSS files.

Thanks to Dmitry Alexandrov <321942@gmail.com> for noticing
this.

Eric Wong (2):
  usercontent.pm: set "!important" to override BOFH prefs
  www: prevent '!important' in BOFH-specified CSS

 lib/PublicInbox/UserContent.pm | 41 +++++++++++++++++++++-------------
 lib/PublicInbox/WWW.pm         | 12 ++++++++--
 2 files changed, 35 insertions(+), 18 deletions(-)

-- 
EW

[PATCH 1/2] usercontent.pm: set "!important" to override BOFH prefs

[Eric Wong]

The sample userContent.css needs a higher priority than what
the BOFH specifies.  In other words, user preference must
ALWAYS take precedence.

Reported-by: Dmitry Alexandrov <321942@gmail.com>
cf. https://public-inbox.org/meta/87mumn4kx8.fsf@gmail.com/
---
 lib/PublicInbox/UserContent.pm | 41 +++++++++++++++++++++-------------
 1 file changed, 25 insertions(+), 16 deletions(-)

diff --git a/lib/PublicInbox/UserContent.pm b/lib/PublicInbox/UserContent.pm
index 468e6cf..5e57602 100644
--- a/lib/PublicInbox/UserContent.pm
+++ b/lib/PublicInbox/UserContent.pm
@@ -16,31 +16,31 @@ sub CSS () {
 	 * It reduces eyestrain for me, and energy usage for all:
 	 * https://en.wikipedia.org/wiki/Light-on-dark_color_scheme
 	 */
-	* { background:#000; color:#ccc }
+	* { background:#000 !important; color:#ccc !important }
 
 	/*
 	 * Underlined links add visual noise which make them hard-to-read.
 	 * Use colors to make them stand out, instead.
 	 */
-	a { color:#69f; text-decoration:none }
-	a:visited { color:#96f }
+	a { color:#69f !important; text-decoration:none !important }
+	a:visited { color:#96f !important }
 
-	/* quoted text gets a different color */
-	*.q { color:#09f }
+	/* quoted text in emails gets a different color */
+	*.q { color:#09f !important }
 
 	/*
-	 * these may be used with cgit, too
+	 * these may be used with cgit <https://git.zx2c4.com/cgit/>, too.
 	 * (cgit uses <div>, public-inbox uses <span>)
 	 */
-	*.add { color:#0ff }
-	*.del { color:#f0f }
-	*.head { color:#fff }
-	*.hunk { color:#c93 }
+	*.add { color:#0ff } /* diff post-image lines */
+	*.del { color:#f0f } /* diff pre-image lines */
+	*.head { color:#fff } /* diff header (metainformation) */
+	*.hunk { color:#c93 } /* diff hunk-header */
 
 	/*
 	 * highlight 3.x colors (tested 3.18) for displaying blobs.
-	 * This doesn't use most of the colors available (I find too many
-	 * colors overwhelming), so the #ccc default is commented out.
+	 * This doesn't use most of the colors available, as I find too
+	 * many colors overwhelming, so the default is commented out.
 	 */
 	.hl.num { color:#f30 } /* number */
 	.hl.esc { color:#f0f } /* escape character */
@@ -51,13 +51,15 @@ sub CSS () {
 	.hl.com { color:#09f } /* multi-line comment */
 	/* .hl.opt { color:#ccc } */ /* operator */
 	/* .hl.ipl { color:#ccc } */ /* interpolation */
-	/* .hl.lin { color:#ccc } */ /* line-number (unused by public-inbox) */
 
 	/* keyword groups kw[a-z] */
-	.hl.kwa { color:#ff0 }
-	.hl.kwb { color:#0f0 }
-	.hl.kwc { color:#ff0 }
+	.hl.kwa { color:#ff0 !important }
+	.hl.kwb { color:#0f0 !important }
+	.hl.kwc { color:#ff0 !important }
 	/* .hl.kwd { color:#ccc } */
+
+	/* line-number (unused by public-inbox) */
+	/* .hl.lin { color:#ccc } */
 _
 }
 # end of auto-updated sub
@@ -89,7 +91,14 @@ if (scalar(@ARGV) == 1 && -r __FILE__) {
 	use autodie;
 	open my $ro, '<', $ARGV[0];
 	my $css = do { local $/; <$ro> };
+
+	# indent one level:
 	$css =~ s/^([ \t]*\S)/\t$1/smg;
+
+	# "!important" overrides whatever the BOFH sets:
+	$css =~ s/;/ !important;/sg;
+	$css =~ s/(\w) \}$/$1 !important }/msg;
+
 	open my $rw, '+<', __FILE__;
 	my $out = do { local $/; <$rw> };
 	$out =~ s/^sub CSS.*^_\n\}/sub CSS () {\n\t<<'_'\n${css}_\n}/sm;
-- 
EW

[PATCH 2/2] www: prevent '!important' in BOFH-specified CSS

[Eric Wong]

CSS specified by the BOFH must never take precedence over
what a user sets in userContent.css.
---
 lib/PublicInbox/WWW.pm | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/lib/PublicInbox/WWW.pm b/lib/PublicInbox/WWW.pm
index cbaf884..7ed4f65 100644
--- a/lib/PublicInbox/WWW.pm
+++ b/lib/PublicInbox/WWW.pm
@@ -512,8 +512,9 @@ sub stylesheets_prepare ($$) {
 		if (defined $attr->{href}) {
 			$inline_ok = 0;
 		} else {
-			open(my $fh, '<', $_) or do {
-				warn "failed to open $_: $!\n";
+			my $fn = $_;
+			open(my $fh, '<', $fn) or do {
+				warn "failed to open $fn: $!\n";
 				next;
 			};
 			my ($key) = (m!([^/]+?)(?:\.css)?\z!i);
@@ -523,6 +524,13 @@ sub stylesheets_prepare ($$) {
 				$ctime = sprintf('%x',(stat($fh))[10]);
 				$local = $mini->($local);
 			}
+
+			# do not let BOFHs override userContent.css:
+			if ($local =~ /!\s*important\b/i) {
+				warn "ignoring $fn since it uses `!important'\n";
+				next;
+			}
+
 			$css_map->{$key} = $local;
 			$attr->{href} = "$upfx$key.css?$ctime";
 			if (defined($attr->{title})) {
-- 
EW

Re: Default theme

[Mateusz Loskot]

On Sat, 23 Feb 2019 at 03:47, Eric Wong <e@80x24.org> wrote:
> UI preferences/colors is not as important as fighting against
> centralization.  So if my color preference puts people off and
> encourages light/un-themed mirrors to spawn, then it's a win :)

That makes a concluding point to me. Point taken.

Thank you for addressing my questions and all the explanations.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net