Thanks for the response. I had assumed that, since my patch changes the color scheme long before anything else is, it would be okay. The pattern I noticed was this: if something was done (the background was changed) it was okay; if nothing was done, there was trouble (clashing colors). My patch does something, but I guess it was too naive. Lets keep working to make it smarter. In this particular case, I don't think attempting to fix broken pages will help much. Pages assume that you are using MSIE 6.0 with black text and a white background. Often times, there are html colors that are supposed to match pre-rendered gifs that have the same colors. If you go around mixing up colors, this creates weird and ugly pages. I'd also like to note that there are definite use cases for black-on-black text. If a site uses black-on-black text, it may be for a good reason and we don't want to deny this choice to our users. A good example is how on many forums, if information is spoilers for a tv show, book or movie, the information is placed in black on black text to make it less likely that someone will read it by accident. So we should assume that sites want black on white, but if a site specifically says it wants black on black, we should let it. As I mentioned, I can provide a check box so that users can choose not to have this feature. And I want to continue to work to make it more intellegent. Incidentally, do you have an example site that breaks my patch? BTW, to the person who provided a backtrace, I don't have the rights to see it on that site. Could you email it to me personally? Message: 10 Date: Fri, 27 Jun 2008 13:18:54 -0500 From: Matthew Woehlke Subject: Re: KHTML color scheme patch To: kde-devel@kde.org Message-ID: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Conor W Sullivan wrote: > Hi, where is the best place to discuss khtml issues? ?The following is a patch > to kdelibs/khtml/khtml_part.cpp which simply sets the part's color scheme as > being a generic black-on-white color scheme. ?This is because khtml often > works with webpages that conflict severly with dark color schemes. ?I can add a > system settings option to disable this is you like. IMO forcing the color palette to ignore user settings is a major step backwards (not to mention a huge u7y/a11y no-no). I would *much* rather see khtml be smart enough to detect brain-dead pages and fix them... not only for this issue, but to be honest, I'd like it to "fix" pages that intentionally try to obfuscate text by making it, say, black-on-black. KColorUtils::contrastRatio was created for exactly this sort of thing. A quick fix is, assuming you know the background color, replace the requested foreground color with KCU::tint(askedFG, ref) where "ref" is black if KCU::luma(background) > 0.5 and white otherwise. (Actually, I'd like to further see if the requested foreground is black and no background was requested i.e. we're using the default, ignore the foreground request and use the default foreground. Since this is how most pages screw up anyway...) -- Matthew >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<