1625036 - Don't use UA sheet text color when background-color is set to transparent for buttons/inputs

Status: VERIFIED FIXED

(Core :: CSS Parsing and Computation, defect)

Description

[Tim Nguyen :ntim]

Attachment: Screenshot of bug

STR:

1. Enable forced colors mode in Firefox, set background to black and text color to white in prefs
2. Make sure -moz-FieldText is black w/ your platform settings
3. Visit data:text/html,hello<input type="text" style="background: transparent; color: inherit" value="world">

AR:
input is black text on black background

ER:
input is white text on black background

This is because while the input honors background: transparent, the color is still forced to -moz-FieldText, which is black here. A reasonable fix would probably be using the browser.display.foreground_color color instead of -moz-FieldText.

Comment 1

[Tim Nguyen :ntim]

Attachment: screenshot of bug in about:config

This seems to affect about:config reset buttons (the ones with a border and no background) too.

emilio, do you know how hard is it to fix this ?

I can see the behaviour is being defined here:
https://searchfox.org/mozilla-central/rev/4d9cd186767978a99dafe77eb536a9525980e118/servo/components/style/properties/cascade.rs#383-392,406

Not sure how to tell revert to use the browser.display.foreground_color instead of the UA sheet color only when the background color is set to transparent though.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

This is not quite trivial to fix. Because you can't know the background of your ancestors (or your background for that matter) at that point.

You shouldn't use revert for this, if you'd want to fix it. You can force to use the default color, but that would break other stuff.

How common is it to use transparent backgrounds for inputs / other form controls?

We could always revert backgrounds I think... honoring background: transparent was necessary when what we did was overriding with the default background color, but shouldn't be the case anymore with revert.

Comment 3

[Tim Nguyen :ntim]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #2)

You shouldn't use revert for this, if you'd want to fix it. You can force to use the default color, but that would break other stuff.

How common is it to use transparent backgrounds for inputs / other form controls?

It's quite common for buttons to do this, especially icon buttons on websites nowadays.

We could always revert backgrounds I think... honoring background: transparent was necessary when what we did was overriding with the default background color, but shouldn't be the case anymore with revert.

What about honouring color: inherit instead ? I do think honoring background: transparent is still a good idea, because some elements can be sized in a way where they don't expect the background-color to be anything else other than transparent, so forcing a background-color on them may look odd.

Comment 4

[Tim Nguyen :ntim]

FWIW, I'm trying a combination of background: transparent and color: inherit on the video control icons for bug 1022553 and they're bitten by this bug, due to those icons being buttons.

Comment 5

[Emilio Cobos Álvarez (:emilio)]

(In reply to Tim Nguyen :ntim from comment #3)

What about honouring color: inherit instead ? I do think honoring background: transparent is still a good idea, because some elements can be sized in a way where they don't expect the background-color to be anything else other than transparent, so forcing a background-color on them may look odd.

Like which elements? Can you put an example?

Honoring only color: inherit can cause lack of contrast in other situations... I'd prefer if we stuck as closely as possible to what the color adjust spec does.

Comment 6

[Tim Nguyen :ntim]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #5)

(In reply to Tim Nguyen :ntim from comment #3)

What about honouring color: inherit instead ? I do think honoring background: transparent is still a good idea, because some elements can be sized in a way where they don't expect the background-color to be anything else other than transparent, so forcing a background-color on them may look odd.

Like which elements? Can you put an example?

https://edition.cnn.com/ is an example, adding a background behind the search and menu icons doesn't look very good.

It's also a common practice on the web to use Fitts' Law by providing a bigger click area than they appear on buttons, the browser back button is an example, if you hover over the top left corner of the navbar (even outside of the back button circle), the button is hovered.

I've also implemented this on my bugzilla board (hover over the edit/delete icons on each card), but there are also lots of web dev blog posts about clickable area and Fitts' Law.

Comment 7

[Tim Nguyen :ntim]

Attachment: Bugzilla header with `button { background: revert !important }`

Bugzilla looks pretty wrong too, when you force background: revert;, the mozilla logo lacks contrast, and the notification and profile buttons have an out of place background color. These aren't issues when background: transparent is preserved.

Comment 8

[Emilio Cobos Álvarez (:emilio)]

With my proposed change both bugzilla and that cnn page look fine, both in the light and dark high-contrast gtk theme (well, in the light one the mozilla logo looks white-on-white, but that's a pre-existing issue).

Comment 9

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1625036 - Tweak background: transparent handling so that color: transparent doesn't override UA sheet backgrounds. r=ntim

Comment 10

[Emilio Cobos Álvarez (:emilio)]

Note that those light backgrounds are themed, and with the default theme they're dark.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/360f09e5abbd
Tweak background: transparent handling so that color: transparent doesn't override UA sheet backgrounds. r=morgan

Comment 12

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/mozilla-central/rev/360f09e5abbd

Comment 13

[Cristian Fogel [:cfogel]]

With some additional info from :ntim we managed to verify the fix with 76.0b7 on macOS and Windows 10 and 77.0a1(2020.04.23) on macOS 10.15.3.