shout
shout copied to clipboard
Upgraded nick colors to use classes & IRC colors
Users with enabled nick colors might have noticed that the selected colors are not applied via CSS but instead with a 'style' added by JavaScript (handlebars).
This change uses the same hashing algorithm but instead of generating a color based off of the nickname string it returns a random number between 0 and 15 (or more accurately 2 and 13). Instead of applying the color via style it applies a class irc-fg$ where $ is the randomly generated number. (There are 16 colors, but I decided to not use the first two (white and black) or the last two (shades of gray) for readability).
These changes are meant to allow custom themes to be compatible with nickname colors where in the past some names would become illegible. They can now be styled with CSS (example near the bottom of GOOD.css - a theme I added as well)
The CSS method is better as it allows for customization.
@easymac, is this PR still relevant? While reviewing #583, I understood CSS classes were used, but maybe we are talking about 2 different things.
@astorije From what I can tell, they are related but disparate.
What I did here was use the IRC color palette for the colored nickname setting - it used to hash nicks into a random RGB triplet excluding colors that were too light to appear on white backgrounds.
That solution doesn't allow for custom themes with different colored backgrounds.
My solution was to hash the nick into an int between 0 and 15 (excluding the first few and last few for being greyscale) to represent the base IRC color palette. All of the colored nicks would use IRC colors defined by the stylesheet.
The PR you linked seems to simply handle an extended palette.
Truth be told, I can't remember what style sheet changes I had to make: if I recall correctly, I simply overrided the .irc-fg{N} and .irc-bg{N} classes in the theme.
I've probably over-explained what could be simply put as "No, that seems to expand the color palette and this just makes the colored nicknames use the base palette" but I'm on mobile and haven't looked carefully enough, so I'll allow you to judge.
Hey @easymac! I haven't looked at that part of the code yet, whether it's for your changes or for what #586 changes. That would be very helpful if @xPaw for opened #583, worked on #586 and therefore spent some time on that code (at least more than me :P), could give his thoughts on this PR. Thanks in advance!
This a good idea, IMO. Right now due to inlined colors, some css styles must have !important to override these colors, and it just gets messy. However this PR doesn't fully fix this issue as there are styles for .no-colors which introduce even more !important declarations.