[solved] Dark/light modes via OS preference

Destry · 2020-12-15 08:06:38

Cool. I will try that. Maybe I get it working and see it in dev with the FF plugin.

(No, not live yet.)

Btw, I’ve always been putting single quotes around the url() path, like above, but I’m not sure why; probably copied it once upon a time and it stuck. But is that even necessary?

phiw13 · 2020-12-15 08:16:11

Destry wrote #327520:

Btw, I’ve always been putting single quotes around the url() path, like above, but I’m not sure why; probably copied it once upon a time and it stuck. But is that even necessary?

Technically quotes are not needed in “simple” cases, but it is not a bad habit to always include them

Quotes are required if the URL includes parentheses, whitespace, or quotes, unless these characters are escaped, or if the address includes control characters above 0×7e.

source

Destry · 2020-12-15 10:01:09

Well, that fell into place nicely. I can even use a single image to source both locations by adding the filter: opacity(); into the mix. And I can see it all in local development on my late 2011 laptop maxed out at Sierra by help of that Darker Mode plugin for Firefox. Ding!

(I was using two images before — 25op and 50op — that were created with different opacity values from a full opacity image; so I just learned something great about CSS filters. Will be using these more often, if ever having the chance.)

And after thinking about ::before solution, it even gives me an idea of trying something interesting with the nav. But that’s for later.

Btw, regarding ::before, when I first set it up, the pseudo was sitting on top of the .menu item links, so I couldn’t use the links. I put a z-index: -1; on it and that fixed the problem. I would have thought, though, that being before the main element box, it would have been under it already when stacked. Oh well.

I will push this in a while.

Come to think of it, if the element is stacked like a sandwich with ::before and ::after, then before is probably the top slice of bread, and I needed after?

Last edited by Destry (2020-12-15 11:09:44)

Destry · 2020-12-16 08:28:39

Life got in the way, so I haven’t pushed this yet, but I will within the hour.

I’ve been reading more on this stuff here, and the CSSWG spec on it, which has me thinking I don’t have it optimized yet (serving colors via a light.css and dark.css to reduce data loading, and allowing for a potential ‘sepia’ option), thus will be iterating on it a time or two, but I’ll get what I have up for a start.

Question, isn’t this a valid way to use custom properties?

hr {background: linear-gradient(to right, --hr-gradient-end-color, --hr-gradient-middle-color 50%, --hr-gradient-end-color);
}

If so, then I think I found another thing the FF plugin doesn’t recognize, because it doesn’t show up in testing.

Is it possible to break that linear-gradient() rule down more to separate the color rules out? I didn’t think it was, but maybe I’m wrong.

Last edited by Destry (2020-12-16 08:33:48)

phiw13 · 2020-12-16 08:45:27

Destry wrote #327540:

[…] serving colors via a light.css and dark.css to reduce data loading,

dont’t do that, unless your are serving enormous stylesheets (TXP backend stylesheets are not so big). You need to open two or more http connections which is way more expensive than downloading a couple of KB of text.

Question, isn’t this a valid way to use custom properties?

hr {background: linear-gradient(to right, --hr-gradient-end-color, --hr-gradient-middle-color 50%, --hr-gradient-end-color);...

not valid, you need to wrap into a var() :

hr {background: linear-gradient(to right, var(--hr-gradient-end-color), var(--hr-gradient-middle-color) 50%, var(--hr-gradient-end-color));
}

Last edited by phiw13 (2020-12-16 08:46:08)

jakob · 2020-12-16 08:46:43

Destry wrote #327540:

… (serving colors via a light.css and dark.css to reduce data loading, and allowing for a potential ‘sepia’ option) …

I think having a separate light/dark.css is overkill if you’re just switching out the css variables via a css-theme / group (like this for example) plus a few extra directives. The number of extra directives is likely not a huge amount of data and the if you have compression activated on your server (in htaccess for example), then a fair amount of the css is identical and the difference after compression will be minimal.

Question, isn’t this a valid way to use custom properties?

hr {background: linear-gradient(to right, --hr-gradient-end-color, --hr-gradient-middle-color 50%, --hr-gradient-end-color);...

I think you just need var(…) around your variables, e.g.:

hr { background: linear-gradient(to right, var(--hr-gradient-end-color), var(--hr-gradient-middle-color) 50%, var(--hr-gradient-end-color));
}

Is it possible to break that linear-gradient() rule down more to separate the color rules out? I didn’t think it was, but maybe I’m wrong.

Have a look at this page for one approach of using CSS (custom) variables with linear-gradient: What can you put in a CSS variable?

EDIT: Philippe was quicker and more concise :-)

Destry · 2020-12-16 09:19:30

jakob wrote #327543:

you just need var(…) around your variables

EDIT: Philippe was quicker and more concise :-)

Doh! I should have saw that. I’m not used to looking at these.

Thanks, and for the advice. I won’t make files.

Last edited by Destry (2020-12-16 09:19:40)

Destry · 2020-12-16 12:58:23

Pushed. I will change web form coloring. That’s a different theme. And I see I forgot the submit button colors.

Anything else you might see amiss, I’m all ears.

Destry · 2020-12-16 16:05:43

Destry wrote #327482:

And I noticed that if I use the background-image rules in the color-scheme set anyway…

. . .

It works to make those bar graphics on nav items and body links not appear in dark mode only

As it expectedly turns out, that’s only because the FF extension doesn’t show them, but I can see them on the live site. So it seems I’ll be able to fix those properly too.

Currently the nav hover graphic looks purple in my phone, but it’s supposed to be a darker blue.

———————-

Now it’s blue. Takes a while to propagate, I guess.

———————-

Realizing how much I would benefit from using CSS variables to manage my numerous font size assignments, often redundant across elements.

Last edited by Destry (2020-12-16 17:07:41)

phiw13 · 2021-03-24 08:25:41

Firefox 87 —out just today— now include a toggle to test “the other” media query (dark mode or light mode) build in the developper tools. That might be, for development, a better solution than the extension discussed above. See this Mozilla blog post (first item) for some details. I have no idea how well it works on systems that don’t have build-in Dark mode support. And it won’t help magically displaying webpages in Dark mode for everyday browsing of course.

Destry · 2021-05-19 07:26:55

phiw13 wrote #329416:

Firefox . . . toggle to test “the other” media query (dark mode or light mode) build in the developper tools.

Works nice in old macOS.

And, as you assumed, the color preference query does not work if dev tools are not active in same old OS. Dark Web Enforcer still needed in that case.

Still, since the color pref query got all popular, there’s been a lot of push-back on dark themes, and especially against websites that don’t offer a light theme option. Seems there are people trying really hard to discredit dark themes as bad for your eyes and problematic for people with existing eye problems, etc.

Sounds like a silly pissing war to me. I personally like the iOS preference that switches the mode in relation to day and night hours. My eyes are old and failing like anyone’s and this behaviour works well for me. I prefer dark mode screens at night and light in the day. Bright screens at night in low ambient light always feel like looking across white salt flats with the sun in my eyes. Having that automatically switch on a diurnal pattern on my phone is a pleasant change up. I wish my old macOS would do that.

Regardless, if the query is used correctly, adjusting to user preferences, there should be no problem. It’s a Yin-yang Thang, after all.

Textpattern CMS

Textpattern CMS support forum

#37 2020-12-15 08:06:38

Re: [solved] Dark/light modes via OS preference

#38 2020-12-15 08:16:11

Re: [solved] Dark/light modes via OS preference

Destry wrote #327520:

#39 2020-12-15 10:01:09

Re: [solved] Dark/light modes via OS preference

#40 2020-12-16 08:28:39

Re: [solved] Dark/light modes via OS preference

#41 2020-12-16 08:45:27

Re: [solved] Dark/light modes via OS preference

Destry wrote #327540:

#42 2020-12-16 08:46:43

Re: [solved] Dark/light modes via OS preference

Destry wrote #327540:

#43 2020-12-16 09:19:30

Re: [solved] Dark/light modes via OS preference

jakob wrote #327543:

#44 2020-12-16 12:58:23

Re: [solved] Dark/light modes via OS preference

#45 2020-12-16 16:05:43

Re: [solved] Dark/light modes via OS preference

Destry wrote #327482:

#46 2021-03-24 08:25:41

Re: [solved] Dark/light modes via OS preference

#47 2021-05-19 07:26:55

Re: [solved] Dark/light modes via OS preference

phiw13 wrote #329416:

Board footer