Обсуждение: Dark mode styling for the website

On 10/10/22 12:07 PM, Dave Page wrote:
> Inspired by Dago A Carralero's email earlier today, I started looking
> into what it would take to actually add a dark mode to the entire
> website. Turns out it's not actually that difficult; the attached patch
> took just a couple of hours of fiddling.

Thanks!

> It leaves the existing styling as the default, and uses CSS media
> queries to override certain styles if the browser reports that dark mode
> is preferred. Colours are loosely based on the dark theme for pgAdmin
> (which is of course, based on PostgreSQL blue), with a few other new
> ones added where there were no suitable ones in the pgAdmin palette.
>
> Of course, this is a PoC at this point, for review and comments. I may
> have missed some styles, and the actual colors used are obviously a
> matter for some serious bikeshedding.
>
> Thoughts, comments, and paint colour suggestions welcome.

I don't know if I'll have time to test this week due to the major release.

My general comment on the patch as is stands is around the heavy use of
"!important"; if we have to override styles with that, then something is
not cascading correctly and we should fix that.

Some of the original CSS from the design does have "!important" in it,
though we've been trying to roll back what we can as we come across it.
There are some legit use cases (e.g. overriding something Bootstrap is
doing that we can't otherwise override), but I'd prefer if we don't
introduce further !important's.

On 10/10/22 18:07, Dave Page wrote:
> Inspired by Dago A Carralero's email earlier today, I started looking into
> what it would take to actually add a dark mode to the entire website. Turns
> out it's not actually that difficult; the attached patch took just a couple
> of hours of fiddling.
>
> It leaves the existing styling as the default, and uses CSS media queries
> to override certain styles if the browser reports that dark mode is
> preferred. Colours are loosely based on the dark theme for pgAdmin (which
> is of course, based on PostgreSQL blue), with a few other new ones added
> where there were no suitable ones in the pgAdmin palette.
>
> Of course, this is a PoC at this point, for review and comments. I may have
> missed some styles, and the actual colors used are obviously a matter for
> some serious bikeshedding.
>
> Thoughts, comments, and paint colour suggestions welcome.


I fully support a dark mode on our website.  However, I do not like this
implementation.

There should be a :root selector that defines variables for all of the
colors, and then this patch would just override that.  This would
harmonize the whole of the styling (avoiding typos and other random
coloring), and future-proof having to override everything everywhere and
cluttering the sheet.

I agree with Jonathan that the !important flags are unfortunate.  The
best would be to integrate Bootstrap into the build system so that it
can pick up our theme colors at the source, but that is not a job for
this patch.  It should perhaps be done before this patch, though.

On Wed, 12 Oct 2022 at 02:58, Vik Fearing <vik@postgresfriends.org> wrote:

On 10/10/22 18:07, Dave Page wrote:
> Inspired by Dago A Carralero's email earlier today, I started looking into
> what it would take to actually add a dark mode to the entire website. Turns
> out it's not actually that difficult; the attached patch took just a couple
> of hours of fiddling.
>
> It leaves the existing styling as the default, and uses CSS media queries
> to override certain styles if the browser reports that dark mode is
> preferred. Colours are loosely based on the dark theme for pgAdmin (which
> is of course, based on PostgreSQL blue), with a few other new ones added
> where there were no suitable ones in the pgAdmin palette.
>
> Of course, this is a PoC at this point, for review and comments. I may have
> missed some styles, and the actual colors used are obviously a matter for
> some serious bikeshedding.
>
> Thoughts, comments, and paint colour suggestions welcome.


I fully support a dark mode on our website.  However, I do not like this
implementation.

There should be a :root selector that defines variables for all of the
colors, and then this patch would just override that.  This would
harmonize the whole of the styling (avoiding typos and other random
coloring), and future-proof having to override everything everywhere and
cluttering the sheet.

Well that harmonising took about 4x the amount of time the original patch did. And then adding dark mode colour over it took, well, not long at all. I need a rest now.

So here's an updated patch, the vast majority of which is breaking out the original colour specifications into per-id/class variables. Depending on how far we want to take this, we could add another layer of indirection so we have one variable defined for each colour we use (naming of which would be a nightmare, as obviously we wouldn't want to name them for the actual colours as that's dependent on the scheme in use), and then assign those variables to the per-id/class variables. Whilst that would mean any single colour could then be changed in one place, I'm not sure it's worth the pain over just doing a search/replace. 

 

I agree with Jonathan that the !important flags are unfortunate.  The
best would be to integrate Bootstrap into the build system so that it
can pick up our theme colors at the source, but that is not a job for
this patch.  It should perhaps be done before this patch, though.

I managed to get rid of a few more - the total with the latest patch is +2 over the current code. I also cleaned up some duplicated styles and inefficient notation (e.g. borders with 5 lines specifying sizes and colour, which can be done in one line). 

On Thu, Oct 13, 2022 at 12:46:15PM +0100, Dave Page wrote:
> FYI, I've setup a test instance at
> http://ec2-18-170-0-35.eu-west-2.compute.amazonaws.com
> One minor change since the last patch: FontAwesome icons are now shown in
> the same off-white as the text, rather than pure white.

Not sure if this is the time for comments on the colors/readability,

but just in case:

Firefox 105.0.3 on Ubuntu Ubuntu 22.04.1

My comments:
1. In the latest releases list, there is even/odd difference in
   background between versions. The lighter background is too light, and
   makes it harder to read "Notes", plus I'd say it's a bit jarring.
2. Same problem for Upcoming events.
3. "Learning Opportunities Ahead" section is on white background, with
   while title, which is invisible unless selected.
4. Same problem in "Seeing unexpected behavior?" section.

On Thu, Oct 13, 2022 at 01:33:37PM +0100, Dave Page wrote:
> > My comments:
> > 1. In the latest releases list, there is even/odd difference in
> >    background between versions. The lighter background is too light, and
> >    makes it harder to read "Notes", plus I'd say it's a bit jarring.
> > 2. Same problem for Upcoming events.
> > 3. "Learning Opportunities Ahead" section is on white background, with
> >    while title, which is invisible unless selected.
> > 4. Same problem in "Seeing unexpected behavior?" section.
> How is it now?

Much better.

The only question that I have - do we have to have these
white sections?

On Thu, 13 Oct 2022 at 14:01, hubert depesz lubaczewski <depesz@depesz.com> wrote:

On Thu, Oct 13, 2022 at 01:33:37PM +0100, Dave Page wrote:
> > My comments:
> > 1. In the latest releases list, there is even/odd difference in
> >    background between versions. The lighter background is too light, and
> >    makes it harder to read "Notes", plus I'd say it's a bit jarring.
> > 2. Same problem for Upcoming events.
> > 3. "Learning Opportunities Ahead" section is on white background, with
> >    while title, which is invisible unless selected.
> > 4. Same problem in "Seeing unexpected behavior?" section.
> How is it now?

Much better.

Thanks.

 

The only question that I have - do we have to have these
white sections?

Well they don't need to be white if that's what you mean?

On Thu, Oct 13, 2022 at 02:47:24PM +0100, Dave Page wrote:
> Actually, there was a bug there. When moving everything to use CSS vars, I
> switched the foreground and background colours for both schemes. It's fixed
> now.

Currently the two sections:
"Learning Opportunities Ahead"
and
"Seeing unexpected behavior?"

no longer have white background, which is great. The background is now
blue, but so is color of section title...

On Wed, 12 Oct 2022 at 16:04, Dave Page <dpage@pgadmin.org> wrote:

On Wed, 12 Oct 2022 at 02:58, Vik Fearing <vik@postgresfriends.org> wrote:

On 10/10/22 18:07, Dave Page wrote:
> Inspired by Dago A Carralero's email earlier today, I started looking into
> what it would take to actually add a dark mode to the entire website. Turns
> out it's not actually that difficult; the attached patch took just a couple
> of hours of fiddling.
>
> It leaves the existing styling as the default, and uses CSS media queries
> to override certain styles if the browser reports that dark mode is
> preferred. Colours are loosely based on the dark theme for pgAdmin (which
> is of course, based on PostgreSQL blue), with a few other new ones added
> where there were no suitable ones in the pgAdmin palette.
>
> Of course, this is a PoC at this point, for review and comments. I may have
> missed some styles, and the actual colors used are obviously a matter for
> some serious bikeshedding.
>
> Thoughts, comments, and paint colour suggestions welcome.


I fully support a dark mode on our website.  However, I do not like this
implementation.

There should be a :root selector that defines variables for all of the
colors, and then this patch would just override that.  This would
harmonize the whole of the styling (avoiding typos and other random
coloring), and future-proof having to override everything everywhere and
cluttering the sheet.

Well that harmonising took about 4x the amount of time the original patch did. And then adding dark mode colour over it took, well, not long at all. I need a rest now.

So here's an updated patch, the vast majority of which is breaking out the original colour specifications into per-id/class variables. Depending on how far we want to take this, we could add another layer of indirection so we have one variable defined for each colour we use (naming of which would be a nightmare, as obviously we wouldn't want to name them for the actual colours as that's dependent on the scheme in use), and then assign those variables to the per-id/class variables. Whilst that would mean any single colour could then be changed in one place, I'm not sure it's worth the pain over just doing a search/replace. 

 

I agree with Jonathan that the !important flags are unfortunate.  The
best would be to integrate Bootstrap into the build system so that it
can pick up our theme colors at the source, but that is not a job for
this patch.  It should perhaps be done before this patch, though.

I managed to get rid of a few more - the total with the latest patch is +2 over the current code. I also cleaned up some duplicated styles and inefficient notation (e.g. borders with 5 lines specifying sizes and colour, which can be done in one line). 

FYI, I've setup a test instance at http://ec2-18-170-0-35.eu-west-2.compute.amazonaws.com

FYI, I've setup a test instance at http://ec2-18-170-0-35.eu-west-2.compute.amazonaws.com

And a feature branch can be found at: https://github.com/dpage/pgweb/tree/darkmode 

On 10/18/22 7:14 AM, Dave Page wrote:
>
>
> On Thu, 13 Oct 2022 at 15:45, Dave Page <dpage@pgadmin.org
> <mailto:dpage@pgadmin.org>> wrote:
>
>
>         FYI, I've setup a test instance at
>         http://ec2-18-170-0-35.eu-west-2.compute.amazonaws.com
>         <http://ec2-18-170-0-35.eu-west-2.compute.amazonaws.com>
>
>
>     And a feature branch can be found at:
>     https://github.com/dpage/pgweb/tree/darkmode
>     <https://github.com/dpage/pgweb/tree/darkmode>
>
>
> Here's the latest diff between my dev branch and the master branch.

Thanks! Overall looks good, I think this is close to being ready.

I went through the patch + browsed whole bunch of links. I made a few
changes (attached) and have a question.

Changes:

1. The "heart" on the About page was coming up as gray, which seemed
sad. So I set it to #b52525 (red) in both light/dark mode.

2. The "alert-warning" in the docs (e.g. docs for a deprecated version)
was blaring color, so I softened it a bit.

3. The code was reading "colour" in a few places. While we use British
English on the website content, we have not done that in code to date,
so I reverted to "color"

Questions:

1. General font color (noticed this in docs). We're using #336791 which
is the "standard PG blue", but it can blend in (headers, links)
particularly on pages with a lot of content. I boosted it to #2b6da3,
which made it a bit sharper, but wanted to raise this given it would not
be the "standard blue".

On 10/18/22 11:43 AM, Dave Page wrote:
> Hi
>
> I've put a note in my calendar to commit this at or after 11AM UK time
> on Thursday. Unless I hear objections before then, I'll do that.

Here's a diff with the discussed color changes.

There were some places where swapping the PG default with the lighter
shade would be a bit too bright, so I focused mainly on the
text/buttons. I did move the topbar to using the color, since that is
something we do want to draw attention to.

On Thu, 20 Oct 2022 at 02:08, Jonathan S. Katz <jkatz@postgresql.org> wrote:

On 10/18/22 11:43 AM, Dave Page wrote:
> Hi
>
> I've put a note in my calendar to commit this at or after 11AM UK time
> on Thursday. Unless I hear objections before then, I'll do that.

Here's a diff with the discussed color changes.

There were some places where swapping the PG default with the lighter
shade would be a bit too bright, so I focused mainly on the
text/buttons. I did move the topbar to using the color, since that is
something we do want to draw attention to.

Thanks. Demo site updated. I'll push the changes to prod in 1:30 hours or thereabouts. 

It looks amazing with the dark mode, awesome job.

> On 20 Oct 2022, at 12:54, Jonathan S. Katz <jkatz@postgresql.org> wrote:
>
> On 10/20/22 6:53 AM, Dave Page wrote:
>> On Thu, 20 Oct 2022 at 09:40, Dave Page <dpage@pgadmin.org <mailto:dpage@pgadmin.org>> wrote:
>>    On Thu, 20 Oct 2022 at 02:08, Jonathan S. Katz <jkatz@postgresql.org
>>    <mailto:jkatz@postgresql.org>> wrote:
>>        On 10/18/22 11:43 AM, Dave Page wrote:
>>         > Hi
>>         >
>>         > I've put a note in my calendar to commit this at or after
>>        11AM UK time
>>         > on Thursday. Unless I hear objections before then, I'll do that.
>>        Here's a diff with the discussed color changes.
>>        There were some places where swapping the PG default with the
>>        lighter
>>        shade would be a bit too bright, so I focused mainly on the
>>        text/buttons. I did move the topbar to using the color, since
>>        that is
>>        something we do want to draw attention to.
>>    Thanks. Demo site updated. I'll push the changes to prod in 1:30
>>    hours or thereabouts. And... done!
>> Thanks folks.
>
> Thanks everyone!
>
> Jonathan
>

I agree that the blue-black contrast (e.g., navigation) doesn't seem big enough and also that having the option to flip dark mode on or off on the website itself (cookie memory) would be especially nice.  Having the only control (that I know of) be a system-wide dark mode setting is not desirable for me.

I do appreciate the option and the work that has gone into it.  Just needs a few more tweaks IMO (and some others).

On Wed, 26 Oct 2022 at 20:03, David G. Johnston <david.g.johnston@gmail.com> wrote: 

I agree that the blue-black contrast (e.g., navigation) doesn't seem big enough and also that having the option to flip dark mode on or off on the website itself (cookie memory) would be especially nice.  Having the only control (that I know of) be a system-wide dark mode setting is not desirable for me.

I do appreciate the option and the work that has gone into it.  Just needs a few more tweaks IMO (and some others).

I haven't yet looked into increasing the contrast, but I have pushed the beginnings of a patch to my dev branch that implements manual switching that can override the auto-detected preference. It will use local storage to record your preference for the next visit. You can try it out at:

http://ec2-18-170-0-35.eu-west-2.compute.amazonaws.com

The only issue I can find at the moment is that this will effectively disable dark mode entirely for users that don't have Javascript enabled.

On Thu, Nov 3, 2022 at 7:19 AM Dave Page <dpage@pgadmin.org> wrote:

On Wed, 26 Oct 2022 at 20:03, David G. Johnston <david.g.johnston@gmail.com> wrote: 

I agree that the blue-black contrast (e.g., navigation) doesn't seem big enough and also that having the option to flip dark mode on or off on the website itself (cookie memory) would be especially nice.  Having the only control (that I know of) be a system-wide dark mode setting is not desirable for me.

I do appreciate the option and the work that has gone into it.  Just needs a few more tweaks IMO (and some others).

I haven't yet looked into increasing the contrast, but I have pushed the beginnings of a patch to my dev branch that implements manual switching that can override the auto-detected preference. It will use local storage to record your preference for the next visit. You can try it out at:

http://ec2-18-170-0-35.eu-west-2.compute.amazonaws.com

Thank you. Works nicely on Windows 11 Chrome and iPad Chrome.

The sun icon looks very similar to the settings cog icon, which maybe gets the outcome (someone clicking it to see how to change the darkmode setting), but was a tiny bit confusing at first.  The feature is new enough to me that I'm not really sure what the conventions are.  Having the moon always visible but only a label, and then a left-right option toggle widget is maybe a bit uglier but seems more explicit in how to interact with it.

Another icon thought, to leave the widget as just an icon, would be to always show a moon but use inverted color schemes.  The existing dark moon in light mode then a light moon on dark background(with a white box border) while in dark mode.

The only issue I can find at the moment is that this will effectively disable dark mode entirely for users that don't have Javascript enabled.

I suppose you'd have to make the button into a hyperlink that requests the same page from the server again but with a URL parameter specifying explicitly whether to supply a CSS with darkmode enabled or disabled (the resulting page would just use the complementary URL parameter value).  Though the initial page would be an issue since I'm guessing the server has no idea what system preference has been chosen.  We'd probably have to simply discard adhering to the system setting at all, return the light page by default, and, probably via a cookie, change the default through the GUI widget.  With cookies disabled you could still request your current page in dark mode but the system would not remember the choice - though maybe referrer and/or URL rewriting could provide the necessary information and link munging capability respectively.

On Thu, 3 Nov 2022 at 10:40, David G. Johnston <david.g.johnston@gmail.com> wrote:

On Thu, Nov 3, 2022 at 7:19 AM Dave Page <dpage@pgadmin.org> wrote:

On Wed, 26 Oct 2022 at 20:03, David G. Johnston <david.g.johnston@gmail.com> wrote: 

I agree that the blue-black contrast (e.g., navigation) doesn't seem big enough and also that having the option to flip dark mode on or off on the website itself (cookie memory) would be especially nice.  Having the only control (that I know of) be a system-wide dark mode setting is not desirable for me.

I do appreciate the option and the work that has gone into it.  Just needs a few more tweaks IMO (and some others).

I haven't yet looked into increasing the contrast, but I have pushed the beginnings of a patch to my dev branch that implements manual switching that can override the auto-detected preference. It will use local storage to record your preference for the next visit. You can try it out at:

http://ec2-18-170-0-35.eu-west-2.compute.amazonaws.com

The sun icon looks very similar to the settings cog icon, which maybe gets the outcome (someone clicking it to see how to change the darkmode setting), but was a tiny bit confusing at first.  The feature is new enough to me that I'm not really sure what the conventions are.  Having the moon always visible but only a label, and then a left-right option toggle widget is maybe a bit uglier but seems more explicit in how to interact with it.

Another icon thought, to leave the widget as just an icon, would be to always show a moon but use inverted color schemes.  The existing dark moon in light mode then a light moon on dark background(with a white box border) while in dark mode.

That's certainly doable, though it would require more CSS of course. Another option would be to simply change the icon. There's a lightbulb one that could work: https://fontawesome.com/v4/icon/lightbulb-o ?

On Thu, Nov 3, 2022 at 8:04 AM Dave Page <dpage@pgadmin.org> wrote:

On Thu, 3 Nov 2022 at 10:40, David G. Johnston <david.g.johnston@gmail.com> wrote:

On Thu, Nov 3, 2022 at 7:19 AM Dave Page <dpage@pgadmin.org> wrote:

On Wed, 26 Oct 2022 at 20:03, David G. Johnston <david.g.johnston@gmail.com> wrote: 

I agree that the blue-black contrast (e.g., navigation) doesn't seem big enough and also that having the option to flip dark mode on or off on the website itself (cookie memory) would be especially nice.  Having the only control (that I know of) be a system-wide dark mode setting is not desirable for me.

I do appreciate the option and the work that has gone into it.  Just needs a few more tweaks IMO (and some others).

I haven't yet looked into increasing the contrast, but I have pushed the beginnings of a patch to my dev branch that implements manual switching that can override the auto-detected preference. It will use local storage to record your preference for the next visit. You can try it out at:

http://ec2-18-170-0-35.eu-west-2.compute.amazonaws.com

The sun icon looks very similar to the settings cog icon, which maybe gets the outcome (someone clicking it to see how to change the darkmode setting), but was a tiny bit confusing at first.  The feature is new enough to me that I'm not really sure what the conventions are.  Having the moon always visible but only a label, and then a left-right option toggle widget is maybe a bit uglier but seems more explicit in how to interact with it.

Another icon thought, to leave the widget as just an icon, would be to always show a moon but use inverted color schemes.  The existing dark moon in light mode then a light moon on dark background(with a white box border) while in dark mode.

That's certainly doable, though it would require more CSS of course. Another option would be to simply change the icon. There's a lightbulb one that could work: https://fontawesome.com/v4/icon/lightbulb-o ?

The moon-only with coloring would just be two different icons as well (though it would be a custom icon versus two different standard ones so definitely not as easy).  I do like the lightbulb over the sun icon.  I'd go with it as the easier solution at this point.

On Thu, 3 Nov 2022 at 11:09, David G. Johnston <david.g.johnston@gmail.com> wrote:

On Thu, Nov 3, 2022 at 8:04 AM Dave Page <dpage@pgadmin.org> wrote:

On Thu, 3 Nov 2022 at 10:40, David G. Johnston <david.g.johnston@gmail.com> wrote:

On Thu, Nov 3, 2022 at 7:19 AM Dave Page <dpage@pgadmin.org> wrote:

On Wed, 26 Oct 2022 at 20:03, David G. Johnston <david.g.johnston@gmail.com> wrote: 

I agree that the blue-black contrast (e.g., navigation) doesn't seem big enough and also that having the option to flip dark mode on or off on the website itself (cookie memory) would be especially nice.  Having the only control (that I know of) be a system-wide dark mode setting is not desirable for me.

I do appreciate the option and the work that has gone into it.  Just needs a few more tweaks IMO (and some others).

I haven't yet looked into increasing the contrast, but I have pushed the beginnings of a patch to my dev branch that implements manual switching that can override the auto-detected preference. It will use local storage to record your preference for the next visit. You can try it out at:

http://ec2-18-170-0-35.eu-west-2.compute.amazonaws.com

The sun icon looks very similar to the settings cog icon, which maybe gets the outcome (someone clicking it to see how to change the darkmode setting), but was a tiny bit confusing at first.  The feature is new enough to me that I'm not really sure what the conventions are.  Having the moon always visible but only a label, and then a left-right option toggle widget is maybe a bit uglier but seems more explicit in how to interact with it.

Another icon thought, to leave the widget as just an icon, would be to always show a moon but use inverted color schemes.  The existing dark moon in light mode then a light moon on dark background(with a white box border) while in dark mode.

That's certainly doable, though it would require more CSS of course. Another option would be to simply change the icon. There's a lightbulb one that could work: https://fontawesome.com/v4/icon/lightbulb-o ?

The moon-only with coloring would just be two different icons as well (though it would be a custom icon versus two different standard ones so definitely not as easy).  I do like the lightbulb over the sun icon.  I'd go with it as the easier solution at this point.

I've pushed this change to the dev branch and test site. 

http://ec2-18-170-0-35.eu-west-2.compute.amazonaws.com

I've also now pushed another change to increase the contrast (Wave seems happy now).

On Thu, 3 Nov 2022 at 13:28, Dave Page <dpage@pgadmin.org> wrote:

On Thu, 3 Nov 2022 at 11:09, David G. Johnston <david.g.johnston@gmail.com> wrote:

On Thu, Nov 3, 2022 at 8:04 AM Dave Page <dpage@pgadmin.org> wrote:

On Thu, 3 Nov 2022 at 10:40, David G. Johnston <david.g.johnston@gmail.com> wrote:

On Thu, Nov 3, 2022 at 7:19 AM Dave Page <dpage@pgadmin.org> wrote:

On Wed, 26 Oct 2022 at 20:03, David G. Johnston <david.g.johnston@gmail.com> wrote: 

I agree that the blue-black contrast (e.g., navigation) doesn't seem big enough and also that having the option to flip dark mode on or off on the website itself (cookie memory) would be especially nice.  Having the only control (that I know of) be a system-wide dark mode setting is not desirable for me.

I do appreciate the option and the work that has gone into it.  Just needs a few more tweaks IMO (and some others).

I haven't yet looked into increasing the contrast, but I have pushed the beginnings of a patch to my dev branch that implements manual switching that can override the auto-detected preference. It will use local storage to record your preference for the next visit. You can try it out at:

http://ec2-18-170-0-35.eu-west-2.compute.amazonaws.com

The sun icon looks very similar to the settings cog icon, which maybe gets the outcome (someone clicking it to see how to change the darkmode setting), but was a tiny bit confusing at first.  The feature is new enough to me that I'm not really sure what the conventions are.  Having the moon always visible but only a label, and then a left-right option toggle widget is maybe a bit uglier but seems more explicit in how to interact with it.

Another icon thought, to leave the widget as just an icon, would be to always show a moon but use inverted color schemes.  The existing dark moon in light mode then a light moon on dark background(with a white box border) while in dark mode.

That's certainly doable, though it would require more CSS of course. Another option would be to simply change the icon. There's a lightbulb one that could work: https://fontawesome.com/v4/icon/lightbulb-o ?

The moon-only with coloring would just be two different icons as well (though it would be a custom icon versus two different standard ones so definitely not as easy).  I do like the lightbulb over the sun icon.  I'd go with it as the easier solution at this point.

I've pushed this change to the dev branch and test site. 

I've also now pushed another change to increase the contrast (Wave seems happy now).

On 11/4/22 6:52 PM, Dave Page wrote:

> Here's a patch that implements the manual switching and contrast changes.
>
> The light-mode-only issue for users without JS still needs to be
> resolved (if we actually care).

Thanks for pulling this together. A few comments:

1. Should we apply the lightened text to all font, not just the top nav
links? I do think it is easier to read.

2. There is an inline script that sets the toggle -- we should move that
into a JS file. We had move all of our inline scripts in JS files for
the CSPs.

3. Looking at examples of toggle buttons, the most icon common pattern is:

Light - sun
Dark - moon
(System - computer)

Additionally, it will display the icon of the mode you are currently in.
I'd suggest we currently follow that convention.

I may be able to take a crack at this later in the week + pending
consensus on the above.

On 1/4/23 5:18 AM, Dave Page wrote:
> FYI, I will commit this tomorrow, unless any more issues are raised.

I do have a few issues.

> On Tue, 13 Dec 2022 at 11:17, Dave Page <dpage@pgadmin.org
> <mailto:dpage@pgadmin.org>> wrote:
>
>
>
>     On Mon, 12 Dec 2022 at 17:48, Jonathan S. Katz <jkatz@postgresql.org
>     <mailto:jkatz@postgresql.org>> wrote:
>
>         On 11/4/22 6:52 PM, Dave Page wrote:
>
>          > Here's a patch that implements the manual switching and
>         contrast changes.
>          >
>          > The light-mode-only issue for users without JS still needs to be
>          > resolved (if we actually care).
>
>         Thanks for pulling this together. A few comments:
>
>         1. Should we apply the lightened text to all font, not just the
>         top nav
>         links? I do think it is easier to read.
>
>
>     I'm not sure what you mean - maybe the Fontawesome icons? The
>     lightened text is defined in --a-fg-color, which does apply to all
>     links. The rest of the text is off-white.

Any of the blue text. Let's take the homepage for example, The <h2> tags
use #2b6da3 whereas the links are now #699eca. I think we should be
consistent.

>         2. There is an inline script that sets the toggle -- we should
>         move that
>         into a JS file. We had move all of our inline scripts in JS
>         files for
>         the CSPs.
>
>
>     That's intentional. If it's in a separate file you can get a "flash"
>     of colour change during page load as it can cause the code that
>     changes the theme to what was selected previously to run post-render.

I think this may cause some CSP issues, but we can "see what happens".

>
>         3. Looking at examples of toggle buttons, the most icon common
>         pattern is:
>
>         Light - sun
>         Dark - moon
>         (System - computer)
>
>         Additionally, it will display the icon of the mode you are
>         currently in.
>         I'd suggest we currently follow that convention.
>
>
>     As David noted upthread, the issue is that the sun icon looks
>     confusingly similar to a settings cog icon, which I can certainly
>     see. I think the lightbulb is clearer, and just as obvious as to its
>     purpose. I'm fine with not following convention, when the convention
>     is sub-optimal (and note that the yum, zypp, and pgcac sites all use
>     the lightbulb now). I'm not going to fight over it though - I'd
>     rather get this committed ASAP given that the entire patch is driven
>     by user feedback.

I don't buy the argument that "because these sites in the PG family use
it we should use it here", but I'm not going to die on the hill on it.
So I'll +0 it.

However,  we should show the icon of the mode you're currently in (e.g.
show the moon while you're in dark mode). That is a very common pattern
on the web.

However, I'll +1 the application of the patch, with noted +0s above.

I just noticed that dark mode does not play well with the table heading
in this page
https://www.postgresql.org/support/versioning/

It is pretty much illegible, because of the font remaining white(ish).

> On 3 Jul 2023, at 17:15, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>
> On 2023-Jul-03, Euler Taveira wrote:
>
>> I don't know what Alvaro's OS is but I see the white background that he described.
>
> Yep, this is exactly what I see.  I'm running ungoogled-chromium:
>
>  Versión 114.0.5735.198 (Official Build, ungoogled-chromium) (64 bits)

It shows up in Firefox, Safari and Chrome for me, the issue is that the thead
element still has class thead-light even after switching to dark mode:

<thead class="thead-light">
    <tr>
      <th>Version</th>
      <th>Current minor</th>
      <th>Supported</th>
      <th>First Release</th>
      <th>Final Release</th>
    </tr>
  </thead>

Manually editing it to thead-dark gives the expected result, but I haven't
looked at the code to see why it isn't switched automatically.