Bug 39956 – CSS: incorrect default text color for form elements

• Status: UNCONFIRMED
• Component: CSS

[Olivier Tilloy]

The default color for form elements defined in WebCore/css/html.css is incorrect in two places:

1) where defined as "color: initial", it should be "color: CaptionText" instead
2) where overridden as "color: black" (for keygen and select elements), it should be removed

Those changes will allow the various ports to implement widget styling respecting the system's theme, thus achieving a better consistency.

Note: the original discussion that lead to this bug report is at https://bugs.webkit.org/show_bug.cgi?id=37779. People who reviewed the original patch seem to agree it's correct, it needs testing against all the ports to make sure it doesn't break existing layout tests.

[Olivier Tilloy]

Created attachment 57469 [details]
A patch

This patch was split from the original patch attached to bug #37779, it contains only the changes to WebCore/css/html.css

[Darin Adler]

Comment on attachment 57469 [details]
A patch

A change that fixes a bug needs a test case, either automated or manual. Automated tests go into the LayoutTests directory, and manual tests into WebCore/manual-tests. I'm hoping there's a way to do an automated test of this.

Please re-submit the patch with a test in the patch.

[Peter Kasting]

I don't have the knowledge to give this thumbs-up or down off the top of my head.  I may have written RenderThemeChromiumWin::systemColor(), but that's an easy mechanical mapping of WebKit constants to Windows ones, and doesn't inform the question of what the original WebKit CSS setup should be.

[Shinichiro Hamaji]

(In reply to comment #3)
> I don't have the knowledge to give this thumbs-up or down off the top of my head.  I may have written RenderThemeChromiumWin::systemColor(), but that's an easy mechanical mapping of WebKit constants to Windows ones, and doesn't inform the question of what the original WebKit CSS setup should be.

Thanks for your comment. I have no idea how Windows' GetSysColor determines the color (maybe it uses system's theme?) and I've never worked on theme related issues. I CCed you because I guessed you could have some experience around themes.

[Shinichiro Hamaji]

I played on my Windows with the following HTML:

<select style="color:captiontext"><option>foo</select>
<select><option>foo</select>

It seemed my default theme's captiontext is black and there were no difference between this two <select>s at first. However, after I changed my color theme to "High Contrast Black", the "foo" in the former <select> has disappeared. I think we might need to change the background color of <select>.

Also, I think we should use different system colors for different elements. Specifically,

- It seems <button> families have already had color:ButtonText and background-color:ButtonFace . I guess you can fix button's issue by setting ButtonFace properly in RenderThemeGtk.cpp ?
- We should use color:menutext and background-color:menu for <select> and <keygen> .
- I'm not sure, but I guess we should not specify the color for <textarea>, <input>, and <isindex> .

[Olivier Tilloy]

Note regarding system colors (specification at http://www.w3.org/TR/CSS2/ui.html#system-colors): there is in the tree a layout test named fast/css/css2-system-color.html that was added on 2007-12-16 and disabled on 2007-12-17 ("until we can find a way to make it pass on diverse machines"). I'm not sure the issue with this test is still valid, I think it would be worth trying to enable it again.

[Alexey Proskuryakov]

See also: bug 23760. Should this be marked as a duplicate of the older one?

[Alexey Proskuryakov]

Also, please see bug 6129 and bug 13575.

[Olivier Tilloy]

As I understand it, bug #23760 is specific to Safari on windows (and should be marked as such, I suppose).
Bug #6129 and bug #13575 are specific to Safari on OS X.

All three bugs are about the implementation of the mapping between CSS constants and system colours (much like bug #40024 for the GTK port), while this bug is about wrong default values in the default CSS for some widgets. In practice, both types of bugs will influence the final rendering of widgets in forms though.

[Ahmad Saleem]

We still have both (which this patch was trying to modify):

https://searchfox.org/wubkat/source/Source/WebCore/css/html.css#412

input, textarea, select, button {
    margin: 0__qem;
#if !(defined(WTF_PLATFORM_IOS_FAMILY) && WTF_PLATFORM_IOS_FAMILY)
    font: -webkit-small-control;
#endif
    color: initial; <----------- here
    letter-spacing: normal;
    word-spacing: normal;
    line-height: normal;
    text-transform: none;
    text-indent: 0;
    text-shadow: none;
    display: inline-block;
    text-align: start;
}

and

https://searchfox.org/wubkat/source/Source/WebCore/css/html.css#1098

select {
    box-sizing: border-box;
    appearance: auto;
#if defined(WTF_PLATFORM_IOS_FAMILY) && WTF_PLATFORM_IOS_FAMILY
    letter-spacing: normal;
    word-spacing: normal;
    line-height: normal;
    padding: 0 0.4em 0 0.4em;
    color: -apple-system-blue;
    font: 11px system-ui;
    border: 1px solid -webkit-control-background;
    border-radius: initial;
#if defined(WTF_PLATFORM_VISION) && WTF_PLATFORM_VISION
    background-color: rgba(0, 0, 0, 0.04);
#else
    background-color: -apple-system-opaque-secondary-fill;
#endif /* defined(WTF_PLATFORM_VISION) && WTF_PLATFORM_VISION */
#else
    border-radius: 5px;
    border: 1px solid;
#if defined(HAVE_OS_DARK_MODE_SUPPORT) && HAVE_OS_DARK_MODE_SUPPORT
    color: CanvasText;
    background-color: Canvas;
#else
    color: black; <---------------- here
    background-color: white;
#endif /* defined(HAVE_OS_DARK_MODE_SUPPORT) && HAVE_OS_DARK_MODE_SUPPORT */
#endif
    align-items: center;
    white-space: pre;
    -webkit-rtl-ordering: logical;
    cursor: default;
}