Re: Dark mode styling for the website

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