Re: Dark mode styling for the website - Mailing list pgsql-www

From Dave Page
Subject Re: Dark mode styling for the website
Date
Msg-id CA+OCxow=xiNBaTqu3x+ED6g+cTfqp1fp1CjJSOFznKXcnxkEhw@mail.gmail.com
Whole thread Raw
In response to Re: Dark mode styling for the website  (Dave Page <dpage@pgadmin.org>)
Responses Re: Dark mode styling for the website
Re: Dark mode styling for the website
List pgsql-www


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

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

pgsql-www by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Use proper en dash typography for ranges
Next
From: hubert depesz lubaczewski
Date:
Subject: Re: Dark mode styling for the website