Re: Dark mode styling for the website

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.

--
Dave Page
Blog: https://pgsnake.blogspot.com
Twitter: @pgsnake

EDB: https://www.enterprisedb.com

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.

Thanks,

Jonathan

Hi

On Mon, 10 Oct 2022 at 21:44, Jonathan S. Katz <jkatz(at)postgresql(dot)org> wrote:

> 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.

No rush.

>
> 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.

I believe that is what most (all?) of them are doing.

> --
--
Dave Page
https://pgsnake.blogspot.com

EDB Postgres
https://www.enterprisedb.com

On 10/10/22 5:46 PM, Dave Page wrote:

> 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.
>
>
> I believe that is what most (all?) of them are doing.

Yes, looking at it closer, it does appear to be that way. I still think
we should try to do it without the "!important" if at all possible. We
have had some strange bugs or trouble editing things as is.

That said, I'll try to test in the coming days and see if I have
additional comments. I do prefer to run my personal setup in dark mode,
so I'm happy to test :)

Thanks,

Jonathan

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.
--
Vik Fearing

On Wed, 12 Oct 2022 at 02:58, Vik Fearing <vik(at)postgresfriends(dot)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).

--
Dave Page
Blog: https://pgsnake.blogspot.com
Twitter: @pgsnake

EDB: https://www.enterprisedb.com

On Wed, 12 Oct 2022 at 16:04, Dave Page <dpage(at)pgadmin(dot)org> wrote:

>
>
> On Wed, 12 Oct 2022 at 02:58, Vik Fearing <vik(at)postgresfriends(dot)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

One minor change since the last patch: FontAwesome icons are now shown in
the same off-white as the text, rather than pure white.

--
Dave Page
Blog: https://pgsnake.blogspot.com
Twitter: @pgsnake

EDB: https://www.enterprisedb.com

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.

depesz

Hi

On Thu, 13 Oct 2022 at 13:10, hubert depesz lubaczewski <depesz(at)depesz(dot)com>
wrote:

> 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,
>

Absolutely.

> 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.
>

How is it now?

Thanks!

--
Dave Page
Blog: https://pgsnake.blogspot.com
Twitter: @pgsnake

EDB: https://www.enterprisedb.com

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?

depesz

On Thu, 13 Oct 2022 at 14:01, hubert depesz lubaczewski <depesz(at)depesz(dot)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?

This patch is not about changing the content though.

--
Dave Page
Blog: https://pgsnake.blogspot.com
Twitter: @pgsnake

EDB: https://www.enterprisedb.com

On Thu, 13 Oct 2022 at 14:06, Dave Page <dpage(at)pgadmin(dot)org> wrote:

>
>
> On Thu, 13 Oct 2022 at 14:01, hubert depesz lubaczewski <depesz(at)depesz(dot)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?
>

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.

--
Dave Page
Blog: https://pgsnake.blogspot.com
Twitter: @pgsnake

EDB: https://www.enterprisedb.com

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...

depesz

On Thu, 13 Oct 2022 at 15:14, hubert depesz lubaczewski <depesz(at)depesz(dot)com>
wrote:

> 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...
>

Oops, fixed.

--
Dave Page
Blog: https://pgsnake.blogspot.com
Twitter: @pgsnake

EDB: https://www.enterprisedb.com

On Thu, 13 Oct 2022 at 12:46, Dave Page <dpage(at)pgadmin(dot)org> wrote:

>
>
> On Wed, 12 Oct 2022 at 16:04, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>
>>
>>
>> On Wed, 12 Oct 2022 at 02:58, Vik Fearing <vik(at)postgresfriends(dot)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
>

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

--
Dave Page
Blog: https://pgsnake.blogspot.com
Twitter: @pgsnake

EDB: https://www.enterprisedb.com

On Thu, 13 Oct 2022 at 15:45, Dave Page <dpage(at)pgadmin(dot)org> wrote:

>
>> 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
>
>
Here's the latest diff between my dev branch and the master branch.

--
Dave Page
Blog: https://pgsnake.blogspot.com
Twitter: @pgsnake

EDB: https://www.enterprisedb.com

On 10/18/22 7:14 AM, Dave Page wrote:
>
>
> On Thu, 13 Oct 2022 at 15:45, Dave Page <dpage(at)pgadmin(dot)org
> <mailto:dpage(at)pgadmin(dot)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".

Thanks,

Jonathan

Hi

On Tue, 18 Oct 2022 at 16:27, Jonathan S. Katz <jkatz(at)postgresql(dot)org> wrote:

> On 10/18/22 7:14 AM, Dave Page wrote:
> >
> >
> > On Thu, 13 Oct 2022 at 15:45, Dave Page <dpage(at)pgadmin(dot)org
> > <mailto:dpage(at)pgadmin(dot)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"
>

All seem good to me. I've pushed the changes to my dev branch and updated
the demo.

>
> 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".
>

Yes, I'm fine with that. I'd been a little concerned about that myself.

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.

--
Dave Page
Blog: https://pgsnake.blogspot.com
Twitter: @pgsnake

EDB: https://www.enterprisedb.com

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,

Jonathan

On Thu, 20 Oct 2022 at 02:08, Jonathan S. Katz <jkatz(at)postgresql(dot)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.

--
Dave Page
Blog: https://pgsnake.blogspot.com
Twitter: @pgsnake

EDB: https://www.enterprisedb.com

On Thu, 20 Oct 2022 at 09:40, Dave Page <dpage(at)pgadmin(dot)org> wrote:

>
>
> On Thu, 20 Oct 2022 at 02:08, Jonathan S. Katz <jkatz(at)postgresql(dot)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.

--
Dave Page
Blog: https://pgsnake.blogspot.com
Twitter: @pgsnake

EDB: https://www.enterprisedb.com

On 10/20/22 6:53 AM, Dave Page wrote:
>
>
> On Thu, 20 Oct 2022 at 09:40, Dave Page <dpage(at)pgadmin(dot)org
> <mailto:dpage(at)pgadmin(dot)org>> wrote:
>
>
>
> On Thu, 20 Oct 2022 at 02:08, Jonathan S. Katz <jkatz(at)postgresql(dot)org
> <mailto:jkatz(at)postgresql(dot)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

It looks amazing with the dark mode, awesome job.

> On 20 Oct 2022, at 12:54, Jonathan S. Katz <jkatz(at)postgresql(dot)org> wrote:
>
> On 10/20/22 6:53 AM, Dave Page wrote:
>> On Thu, 20 Oct 2022 at 09:40, Dave Page <dpage(at)pgadmin(dot)org <mailto:dpage(at)pgadmin(dot)org>> wrote:
>> On Thu, 20 Oct 2022 at 02:08, Jonathan S. Katz <jkatz(at)postgresql(dot)org
>> <mailto:jkatz(at)postgresql(dot)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
>

On Tue, Oct 25, 2022 at 7:03 AM Dago A Carralero <tocarralero(at)gmail(dot)com>
wrote:

> It looks amazing with the dark mode, awesome job.
>
> > On 20 Oct 2022, at 12:54, Jonathan S. Katz <jkatz(at)postgresql(dot)org> wrote:
> >
> > On 10/20/22 6:53 AM, Dave Page wrote:
> >> On Thu, 20 Oct 2022 at 09:40, Dave Page <dpage(at)pgadmin(dot)org <mailto:
> dpage(at)pgadmin(dot)org>> wrote:
> >> On Thu, 20 Oct 2022 at 02:08, Jonathan S. Katz <jkatz(at)postgresql(dot)org
> >> <mailto:jkatz(at)postgresql(dot)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
> >
>
>
So, Reddit peeps have noticed the change:

https://www.reddit.com/r/PostgreSQL/comments/ye4719/did_postgresqlorg_just_flip_to_dark_mode/

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).

David J.

Looks like it’s more work than actually I thought when i hacked my own dark styles. I will really like to help to tackle down those a11y issues. How could i do that ?

Also i think will be ideal for most people to setup a little widget for the color scheme setting:
• 💻 OS Default
• ☀️ Light
• 🌚 Dark

In the css could be approached by setting a color theme class on the html element.

For instance serve the docs with:
• <html class=“color-os”> & keep the styles as they are, :root { /* light vars */ } and @media (prefers-color-scheme: dark) { :root { /* dark vars */} }
Then after user selection:
• <html class=“color-light”> & set the styles: .color-light { /* light vars */}
• <html class=“color-dark”> & set the styles: .color-dark { /* dark vars */}

You can see a simple example of this setting on the MDN docs website.

> On 26 Oct 2022, at 20:03, David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
>
> On Tue, Oct 25, 2022 at 7:03 AM Dago A Carralero <tocarralero(at)gmail(dot)com> wrote:
> It looks amazing with the dark mode, awesome job.
>
> > On 20 Oct 2022, at 12:54, Jonathan S. Katz <jkatz(at)postgresql(dot)org> wrote:
> >
> > On 10/20/22 6:53 AM, Dave Page wrote:
> >> On Thu, 20 Oct 2022 at 09:40, Dave Page <dpage(at)pgadmin(dot)org <mailto:dpage(at)pgadmin(dot)org>> wrote:
> >> On Thu, 20 Oct 2022 at 02:08, Jonathan S. Katz <jkatz(at)postgresql(dot)org
> >> <mailto:jkatz(at)postgresql(dot)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
> >
>
>
> So, Reddit peeps have noticed the change:
>
> https://www.reddit.com/r/PostgreSQL/comments/ye4719/did_postgresqlorg_just_flip_to_dark_mode/
>
> 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).
>
> David J.

On Wed, 26 Oct 2022 at 20:03, David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)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.
The reason for that is that as far as I can tell, I would need to duplicate
the color vars for dark mode auto and dark mode manual in the CSS, and then
we'd have to keep them in sync forever. Specifically, we currently have:

media (prefers-color-scheme: dark) {
:root {
--a-fg-color: #2b6da3;
....
}
}

To toggle manually, I've changed that to:

[data-theme="dark"] {
--a-fg-color: #2b6da3;
...
}

I can't find any way to avoid that duplication, if we care about non-JS
users. Maybe someone cleverer than me knows a way?

There's also some ugly JS duplication, as apparently we have different base
templates for the docs and the rest of the site. I'd probably push the JS
into shared files in a more polished patch.

Code is at https://github.com/dpage/pgweb/tree/darkmode.

Thoughts/comments appreciated.

--
Dave Page
Blog: https://pgsnake.blogspot.com
Twitter: @pgsnake

EDB: https://www.enterprisedb.com

On Thu, Nov 3, 2022 at 7:19 AM Dave Page <dpage(at)pgadmin(dot)org> wrote:

>
>
> On Wed, 26 Oct 2022 at 20:03, David G. Johnston <
> david(dot)g(dot)johnston(at)gmail(dot)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.

Just some, possibly dated, thoughts (haven't done website work in a long
while).

David J.

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

> On Thu, Nov 3, 2022 at 7:19 AM Dave Page <dpage(at)pgadmin(dot)org> wrote:
>
>>
>>
>> On Wed, 26 Oct 2022 at 20:03, David G. Johnston <
>> david(dot)g(dot)johnston(at)gmail(dot)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.
>

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 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.
>

I'm not overly enthralled by that idea. It would require the server to
inspect every page request and return a different stylesheet if dark mode
is requested. That would immediately make caching less efficient, and it'd
be pretty ugly.

I've asked Vik to take a look for now anyway - hopefully he can see a
better way to avoid duplicating the colour definitions.

--
Dave Page
Blog: https://pgsnake.blogspot.com
Twitter: @pgsnake

EDB: https://www.enterprisedb.com

On Thu, Nov 3, 2022 at 8:04 AM Dave Page <dpage(at)pgadmin(dot)org> wrote:

>
>
> On Thu, 3 Nov 2022 at 10:40, David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>
> wrote:
>
>> On Thu, Nov 3, 2022 at 7:19 AM Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>
>>>
>>> On Wed, 26 Oct 2022 at 20:03, David G. Johnston <
>>> david(dot)g(dot)johnston(at)gmail(dot)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.

David J.

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

> On Thu, Nov 3, 2022 at 8:04 AM Dave Page <dpage(at)pgadmin(dot)org> wrote:
>
>>
>>
>> On Thu, 3 Nov 2022 at 10:40, David G. Johnston <
>> david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
>>
>>> On Thu, Nov 3, 2022 at 7:19 AM Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>>
>>>>
>>>> On Wed, 26 Oct 2022 at 20:03, David G. Johnston <
>>>> david(dot)g(dot)johnston(at)gmail(dot)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.

--
Dave Page
Blog: https://pgsnake.blogspot.com
Twitter: @pgsnake

EDB: https://www.enterprisedb.com

On Thu, 3 Nov 2022 at 13:28, Dave Page <dpage(at)pgadmin(dot)org> wrote:

>
>
> On Thu, 3 Nov 2022 at 11:09, David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>
> wrote:
>
>> On Thu, Nov 3, 2022 at 8:04 AM Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>
>>>
>>>
>>> On Thu, 3 Nov 2022 at 10:40, David G. Johnston <
>>> david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
>>>
>>>> On Thu, Nov 3, 2022 at 7:19 AM Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>>>
>>>>>
>>>>> On Wed, 26 Oct 2022 at 20:03, David G. Johnston <
>>>>> david(dot)g(dot)johnston(at)gmail(dot)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).

--
Dave Page
Blog: https://pgsnake.blogspot.com
Twitter: @pgsnake

EDB: https://www.enterprisedb.com

On Fri, Nov 4, 2022 at 11:47 AM Dave Page <dpage(at)pgadmin(dot)org> wrote:

>
>>>>>> 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).
>
>
Much better now, thank you. I may change my mind after using it for a bit
but it is a definite improvement over my reaction to the initial version.
I think my hesitation is just that it is different and thus takes a little
getting used to.

David J.

On Fri, 4 Nov 2022 at 14:46, Dave Page <dpage(at)pgadmin(dot)org> wrote:

>
>
> On Thu, 3 Nov 2022 at 13:28, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>
>>
>>
>> On Thu, 3 Nov 2022 at 11:09, David G. Johnston <
>> david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
>>
>>> On Thu, Nov 3, 2022 at 8:04 AM Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>>
>>>>
>>>>
>>>> On Thu, 3 Nov 2022 at 10:40, David G. Johnston <
>>>> david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
>>>>
>>>>> On Thu, Nov 3, 2022 at 7:19 AM Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>>>>
>>>>>>
>>>>>> On Wed, 26 Oct 2022 at 20:03, David G. Johnston <
>>>>>> david(dot)g(dot)johnston(at)gmail(dot)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).
>

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).

--
Dave Page
Blog: https://pgsnake.blogspot.com
Twitter: @pgsnake

EDB: https://www.enterprisedb.com

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.

Thanks,

Jonathan

On Mon, 12 Dec 2022 at 17:48, Jonathan S. Katz <jkatz(at)postgresql(dot)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.

>
> 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.

>
> 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 may be able to take a crack at this later in the week + pending
> consensus on the above.
>

Thanks.

--
Dave Page
Blog: https://pgsnake.blogspot.com
Twitter: @pgsnake

EDB: https://www.enterprisedb.com

FYI, I will commit this tomorrow, unless any more issues are raised.

On Tue, 13 Dec 2022 at 11:17, Dave Page <dpage(at)pgadmin(dot)org> wrote:

>
>
> On Mon, 12 Dec 2022 at 17:48, Jonathan S. Katz <jkatz(at)postgresql(dot)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.
>
>
>>
>> 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.
>
>
>>
>> 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 may be able to take a crack at this later in the week + pending
>> consensus on the above.
>>
>
> Thanks.
>
> --
> Dave Page
> Blog: https://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EDB: https://www.enterprisedb.com
>
>

--
Dave Page
Blog: https://pgsnake.blogspot.com
Twitter: @pgsnake

EDB: https://www.enterprisedb.com

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(at)pgadmin(dot)org
> <mailto:dpage(at)pgadmin(dot)org>> wrote:
>
>
>
> On Mon, 12 Dec 2022 at 17:48, Jonathan S. Katz <jkatz(at)postgresql(dot)org
> <mailto:jkatz(at)postgresql(dot)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.

Thanks,

Jonathan

On Thu, 5 Jan 2023 at 01:43, Jonathan S. Katz <jkatz(at)postgresql(dot)org> wrote:

> 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(at)pgadmin(dot)org
> > <mailto:dpage(at)pgadmin(dot)org>> wrote:
> >
> >
> >
> > On Mon, 12 Dec 2022 at 17:48, Jonathan S. Katz <jkatz(at)postgresql(dot)org
> > <mailto:jkatz(at)postgresql(dot)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.
>

OK, I'm confused. As far as I can see, they are both #699eca.
See --a-fg-color and --header-fg-color in
https://github.com/dpage/pgweb/blob/darkmode/media/css/main.css (yes, I
know the commit has today's date on it, but that's because I rebased).

>
> > 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.
>

Well you are arguing for consistency above :-)

>
> 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.
>

I think you might be confusing buttons with toggles here. Toggles show the
current state, so yes, most will show a moon icon or similar when you're in
dark mode and a sun when you're in light mode.

Icons on buttons are not the same though. They indicate what will happen
when you click the button; in this case, switch to the indicated mode.

Having a button icon that indicates the current state rather than the state
that will be shown if you click it goes against every example of related
design I can find. A good example is the Play button in Apple Music. It
will show the Play icon (the right-pointing solid triangle) when nothing is
playing, and changes to a pause icon (two vertical rectangles) when
something is playing.

--
Dave Page
Blog: https://pgsnake.blogspot.com
Twitter: @pgsnake

EDB: https://www.enterprisedb.com

On 1/5/23 5:21 AM, Dave Page wrote:
>
>
> On Thu, 5 Jan 2023 at 01:43, Jonathan S. Katz <jkatz(at)postgresql(dot)org
> <mailto:jkatz(at)postgresql(dot)org>> wrote:
>
> On 1/4/23 5:18 AM, Dave Page wrote:

> >     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.
>
>
> OK, I'm confused. As far as I can see, they are both #699eca.
> See --a-fg-color and --header-fg-color in
> https://github.com/dpage/pgweb/blob/darkmode/media/css/main.css
> <https://github.com/dpage/pgweb/blob/darkmode/media/css/main.css> (yes,
> I know the commit has today's date on it, but that's because I rebased).

I believe this was my repo getting out of sync. Per off-list delivery of
patch, this looks correct to me now.

>
> 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.
>
>
> I think you might be confusing buttons with toggles here. Toggles show
> the current state, so yes, most will show a moon icon or similar when
> you're in dark mode and a sun when you're in light mode.
>
> Icons on buttons are not the same though. They indicate what will happen
> when you click the button; in this case, switch to the indicated mode.
>
> Having a button icon that indicates the current state rather than the
> state that will be shown if you click it goes against every example of
> related design I can find. A good example is the Play button in Apple
> Music. It will show the Play icon (the right-pointing solid triangle)
> when nothing is playing, and changes to a pause icon (two vertical
> rectangles) when something is playing.

I understand this interface style. My comment was that around the web
for how people handled light/dark mode toggles, i.e. the trend was to
show the "current" state. There are of course sites that follow the
"music player" style interface as well.

I'll +0 this.

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

Thanks,

Jonathan

Hi

On Thu, 5 Jan 2023 at 14:59, Jonathan S. Katz <jkatz(at)postgresql(dot)org> wrote:

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

You were correct about the CSP issue; I could have sworn I had CSP in
enforcing mode on my test server, but apparently not (hence the commit &
revert on the main repo).

[For those wondering why we don't use a nonce instead, that wouldn't work
with our caching infrastructure].

Here's a minor update that resolves it. The inline JS in the header is
pushed out to a new file (because we need it to load in the header, to
avoid color flashing as much as possible), and the buttons onclick
attribute is replaced with an event handler. The inline CSS to hide the
form wrapping the button (for non-JS browsers) has been replaced with the
d-none class.

If you can give it a quick once-over, I'll get it committed and wrap this
up ASAP.

Thanks.

--
Dave Page
Blog: https://pgsnake.blogspot.com
Twitter: @pgsnake

EDB: https://www.enterprisedb.com

I just noticed that dark mode does not play well with the table heading
in this page
/support/versioning/

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

Thanks

--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"Ninguna manada de bestias tiene una voz tan horrible como la humana" (Orual)

Hi

On Tue, 27 Jun 2023 at 18:12, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
wrote:

> I just noticed that dark mode does not play well with the table heading
> in this page
> /support/versioning/
>
> It is pretty much illegible, because of the font remaining white(ish).
>

It looks fine to me on Safari, Chrome, and Firefox. What do you see?

[image: Screenshot 2023-07-03 at 09.55.05.png]

--
Dave Page
Blog: https://pgsnake.blogspot.com
Twitter: @pgsnake

EDB: https://www.enterprisedb.com

On Mon, Jul 3, 2023, at 5:57 AM, Dave Page wrote:
> On Tue, 27 Jun 2023 at 18:12, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
>> I just noticed that dark mode does not play well with the table heading
>> in this page
>> /support/versioning/
>>
>> It is pretty much illegible, because of the font remaining white(ish).
>
> It looks fine to me on Safari, Chrome, and Firefox. What do you see?

I don't know what Alvaro's OS is but I see the white background that he described.

$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 11 (bullseye)
Release: 11
Codename: bullseye
$ uname -a
Linux warrior 5.10.0-23-amd64 #1 SMP Debian 5.10.179-1 (2023-05-12) x86_64 GNU/Linux

Firefox 102.12.0esr
Google Chrome 114.0.5735.198

--
Euler Taveira
EDB https://www.enterprisedb.com/

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)

--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"Estoy de acuerdo contigo en que la verdad absoluta no existe...
El problema es que la mentira sí existe y tu estás mintiendo" (G. Lama)

> On 3 Jul 2023, at 17:15, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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.

--
Daniel Gustafsson

Hi

On Mon, 3 Jul 2023 at 16:29, Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:

> > On 3 Jul 2023, at 17:15, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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.
>

Lack of !important tags I think (which we're trying to avoid).

Removing the class entirely seems fine though. I've pushed a commit to do
that - there were a ton of places affected that I found once I managed to
reproduce the issue on Ubuntu. Figured it was better to get it out ASAP and
then quibble over better ways to do it than leave folks unable to read the
site.

Please re-check!

--
Dave Page
Blog: https://pgsnake.blogspot.com
Twitter: @pgsnake

EDB: https://www.enterprisedb.com

> On 4 Jul 2023, at 17:05, Dave Page <dpage(at)pgadmin(dot)org> wrote:

> Please re-check!

Tested and verified to work in Firefox, Safari, Chrome and Edge. Thanks!

--
Daniel Gustafsson

On 2023-Jul-04, Daniel Gustafsson wrote:

> > On 4 Jul 2023, at 17:05, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>
> > Please re-check!
>
> Tested and verified to work in Firefox, Safari, Chrome and Edge. Thanks!

Confirmed, it looks good to me too. Thanks for fixing it!

--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/