Last modified: 2014-02-07 19:40:22 UTC
In order ton make history reading easier, it will be cool (yep !) to mark contribs with colors. I'm trying to explain better :/ * in <font color="c080e0"><u>pink</u></font>, IP contributions * in <font color="red"><u>red</u></font>, sysop contributions (when they clicked on "revert", "rename" for example) * in <font color="green"><u>green</u></font> modifications made by user viewing history (hmm ... I want to say everyone should see his own modifications in a specific color, like green here). * and default colors for others modifications. Is it possible to add a little option in ''preferences'' to diplay or not colored histories ? Will be usefull for sysop ! And funny :) ...
Created attachment 5548 [details] First Try On Adding This Feature
Created attachment 5549 [details] Picture on how this looks
Hi There, this looks like a nice enhancement to me, improving overview in history view, so I made a patch for this. It changes the backgroundcolor of the line, according to the user who made the revision: Not logged in User -> White Some logged in User -> Yellow Currently logged in User -> Green Sysop -> Pink Of course, it uses CSS. Changes have been made to shared.css, so skins can override this. I tested it with various skins and it works fine. Image of the looks attached. Feedback appreciated.
Re-opening. WFM is for closing bugs about errors that no one can re-produce/don't seem to exist.
Adding the classes might be a good idea, but I don't think assigning default colors is necessary. I think that should be left up to individual sites or skin designers. Additionally, color combinations with the link+background text could potentially have accessibility issues for visually impaired users, especially things like red text on pink background, blue/green might have the same issue.
@#5 I orientated the default colors to the default colors in /skins/common/diff.css. I thought, "If they have default colors their, why shouldn't I use them, too"? Furthermore, can't the skin designers just override my colors with their own if they want to? I do totally agree with your critisicm about the bad color combination. I may think of a different color combinations, after we have clarified the "default colors"-issue. Futhermore, there is the question of how to document this color scheme to the user on the history page.
Created attachment 5559 [details] Second Revision of the Patch with no colors but borders used First thing I want to point out, that this patch would be a nice enhancement for the history view, because one would be able to check the involvement of sysops and registered user in changing a site with one glance. I have thought about the colorblindness-thing a lot more and don some research on the web about this issue and read a lot of stuff. I've done some checking with this tool: http://www.paciellogroup.com/resources/contrast-analyser.html which implements the Accessibility Guidelines of the WC3 http://www.w3.org/TR/2007/WD-WCAG20-TECHS-20070517/Overview.html My conclusion is, that there is no good color-scheme to be picked, matching the criteria of having a color in the background, that leaves the foreground text 100 % readable appart from plain white. Not even the "grey" (#F9F9F9) used at the moment in the background of the "Compare Selected Versions" Boxes is 100 % WC3 Contrast Ratio proof (Contrast Ratio against Red is 3,8:1 but should be 5:1). So i thought of a different solution using borders. 1. IP-User have just plain white background 2. Logged-In-Users have the same "grey" background as already used 3. SysOPs have "grey" background and a 1px solid border 4. The current logged-in user has a grey background and a 2px border (i want to see what i have done with this page)
Created attachment 5560 [details] Picture of how it looks with borders
The color solution and the border solution do not work as they should. A solution with dedicated icons runs into the problem that skin developers would have to do new icons for this. Could any skin developer please comment on this? If not, I guess it would be better to close this bug.
(In reply to comment #9) > The color solution and the border solution do not work as they should. A > solution with dedicated icons runs into the problem that skin developers would > have to do new icons for this. Could any skin developer please comment on this? > If not, I guess it would be better to close this bug. > There is a feature created by some wikipedians that I've added to my Monobook here : http://fr.wikipedia.org/wiki/Utilisateur:Liquid_2003/monobook.css A few days ago, there was icons too, from the Crystal Clear pack.
Comment on attachment 5559 [details] Second Revision of the Patch with no colors but borders used Thanks for submitting a patch to MediaWiki. Unfortunately I'm going to have to mark them as obsolete because they no longer merge into our current code. However I would like to touch on two things about the patch: 1. MediaWiki has a strict guideline on how code should be formatted. Mainly, single line if statements are highly discouraged as they aren't very readable. http://www.mediawiki.org/wiki/Manual:Coding_conventions 2. The following code is worrying User::newFromId($revUserId)->getGroups() Although it may not look like much it can possibly add a large amount of Queries to the page. You're loading up a user object which requires a separate database query for each revision. Ouch. If you were to re-implement this today you should look at creating a JOIN in the query to get user groups Thank you very much though for submitting this patch, any bit helps. =)
Changing to RESOLVED WONTFIX as this is issue is both stale and also sounds like all it would do is turn the history page into an assault on the senses.
