[Webkit-unassigned] [Bug 44862] Hard to find a caret in an editable element with black background color

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=44862





--- Comment #8 from Ryosuke Niwa <rniwa at webkit.org>  2010-09-01 08:54:07 PST ---
(In reply to comment #7)
> It seems to make sense that the caret color has to be black or white.
> In this case, we have to change the caret color to white in order to distinguish a caret in dark background.

Right.  Note that TextEdit always uses black for caret even when text is inside a table cell and its background color is black.  Since we usually match the editing behavior of WebKit to that of TextEdit, we may need to keep the current behavior for Mac.  However, that doesn't sound too user-friendly.

> What background color is proper for changing the caret color?

Not sure.

> I think that it would be good to use the lightness value of HSL color space in the Color class.

I think that's reasonable but it's probably better to match Internet Explorer's behavior because we don't want to force Web developers to having to test both on MSIE and WebKit in order to determine which color scheme results in white caret.  See http://support.microsoft.com/kb/84054 for example.  But It's best to test at least Web 256 colors.  Once we narrowed it down to some smaller range of colors, we can then test against the full 24-bit colors and see for which color MSIE produces black / white caret.

But this might be rather challenging when alpha value in background color is considered, or when some element is absolutely positioned and background color comes from element behind the element.  It's even more cumbersome when the element has position: fixed.  Or image the case where background color is white but has a very dark image. etc... See the bug 21680 for more discussions of this sort.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.