(In reply to Emilio Cobos Álvarez (:emilio) from comment #10) > Background transparency affects (generally reduces) contrast tho, right? Anyways happy to defer to Morgan here, I don't particularly mind just removing that but... (In reply to Jonathan Kew [:jfkthame] from comment #8) > OK, thanks. My feeling is that if this interaction is desirable, it should be included in the spec, or else we probably shouldn't do it. But I'd be interested to hear what the Accessibility team has to say.... Morgan, any thoughts on this? Sorry for the slow reply, I was on PTO :) I'll bring this back to the team, but my 2 cents: Using prefers contrast as a proxy for reducing transparency is something both Windows and macOS do at the platform level. If you enable High Contrast Mode on windows Transparency Effects are turned off and disabled (the user cannot enable this option while HCM is on). On macOS, if you enable Increase Contrast, Reduce Transparency is turned on and disabled (the user cannot disable this option while Increase Contrast is on). It makes sense to me that, barring an explicit platform option on GTK, we use HCM as a proxy for reducing transparency. As emilio said, background transparency generally reduces contrast (a similar instance of this: our [backplating algorithm](https://searchfox.org/mozilla-central/rev/dcf50463d3e1e1f3a91bc1406e3772b2a5f62774/layout/generic/nsBlockFrame.cpp#229) traverses the ancestor chain of the frame tree in effort to compose an opaque background color, we don't use the first partially-transparent background we come across).
Bug 1844541 Comment 12 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Emilio Cobos Álvarez (:emilio) from comment #10) > Background transparency affects (generally reduces) contrast tho, right? Anyways happy to defer to Morgan here, I don't particularly mind just removing that but... (In reply to Jonathan Kew [:jfkthame] from comment #8) > OK, thanks. My feeling is that if this interaction is desirable, it should be included in the spec, or else we probably shouldn't do it. But I'd be interested to hear what the Accessibility team has to say.... Morgan, any thoughts on this? Sorry for the slow reply, I was on PTO :) I'll bring this back to the team, but my 2 cents: Using prefers contrast as a proxy for reducing transparency is something both Windows and macOS do at the platform level. If you enable High Contrast Mode on windows, Transparency Effects are turned off and disabled (the user cannot enable this option while HCM is on). On macOS, if you enable Increase Contrast, Reduce Transparency is turned on and disabled (the user cannot disable this option while Increase Contrast is on). It makes sense to me that, barring an explicit platform option on GTK, we use HCM as a proxy for reducing transparency. As emilio said, background transparency generally reduces contrast (a similar instance of this: our [backplating algorithm](https://searchfox.org/mozilla-central/rev/dcf50463d3e1e1f3a91bc1406e3772b2a5f62774/layout/generic/nsBlockFrame.cpp#229) traverses the ancestor chain of the frame tree in effort to compose an opaque background color, we don't use the first partially-transparent background we come across).
(In reply to Emilio Cobos Álvarez (:emilio) from comment #10) > Background transparency affects (generally reduces) contrast tho, right? Anyways happy to defer to Morgan here, I don't particularly mind just removing that but... (In reply to Jonathan Kew [:jfkthame] from comment #8) > OK, thanks. My feeling is that if this interaction is desirable, it should be included in the spec, or else we probably shouldn't do it. But I'd be interested to hear what the Accessibility team has to say.... Morgan, any thoughts on this? Sorry for the slow reply, I was on PTO :) I'll bring this back to the team, but my 2 cents: Using prefers contrast as a proxy for reducing transparency is something both Windows and macOS do at the platform level. If you enable High Contrast Mode on windows, Transparency Effects are turned off and disabled (the user cannot enable this option while HCM is on). On macOS, if you enable Increase Contrast, Reduce Transparency is turned on and disabled (the user cannot disable this option while Increase Contrast is on). It makes sense to me that, barring an explicit platform option on GTK, we use prefers-contrast as a proxy for reducing transparency. As emilio said, background transparency generally reduces contrast (a similar instance of this: our [backplating algorithm](https://searchfox.org/mozilla-central/rev/dcf50463d3e1e1f3a91bc1406e3772b2a5f62774/layout/generic/nsBlockFrame.cpp#229) traverses the ancestor chain of the frame tree in effort to compose an opaque background color, we don't use the first partially-transparent background we come across).