Bug 207875 - color collision: please provide option for smart color fallback (KDE-major)
Summary: color collision: please provide option for smart color fallback (KDE-major)
Status: RESOLVED DUPLICATE of bug 47320
Alias: None
Product: konqueror
Classification: Applications
Component: general (show other bugs)
Version: 4.3.0
Platform: openSUSE Unspecified
: NOR wishlist
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-09-19 12:46 UTC by Maciej Pilichowski
Modified: 2009-09-19 22:48 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Maciej Pilichowski 2009-09-19 12:46:46 UTC
Version:            (using KDE 4.3.0)
Installed from:    SuSE RPMs

STORY:
KDE offers several color schemes, and while dark-on-light work pretty well, the opposite does not work in Konqueror and thus it undermines whole KDE experience (because user is forced to get back to dark-on-light, despite the fact it is less healthy). Don't get me wrong, it is not Konqueror fault, but web pages -- when author sets 90% of colors, and forget about "obvious" 10%. In effect we get color collision.

Just an example:
http://forum.suse.pl/index.php?action=search

In the middle of the screen there is search edit box. With light-on-dark scheme (valid in KDE) you will get black text on dark background. Impossible to use.

The results is KDE suffers from Konqueror which suffers from poor web pages.


SOLUTIONS:
a) wishful thinking -- all authors will not forget to either define 0 colors, all define all of them

b) Konqueror would provide fallback mechanism in case of color colision

WISH (and suggestion):
ad.b) with such option enabled Konqueror would check distance for HSV (each part separately) between background color and text color. If any part (H,S,V) is too close (some sane value by default, 40?, but configurable by user too) the text color (*) is altered:

if (abs(text_color(X)-background_color(X))<color_collision_distance)
  text_color(X) = 255-background_color(X);

Where X is H, S or V

(*) text, because from my experience I can say text color is usually forgotten by web page authors
Comment 1 Maciej Pilichowski 2009-09-19 18:39:35 UTC
Another option would be nice -- ignore (completely) color defined in HTML or/and CSS and whatever. This means for link use KDE link color, for text KDE text, and so on.
Comment 2 FiNeX 2009-09-19 21:16:59 UTC
The root problem is bug #47320.

Fixing that bug will fix this bug too. Anyway I'm adding this specific consideration to bug #47320.

Thanks Maciej.

*** This bug has been marked as a duplicate of bug 47320 ***
Comment 3 Maciej Pilichowski 2009-09-19 22:48:52 UTC
Yes, and no -- what can you do when author will set text color to light gray and background color to dark gray? So colors _are_ set but they are abusing a11y.

Color collision detection is useful aid no matter of other bugs, so I am not 100% sure it is duplicate, but is is strongly related (or IOW solving the other bug, does not add color collision).