Setting CSS color on buttons leads to unreadable text with a dark desktop theme
Categories
(Web Compatibility :: Site Reports, defect, P3)
Tracking
(Not tracked)
People
(Reporter: punx665, Unassigned)
References
()
Details
(Keywords: webcompat:contact-ready)
Attachments
(1 file)
222.79 KB,
image/png
|
Details |
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:61.0) Gecko/20100101 Firefox/61.0 Build ID: 20180807170231 Steps to reproduce: just use any dark GTK theme that uses dark buttons/entrys and bright/white text and then go to a site with HTML-forms. Actual results: black text on black buttons, entrys etc. Expected results: look at the screenshot Chrome use internal styling which avoids all those issues
Comment 1•6 years ago
|
||
The problem is caused by this CSS rule: input, textarea, button, select, optgroup, option { font: inherit; color: inherit; line-height: 1; margin: 0; vertical-align: middle; } at https://wiki.geany.org/lib/exe/css.php?t=vector&tseed=616329f3e3ec536e7b9bfd43175a447a line 7144 The inherited color value is apparently black. If they remove the color declaration then it should work - you'll get the theme's color instead. Or, they could also set the background, depending on what they want. It's generally considered a bug to set one of color/background but not the other since it leads to exactly this issue. I would strongly recommend to not try to style form controls *at all* since the default style is generally what the user expects.
Comment 2•6 years ago
|
||
Looking into why this is OK in Chrome: input { -webkit-appearance: textfield; background-color: white; -webkit-rtl-ordering: logical; cursor: text; padding: 1px; border-width: 2px; border-style: inset; border-color: initial; border-image: initial; } For us, we define background-color as -moz-Field: https://searchfox.org/mozilla-central/source/layout/style/res/forms.css#95 I see that Fennec decided to define that as #fff: https://searchfox.org/mozilla-central/source/mobile/android/app/mobile.js#460 Mats, should we consider something similar for desktop?
Comment 3•6 years ago
|
||
I don't think we should, no. It's inherently a bug in the author's CSS if they specify just one of color/background. They MUST always specify both (or neither) to avoid rendering white-on-white etc. I would strongly recommend that they don't style form controls *at all*. That's the best for the user since they are more recognizable as form controls when they have their default appearance. However, now that CSS supports querying for "dark mode" it should be a little easier for web sites to opt-in to the mode the user is using on their platform (once browsers implement this). https://drafts.csswg.org/mediaqueries-5/#prefers-color-scheme https://github.com/w3c/csswg-drafts/issues/2735 (Note that this means that authors should still *not* style form controls, but the author can now style *other* elements so that it matches a light/dark theme).
Comment 4•6 years ago
|
||
see Also Bug 1435665 There's an issue with the current color of Background color for buttons, which needs to be fixed.
Assignee | ||
Updated•5 years ago
|
Comment 5•4 years ago
|
||
You are welcome to contact them to fix it and you can point them to this discussion.
https://wiki.geany.org/users/enrico
Thanks.
Comment 6•2 years ago
|
||
Works for me, as I was not able to reproduce the issue:
Reporter, can you confirm please?
Tested with:
Browser / Version: Firefox Nightly 101.0a1 (2022-04-27) (64-bit)
Operating System: Windows 10 PRO x64
Comment 7•2 years ago
|
||
Redirect a needinfo that is pending on an inactive user to the triage owner.
:denschub, since the bug has recent activity, could you have a look please?
For more information, please visit auto_nag documentation.
Comment 8•2 years ago
|
||
I can't reproduce the issue either on my side, using Dark theme.
https://i.imgur.com/4Uwm7XO.png
Tested with:
Browser / Version: Firefox Nightly 103.0a1 (2022-06-01)
Operating System: Ubuntu 20.04.2
Dennis can we close this?
Comment 9•2 years ago
|
||
Description
•