[solved] Dark/light modes via OS preference

Destry · 2020-12-14 20:37:33

I’m only keeping the 50op image (to be called, simply, ladder.png).

jakob wrote #327501:

How about like you had it above

I tried, but it doesn’t seem to work. Still loads the same light mode image. That would be the easiest and best solution for an image served from CSS, but it seems too good to be true.

I think I’ll have to take it out of the CSS and put it in a div, which I hate doing for just a presentation image. But then I can use filter: invert (100%);, perhaps.

Compromises.

phiw13 · 2020-12-14 23:06:33

Destry wrote #327502:

I tried, but it doesn’t seem to work. Still loads the same light mode image. That would be the easiest and best solution for an image served from CSS, but it seems too good to be true.

That code does work (assuming no typos, wrong path, …) but that extension you use does not seem to be able to handle that situation. A weakness in the extension ?

Destry · 2020-12-14 23:30:40

phiw13 wrote #327506:

That code does work (assuming no typos, wrong path, …) but that extension you use does not seem to be able to handle that situation. A weakness in the extension ?

Probably the extension.

Well, I just refactored the markup/css to put an extra stupid div in for the ladder image, which blows because I struggled for hours using absolute positioning (no doubt the worst way I could have gone) to get two dumb divs side by side and the ladder sized correctly, and that was just for one screen size. What a nightmare. And feels about as stable as a card house. I could have exercised instead and felt better.

But I can now say that this works:

@media (prefers-color-scheme: dark) {

  :root { [all the variables] }

  .ladder img { filter: invert(100%); }

}

And that’s nice, if I decide to keep it, because it only needs the one light mode image to work, so one less file.

But If you say that other way works, too, then I might change it all back because it doesn’t feel right with the div in the markup.

Last edited by Destry (2020-12-14 23:33:53)

Destry · 2020-12-15 07:21:21

I don’t like the image being content, and the extra (lousy, in my case) code it requires for it, so I’ll put it back to how I had it and push it live today and check the image on my phone to see if your right. If not I’ll revert again to the lousy markup, ‘cause the ladder stays, one way or the other. :}

Destry · 2020-12-15 07:52:14

Too bad the filter: invert(100%); can’t be used on a background image. Or can it…?

What about a pseudo element, so it doesn’t impact the menu content? This may not be exactly right, but for example:

.menu {
    overflow: hidden;
    position: relative;
}

.menu:before {
    position: absolute;
    width: 100%;
    height: 100%;
    background-image:url(‘/assets/.../ladder.png’);
    . . .
    filter: invert(100%);
}

Or would it be :after?

Last edited by Destry (2020-12-15 08:03:42)

phiw13 · 2020-12-15 08:02:39

You haven’t put if live yet I guess? Ask for testing…

As for your other suggestion, sure inserting the image via generated content (::before) would work
You need to specify the content property:

.menu::before { 
  content: '';
  background: url(path/to/image);
/* rest of your code */
}

or

.menu::before { 
  content: url(path/to/image);
 …
}

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)

Textpattern CMS support forum

#31 2020-12-14 20:37:33

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

jakob wrote #327501:

#32 2020-12-14 23:06:33

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

Destry wrote #327502:

#33 2020-12-14 23:30:40

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

phiw13 wrote #327506:

#34 2020-12-15 07:21:21

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

#35 2020-12-15 07:52:14

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

#36 2020-12-15 08:02:39

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

#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:

Board footer