[frontend] colorscheme redesign, some other small css tweaks

[f0x52]

Still kind of a work in progress, trying to pick a better color palette, and to document how those can be combined to maintain predictable contrast ratios.

Needs some more checking, especially with HTML/Markdown formatted posts I think

[tsmethurst]

Excited about this one 👀

[tsmethurst]

I had a read through! Looks good so far. Some things that come to mind:

With the new unexpanded status layout, what happens if someone has a really long display name? does it smush into the date? And what do unexpanded statuses with show more / show less buttons look like?

For color variable names, instead of white, gray, orange, and blue, perhaps they could be foreground, background, accent, and trim, or something like that? Then it'll be less confusing if someone wants to change their foreground color to black and background to white, etc. Whaddya think?

[f0x52]

With the new unexpanded status layout, what happens if someone has a really long display name? does it smush into the date? And what do unexpanded statuses with show more / show less buttons look like?

Needs a bit of a fix still, but we can cut off the displayname with an ellipsis. Was also thinking it might be nice to have a smaller date format (with relative times), so then it takes up less space too.

For color variable names, instead of white, gray, orange, and blue, perhaps they could be foreground, background, accent, and trim, or something like that? Then it'll be less confusing if someone wants to change their foreground color to black and background to white, etc. Whaddya think?

I'm considering adding a bit more proxy variables for that, we kind of already do, with colors, names for colors, specific locations that use those names.
so

$orange1: blah;
$accent: $orange1;
$avatar-border: $accent;

[tsmethurst]

it might be nice to have a smaller date format (with relative times), so then it takes up less space too.

I think relative time works better in clients than it does via a web UI, but we could definitely shorten the date format a bit in other ways (maybe just show like 10/09/22 - 13:36 or something?).

I'd say more proxy variables aren't necessarily required (though it's fine if so); imo the important thing is to just not name variables after certain colors, because it makes it more confusing when users/admins wanna write custom css in the future, if you get me

[f0x52]

I think relative time works better in clients than it does via a web UI, but we could definitely shorten the date format a bit in other ways (maybe just show like 10/09/22 - 13:36 or something?).
Yeah that'd help, maybe also shortening it to just the time if it's the same day?

I'd say more proxy variables aren't necessarily required (though it's fine if so); imo the important thing is to just not name variables after certain colors, because it makes it more confusing when users/admins wanna write custom css in the future, if you get me
Fair, that does make it easier/more logical to change a shade everywhere in one change

[tsmethurst]

Yeah that'd help, maybe also shortening it to just the time if it's the same day?

Sure :) That's a good idea

[f0x52]

This PR is kind of tangled with #812, so I'd rather get that merged first then adapt the discussion mentioned here in a new PR

[tsmethurst]

Alright, sounds good! 😊 Sent from ProtonMail mobile

…

-------- Original Message --------

On Sep 19, 2022, 6:31 PM, f0x52 wrote: This PR is kind of tangled with [#812](#812), so I'd rather get that merged first then adapt the discussion mentioned here in a new PR — Reply to this email directly, [view it on GitHub](#811 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AHT24I3NQKWRIYSVQGNMTHLV7CINHANCNFSM6AAAAAAQIGY3GA). You are receiving this because you commented.Message ID: ***@***.***>