My knee jerk reaction was "Arrrrg, not more darkness on the face of the Earth". But being able to switch in the browser based on an OS preference sounds like a great suggestion to me, even though I'd never be affected by it.

Oh, and I'm one of the nominal JavaScript off crowd (NoScript plugin on FireFox) too. If I follow a link to a news or other casual interest site that shows a blank page I usually close the tab. There is cool stuff that can be done with JavaScript, but most of the time it seems to be there to support stuff I find distracting and annoying.

My knee jerk reaction was "Arrrrg, not more darkness on the face of the Earth".

You are not alone. Dark mode is, for me, more eyestrain and gives me a headache.

But being able to switch in the browser based on an OS preference sounds like a great suggestion to me, even though I'd never be affected by it.

Yeah, i'm fine with it, as long as it only affects users who explicitly set their browser to dark mode. The question here is: Is there a standard (RFC, W3C, ...?) or is this just something that a few browser vendors handwaved into existence for their own software? I hate to support vendor-specific extensions: They tend to break on short notice, they might only work on certain operating systems and they are generally a nightmare to support long term.

PerlMonks XP is useless? Not anymore: XPD - Do more with your PerlMonks XP

Dark mode is, for me, more eyestrain and gives me a headache.

Yes, this is true for some people, my rough understading is that as it causes pupils to dilate more, this can cause vision to blur more.

The question here is: Is there a standard (RFC, W3C, ...?)

See my link in the root node: It's part of the Media Queries Level 5 W3C draft spec and has been supported by all major browsers for the past ~3-4 years.

I visited this node expecting to express some kind of violent NO (I hate dark themes), but with all the criteria you mentioned, I see no harm in what you are suggesting, so ++ from me.

FWIW any app that installs with default dark theme and no easy and obvious way to switch back to light theme is a no-go to me. I won't even read the manual if they inflict that on me.

G'day haukex,

Short Response

I would vote against this proposal in its current form.

I would, however, vote for a similar proposal where AM has a "Switch to dark theme" (or similar) option.

Longer Discussion

I typically access PM via a bookmarked link to my home node. This has the following features:

• I am an AM at this point.
• I see the current, default "light theme". For me, this is a clear indication that I'm not logged in.
• I can see "Last here:". Because I typically log in daily (often more than once) this usually indicates <24hrs. Sometimes I'm away longer than that and this tells me how far back I need to look at "Newest Nodes" and "Recently Active Threads".

I will usually log in immediately. This has these different features:

• I am 'kcott' at this point.
• I see my preferred "dark theme". For me, this is a clear indication that I am logged in.
• "Last here:" just tells me a second ago: not useful for viewing "Newest Nodes" and "Recently Active Threads", as described above.

There are a few situations where I revert to AM (logged off) during a session. Some examples:

• [By choice] I'm investigating some issue raised in "PerlMonks Discussion".
• [By choice] I want to see how my post looks to an AM; usually with respect to code or data wrapping.
• [Forced] A node contains a hard-coded link; e.g. I was logged in under www.perlmonks.org, I'm no longer logged in under www.perlmonks.com.

Being able to see at a glance whether I'm logged in or not means I never accidentally post replies as AM.

I would, however, vote for a similar proposal where AM has a "Switch to dark theme" (or similar) option.

But again, the users who my suggestion applies to have already expressed their preference for a dark theme by setting their OS and/or browser to a dark theme. Your suggestion is theoretically possible with JavaScript (I've implemented a toggle like that myself), but ignores the aforementioned preference. (Cue the people who browse the web with JS turned off complaining next ;-) )

The point you raise, accidentally posting replies as AM, could easily solved differently by e.g. displaying a clear notice next to the submit button, there is no need for the entire site to be a relative retina-burning white when just about every other site and app respects the dark mode option.

Updated as per reply below.

I was simply expressing my opinion in a polite, even-tempered manner. I'm somewhat surprised at the tone of your response.

"... the users who my suggestion applies to have already expressed their preference for a dark theme ..."

I did write: 'I see my preferred "dark theme".'; so I'm one of those users.

"Your suggestion is theoretically possible ..."

I made no suggestion. I merely stated an alternative proposal that I would support.

"... there is no need for the entire site ..."

I would rarely browse more that one node as an AM.

"... to be a relative retina-burning white when just about every other site and app respects the dark mode option."

See https://www.perl.org/, https://www.perl.com/, anything linked from the newly added Slashdot & HackerNews nodelets, and many, many more that do not use a dark theme (which both my O/S and browser settings indicate).

Anyway, as I said, I'm just giving my opinion. I am not attempting to champion a cause. If you don't like my opinion, that's OK.

— Ken

this tells me how far back I need to look at "Newest Nodes" and "Recently Active Threads"

Newest Nodes and Recently Active Threads keep track of that automatically for you; you shouldn't have to manage that yourself.

I will usually log in immediately ... There are a few situations where I revert to AM ...

How are you doing that? You shouldn't need to explicitly log out and in again. The Domain Nodelet is useful for managing this. You can log into each of your pups on a different domain, and any others will serve for AM access; then just jump between them via the Domain Nodelet.

"Newest Nodes and Recently Active Threads keep track of that automatically for you; you shouldn't have to manage that yourself."

That's not been my experience; I have had to manage it manually. Do I need to adjust one or more settings somewhere for this to be automatic?

"How are you doing that? You shouldn't need to explicitly log out and in again."

I don't log in and out. Say I'm logged in using www.perlmonks.org, here's two common methods I use (with Firefox):

• Duplicate Tab, then change org to net (or similar): different URL; no cookies set for this URL; not logged in.
• Right-click then "Open Link in New Private Window": same URL; no cookies set in new private session; not logged in.

"... via the Domain Nodelet."

I've seen that in the past; it used to appear automatically; I never used it. I now see it's an opt-in via "Nodelet Settings". But thanks anyway for pointing it out.

— Ken

I share the opinions of GrandFather and Tux.

I don't get why people want black backgrounds. The last time I payed attention, it was all about energy saving, and at that time, when most people stared at LCD, it was utterly nonsense:

Back in the old days, when I still had my old ZX Spectrum+, having green text on black background felt cool, like working on an even older terminal (DEC VT100 and the like). Even when I was only playing with the Sinclair BASIC interpreter. Back then, CRTs were the dominant display technology, having a black background with only a few bright pixels for the text really had advantages. You would use a little bit less energy (black pixel = no electron beam = no current = no power needed for the pixel). That was not that important for the environment or the electricity bill, but it also reduce the load on the high voltage generated (as a by-product) by the horizontal deflection transformer. Stabilisation of the high voltage was not that great for decades, and so the numnber of bright pixels per line influenced the horizontal deflection. Bright lines needed more energy, so there was less energy left for the horizontal deflection, and so the image width was reduced for the bright lines. Keeping the background black largely avoided this effect. On later CRT monitors (and TV sets), high voltage stabilisation was way improved, and so the advantage of a black background for the image stability was gone.

I still own an Eizo T566 CRT monitor (17 inch 4:3). Its technical data report a power consumption of 110 W. I don't know the exact anode voltage of the CRT, but it is usually around 25 kV, a little bit less on smaller CRTs, a little bit more on larger CRTs. The anode current for a white image is typically around 1 mA to 1.5 mA, a little bit more on Sony Trinitron CRTs, a little less on CRTs designed to run 24/7. Multiplying both values gives about 25 W to 40 W used to display a white image. In other words, switching from 100 % white to 100 % black reduces the power consumption by 25 W to 40 W, about a quarter to a third of the total consumption.

Now, LCDs in several variants are standard, the older ones used cold cathode backlights, newer ones use LED backlights. The backlight, as the name implies, illuminates the backside of the LCD. Typically, this is implemented as a large diffuser illuminated from one or both sides(!) of the screen. The LCD is switched to block light for a black pixel, and to let light pass for a white pixel. What you see on a (monochrome) LCD are shadows in front of a constantly bright backlight. (Color LCDs have R/G/B color filters the optical path, so you get colored shadows.) Switching an LCD pixel needs power, but a steady-state pixel does not. The main consumer for a static image is the backlight, and because its brightness does not change with the image, the power consumption is also constant. Or shorter, it does not matter if an LCD shows a dark or a bright image.

Modern LCDs have backlights splitted into a few rectangles that can be individually dimmed depending on the image content. This is nice if the image is a dark szene with only a few bright spots. But if you fill the screen with white text on a black background, the entire backlight has to be as bright as the brightest pixel. So, no energy savings here.

Displays based on a matrix of tiny LEDs (in contrast to LED-backlit LCDs) are rare and expensive, especially at sizes typical for monitors and TVs. (Displays used in statiums may use LEDs, but with pixel sizes in the mm range.) Like CRTs, their energy consumption depends largely on the bightness of the image. A black image simply has all LEDs switched off, so no current. LEDs may burn in, very much like phospor-based CRTs. In order to equalize wear on the LEDs, modern LED-based TVs and monitors turn on the less-used LEDs in standby mode and intentionally wear them to to reach the wear level of the LEDs that were bright while the TV/monitor was turned on. So again, no energy saved.

Alexander

Thanks for the feedback, and no, it's not about energy savings, it's just a preference: If I'm using my phone in a dark environment, and every other app and website that I use regularly respects the dark mode setting, then I just find it really unpleasant to have your eyes suddenly blasted with white light (this is true even when the display's brightness is turned down and/or the blue filter is on). And in my experience, dark mode is improved by having modern, good screens that have good black levels; I'm not sure I'd find dark mode on an old CRT or even an old LCD with a strong backlight blead as pleasant.

But in going through the new themes, and trying to figure out whether I needed a particular class to swap the link/visited colors, I discovered that the theme is enforced by embedding a style tag linking to the right stylesheet node (though now that I reread the original post, I see that was already strongly hinted by the node_id's in haukex's example AM theme). So that means it's easy to look at what selectors need to be set to give a "fully-defined theme" by just looking at each stylesheet node, which means you can make any theme which suits your fancy.

Theme	Mode	Desc
Blue	Light	Default: Blue bar
Green	Light	Like Default, but Green bar
Red	Light	Like Default, but Red bar
Perl-blue	Light	Offwhite background, Blue bar
Dark	Dark	Black background, Gray bar
JBlue	Dark	Blue background, Red bar
Night Shift	Dark	Black background, Green Bar (comments in View Source for a page using this theme imply Corion created the theme)
No Theme	None	Does not include a stylesheet link at all; presumably the best choice if you want to completely design your own theme using the Display Settings's On-Site CSS Markup and/or Link to External CSS stylesheet

So for those who want AM to be dark based on browser settings, and want a different dark theme for their logged in self, to be able to tell at a glance that they aren't logged in, I would suggest seeing if one of the alternate darkish themes would work for your logged-in usage. Or just do a noticeable tweak using On-Site/External CSS. Or create your fully-customized Personal-Dark Theme coupled with picking "No Theme", .

Part of me wants to say that it would be a good idea to honor the OS/browser preferences for even anonymous users, and to switch AM to Dark Mode when their OS/browser asks for it (and that's the part of me that actually wins). Part of me thinks that maybe leaving it the "glaringly bright" default theme would at least discourage some anonymous usage and especially anonymous posting -- at least by anonymonks who don't like light themes. (Anyone want to join me in voting for a nearly-impossible-to-post-theme for AM, which makes the posting form foreground=background and hides the submit button? No? Oh, well.)

But putting aside my anti-anonymous bias, the user-friendly thing to do is to honor OS/browser settings, and have Dark Theme auto-selected for anonymous users who have that browser setting.

e.g. on mobile where I'm not logged in by default

Not that I'm necessarily against the proposal but this phrase is the one which surprises me. If the status quo is so bad for you, why not just login on mobile? Wouldn't that solve it for you, personally?

I use the dark theme here and like kcott it means that there is no way I can miss being logged out. I appreciate that this is almost certainly not a common enough accidental use case of how things are to count against the proposal.

It has also been my experience that the overwhelming majority of sites don't honour the OS/DE/Browser default mode anyway (yet). Again, that's not to say that the Monastery shouldn't, but nor does it make it an outlier in this regard. A fair proportion of the key sites I visit have (or had) such poor styling anyway that I use my own CSS ⃰ in preference to theirs which takes away a lot of the related problems. YMMV.

Overall I'm ambivalent about this proposal. It would be nice to see a response from Anonymous Monk here one way or the other. If they were to find it useful then that would make it worth doing.

⃰ Or borrow someone else's.

Thanks for the feedback!

... why not just login on mobile? Wouldn't that solve it for you, personally?

Yes, it would; that I'm not logged in by default on mobile is also a matter of personal preference: since a mobile device is something I can theoretically lose more easily, and despite the fact that my mobile is of course password protected too, I still prefer to reduce the number of things that are permanently logged in on it. (I also very rarely post from mobile because I find it more tedious to type on.)

I would say my proposal has the advantage of also respecting the preferences of all other anonymous visitors with this option turned on - how many there are I don't know of course, but I'm betting it's not zero. And even though it's only a small thing, considering how relatively easy it should be to implement (I hope), I think it's a nice thing to do for new visitors.

... there is no way I can miss being logged out. I appreciate that this is almost certainly not a common enough accidental use case of how things are to count against the proposal.

I'd be happy to support a variation of this where there are two different dark themes with different foreground colors in order to make it easier to tell the difference between being logged in and logged out (though personally, my nodelet configuration is different enough from the default that this would probably be enough for me to differentiate).

Another advantage of my suggestion is that it can help even logged in monks: Say for example I want to use the system-wide light theme during the day and the system-wide dark theme in the evenings, I can do so with a single preference change in my OS, and the setting immediately propagates everywhere. Without an "auto light/dark" theme on PerlMonks, I would have to go into my display settings on PM every time, which is (relatively) cumbersome. (This of course doesn't require a change in AM's settings, that could come later after sufficient testing of the new theme.)

It would be nice to see a response from Anonymous Monk here

Ehhh.... That's not how that works. :-D

Today's latest and greatest software contains tomorrow's zero day exploits.

Thanks for the feedback so far everyone!