thor
The only easy day was yesterday
My fault. I noticed when I changed the css that controls the colours used for the RAT colours (see node 492690) that the key didn't change to reflect my colours.
Because of the way the coloured boxes were generated it was non-trivial to apply the user css so I changed the code to apply the css to the forground of a character. For various reasons I chose to use a spade character, but that will likely change to a filled box later today.
Oh. I figured that we were on our way to adding some sort of character to designate various ages in addition to sizes, colors, etc.
-xdg
Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.
Because of the way the coloured boxes were generated it was non-trivial to apply the user cssLet me clarify: the problem is that the CSS specifies the text colour (AKA foreground colour), while the boxes originally depended on setting the background colour. AFAIK there's no way to tell CSS "swap foreground and background colour". Hence, in a next phase, a completely filled block character was chosen, as quite a few people weren't happy with the spades. It seems an equally important section of our population feels that way about the blocks.
Couldn't you just have it generate two ranges of CSS classes? One for forground and one for background? They could even share the same name just one has a.nnt-Steaming { color : #0000EE; } and the back ground is td.nnt-Steaming { background-color : #0000EE; } ... forgive the css errors if there are any. That region of CSS looks automaticaly generated, if so its just a matter of finding where its generated and making a minor addition.
That is/was one of the possibilities, but required a better understanding of the code and would require a larger change that was more prone to errors. For example, the code would have to accommodate a user that supplied the css in a different order or that used different capitilisation. Think "parsing HTML" and processing user input ("when you make it fool proof, they make better fools").
It could have been done that way (still can), but the road looked bumpier.
Hehe. Sorry last time i looked RAT just had the color blend setting where the intermediate colors where generated automagicaly (i assume). Even now though users could just know that they need to supply a a. and a td. class for each color they wanted to set. I think that then CSS could even be used to insert the char into the table cell (i'm thinking the way some of use insert symbols in front of other users names in the CB).
I don't see any need to parse users input at all, if they are over ridding the actual CSS then they need to get all the tags, and if they are using the color blend then the site generates the needed CSS. Am I missing something painfully obvious? ;)
Only that it would be a breaking change that requires users to generate the additional css, or would require PM to generate the css for them, in which case we are back to the same problem!
At the end of the day, it's a path that could have been followed, but wasn't. We will most likely add an option to the node 492690 page to allow the user to supply a character so that should make most people happy.
Ahh I didn't think about users who already had CSS. I think a little too much time is often spent saving people from 30 seconds of CSS updates. I mean this way is still broken for people who don't have unicode support for that char. No offense meant for the route you choose. It just feels like in general a lot of roadblocks are put up because people don't like change. ;)
----
I Go Back to Sleep, Now.
OGB
I rather agree (that's what I chose after all), but I think it doesn't have sufficient visual impact. Guess if I get a huge response to this we could make it a user selected character. :)
Yes. The spades didn't provide enough visual impact so we changed to using "█" (█) which is a filled box, but being a unicode character may not be rendered by all browsers on all systems. If you are seeing the number in a box I'd guess your browser/system combination don't render it. :(
There is a suggestion on the table that we allow a user selected character - that works around the problem. If there is a lot of support for the idea then I guess that will happen.
perlmonks.org content © perlmonks.org and bart, eric256, GrandFather, jpeg, Old_Gray_Bear, thor, xdg
prlmnks.org © 2006 edmund von der burg (eccles & toad)
v 0.03