Re: Dark mode styling for the website

From: Dave Page <dpage(at)pgadmin(dot)org>
To: Vik Fearing <vik(at)postgresfriends(dot)org>
Cc: PostgreSQL WWW <pgsql-www(at)lists(dot)postgresql(dot)org>, Dago A Carralero <tocarralero(at)gmail(dot)com>
Subject: Re: Dark mode styling for the website
Date: 2022-10-12 15:04:50
Message-ID: CA+OCxowgWL58k135VMYynTG0WEt89W3PnV6GhCChk3FtT8m4ow@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-www

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

Attachment Content-Type Size
pgweb_dark_mode_v2.diff application/octet-stream 27.6 KB

In response to

Responses

Browse pgsql-www by date

  From Date Subject
Next Message Bruce Momjian 2022-10-12 15:24:32 Re: Use proper en dash typography for ranges
Previous Message Daniel Gustafsson 2022-10-12 06:24:56 Re: Use proper en dash typography for ranges