Re: Dark mode styling for the website

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