[mediaqueries-5] Remove or expand inverted-colors

[fantasai]

Splitting out from #3807.

inverted-colors proposal

@media (inverted-colors: none | inverted)

Supported in Safari; it's not clear whether "inverted" means all-pixels inversion, or color-inversion only, or what?

Important to distinguish these, as what authors do in response can vary based on which inversion is performed. (The img { filter: invert(100%); } rule in the spec's example, for instance, is only useful for all-pixel inversion; it would be harmful for a colors-only inversion.)

So, we either need to specify what kind of inversion is allowed to be performed, or add more values capturing the distinctions among the types.

[fantasai]

@grorg wrote in #3807 (comment) ...

@smfr wrote in #3807 (comment) ...

@media (inverted-colors: none | inverted) is about the screen-level color inversion accessibility feature (possibly with some re-inversion of images/video). It's a mode in which individual colors can't be independently adjusted; it's akin to a filter:invert() on the document.

To give a bit of history, this was originally offered as an accessibility feature and implemented at the system level - in that apps couldn't opt-out, and didn't even know it was happening unless they queried the system preferences (which I guess technically gave them a way to opt-out by pre-inverting things before they draw).

It was a popular feature, but the main complaint was that inverted images are wrong. So then came "smart invert", where everything was inverted except images and other media

Then we discovered that people would toggle this feature on and off depending on the page content. Basically they wanted either dark or light pages, and prefer to have their choice even if that meant the colours are all weird. So that's where we are today, and led to having a system preference for light/dark.

If the light/dark preference becomes widely adopted, we might not need the invert path any more.

[fantasai]

Since the behavior of inverted-colors varies wildly among implementations, and there is definitively no way for an author to react to it in a sensible manner, it seems that we should remove the feature.

If we are not removing the feature, then we need to split out these various behaviors into individual values so that authors know whether to rotate hues or double-invert images or whatever.

[frivoal]

The spec was already unambiguous that this media feature only applied when all pixels are inverted, not in some content-aware version of inversion. But unambiguous and obvious may not be the same thing, so I've rephrased it to be more obvious.

That doesn't mean we shouldn't discuss this, but the question is "what do we want", not "what does the spec say".

And I think what we want is what the spec says, because otherwise there's nothing useful an author can do with this media feature.

[AmeliaBR]

Copying over my comments from #3807 (comment):

I wonder if inverted-colors could be generalized as forced-filter, to also include "night light" effects that change the brightness and hue of the screen. e.g. @media (forced-filter: invert) vs @media (forced-filter: sepia) or just @media (forced-filter) to indicate that the user agent or OS is filtering the final rendered colors.

That would also avoid any confusion about how invert mode interacts with individual color values — it's a filter effect that applies to the full screen, although it is possible to revert the effect with opposite filters on individual elements. (I think this is how the Safari implementation works, with the "reverting invert" filters on images and videos now specified in the user style sheet. So specifying the same rule in an author stylesheet would have neither harm nor benefit. But someone who is familiar with the latest WebKit changes needs to confirm.)

The special cascade order rules for forced-color / -ms-high-contrast might also apply for forced-filter and other “forced” UA media manipulations. Whether this is necessary would depend on how many other user-agent style tweaks get added in those conditions. But for example, maybe I have an <img> that is a black line drawing on a white background and it should actually get inverted to white on black when the user has inverted the rest of the screen, so I want to use img { filter: none} to cancel out any user-agent stylesheet that double-inverts images.

(Note, that last comment is less relevant if forced-color overrides are done using revert instead of cascade trickery.)

[frivoal]

@AmeliaBR I don't think we should generalize. When the screen switches to warmer colors for night time, there is no expectation that the author will change something in response (nor, as far as I know, a demand from authors to be able to respond). I don't think we should generalize for the sake of generalizing.

For inverted colors, other need to respond to uninvert (or double invert, call it what you want), an to turn off the shadows-that-have-now-become-highlights, so that one does need a media feature.

But it's existence is driven by the need to react to it. Conceptually similar effects that don't need to be reacted to don't need to be exposed via MQs.

[css-meeting-bot]

The CSS Working Group just discussed Remove or expand inverted-colors, and agreed to the following:

• RESOLVED: Leave inverted colors as is, add webkit UA stylesheet as an example implementation for MQ L5 (no change)
• RESOLVED: Add inversion rule to the UA stylesheet

The full IRC log of that discussion

<dael> Topic: Remove or expand inverted-colors
<dael> github: https://github.com//issues/3858
<dael> florian: I think the initial issue was raised b/c wording wasn't clear. I've done an edit. It's supposed to trigger when entire screen is flipped pixel by pixel. Author needs to know to double invert images and the like.
<dael> florian: Becaue wording was ambig. there were questions if it triggered during a smart invert. Also expand to all things like night mode.
<dael> florian: My take is don't change. Full invert MQ is useful because there's a predictable way to react. A general 'your screen has been filtered somehow' doesn't have a strong way to respond so no use case. Having made the editorial correction I think close no change
<dael> dbaron: Is spec clear on what inversion means in this context?
<dael> florian: Prob not. It's graphical operation that effects all pixels. It's not clear if it's different for every pixel
<dael> dbaron: And if you want to correct images you need to know what inversion operation to do
<dael> florian: Good point, should clarify. I don't know if there's multiple ways done in practice
<dael> TabAtkins: 2 ways. Safari does fancy that doesn't invert images
<dael> florian: Not that one. It's within the non-smart is there a hue rotate, inversion around gray point?
<dael> TabAtkins: I think math is the same between everybody.
<dael> florian: Smart one doesn't match this. This is all the pixels have been flipped. If it's smart we don't need tor eact so don't need MQ
<dael> TabAtkins: Disagree with this. There are multiple mitigations for the page. Some apply across several diff types of inversion. If you do smart inversion page wants to still remove shadows. Having images not be inverted but the rest does means the pages with smart will not have their shadows with fixed
<dael> florian: But if we conflait the 2 you get the wrong answer for a system
<dael> TabAtkins: Yes. Given that inversion exists to flip light vs dark mode of the page and we have light/dark mode happening maybe we can assume inversion will decrease in use and drop the MQ.
<dael> florian: I suspect smart version will fade to dark/light mode. Does that apply to dumb which is easier for OSs? Those trying to be smart will be smart
<dael> TabAtkins: Android has every single pixel inverts mode
<dael> florian: OSX has that
<dael> TabAtkins: These MQ are for when an author should apply mitegrations. Either design around mitegrations themselves or don't do it at all. Doing around a feature that has multiple mitegations isn't a good designf or the future
<dael> TabAtkins: I propose that invert colors as current def is not good because limits to every px inverted. WE should either drop it completely and assume it's a corner case due to new functionality or we make it more complex and break it down by mitgations authors would apply
<dael> florian: Please invert images, please remove shadows?
<dael> TabAtkins: Yes
<dael> fantasai: It's a bit overkill
<dael> TabAtkins: Agree. Removing is better
<dael> fantasai: Design where you don't know what you're responding to doens't have purpose. Current def that you've inverted entire screen has usefulness. It's nice that we're moving toward place that people rec that inversion is to handle dark mode and they're doing smarter inversion is good.
<dael> fantasai: As long as full screen inversion does exist and it seems likely to continue to exist for a while...iOS isn't the only browser. THere are smaller devices that are doing what they're doing. We'll have to deal with full screen inversion for a while. MQ on that isn't unreasonable
<dael> Rossen_: Windows supports inverted and it's used quite a bit. I sympathize with TabAtkins that this one query that only covers one case isn't sufficient. Might consider adding to this so you can handle the smart invert iOS supports. I didn't hear if there's anything on Android. But there's 2 cases that capture everything. Full inversion or smart which is no image and control
<dael> TabAtkins: I expect we can get as far as we need by splitting into 2. Are images inverted and is everything else inverted? MS would respond yes to both, Safari yes to 1. That's all authors need to mitegate. Will images look weird and will the rest of the page look weird. WE should address those two directly
<dael> AmeliaBR: When talking 2 MQ is it 2 keyword values for inverted colors?
<Rossen_> q?
<dael> florian: I think it's 2 separate. Media features can be used without an argument and if you have multi keyword it's muddled
<dael> AmeliaBR: Disagree. Some miegations we want for both. Removing shadows is if inverting colors is true for any keyword. For keyword that specially indicates not images you can do something specific for images
<dael> florian: Could, but easy to misuse.
<dael> AmeliaBR: Up to the spec to be more specific about what things mean
<dael> florian: I don't think can fix bad API design with good documentation
<dael> TabAtkins: Most usable as 2. You can do mitegations on images for on MQ and color on the other.
<dael> florian: Existing stays as is and add one for inverted images?
<dael> fantasai: No, current is full screen inversion.
<dael> TabAtkins: Defined as that but can change definition
<tantek> Interesting, I just found the iOS setting in Settings > General > Accessibility > Display Accommodations > Invert Colors - then two mutex radio buttons: Smart Invert (* ), Classic Invert (* )
<dael> fantasai: Shipping now
<AmeliaBR> q+
<tantek> this is iOS 12.1 BTW
<dael> TabAtkins: iOS would start matching inverted color. I think they do now so no behavior change I believe. New query for inverted images would match android and edge but not iOS
<tantek> +1 to that
<dael> dbaron: I wanted to mention it's worth considering if users expect this information to be exposed. Not clear to me that they do or that a user choosing to use inversion would expect webpages to know. It's additional information to fingerprint and users might not want web pages to know about that.
<dael> florian: Fair
<Rossen_> ack dbaron
<Zakim> dbaron, you wanted to bring up question of whether users expect this information to be exposed to web pages
<tantek> q?
<dael> fantasai: I think we opened that door with all the other preferences like color-scheme and reduced-motion. Not sure this is a big diff in exposure
<tantek> q+
<dael> dbaron: Users are choosing or not to expose that information. THey can not expose if they prefer. I guess that's true here too. But those seem more like a preference. I guess it's OS level. It's just more bits of information
<Rossen_> ack AmeliaBR
<dael> AmeliaBR: To follow up dbaron point I agree with the general concern abotu fingerprinting and this is a a11y functionality. Less of a fingerprinting vector than others as it's something people toggle on and off. Worth talking about. Every MQ is a fingerprinting vector
<dael> AmeliaBR: It is exposed in iOS but it doesn't mean they looked into what users want. Esp since benefit of this MQ we can only come up with 2 rules that would make sense
<florian> q?
<dael> AmeliaBR: I went on queue to say that when talking about the 2 MQ option we have to start looking at that this has shipped in one UA. I'd like someone who is familiar with iOS to talk if they're on the call and how they impl smart inversion and if they currently rec. in the MQ when someone does a double inversion and if they're avoiding a triple inversion. I was thinking smart inversion came through CS mech
<dael> AmeliaBR: Through cascade it wouldn't hurt to have author rule, but maybe incorrect if it's from OS level compositor. Before we agree to 2 MQs lets talk to people using feature to see if nec.
<TabAtkins> https://github.com//issues/3807#issuecomment-481868265 Comment from Dean about history of Apple's inversion
<dael> smfr: As far as I understand, iOS and I think Mac is when the user toggles the a11y setting the entire screen is inverted and WK applies a CSS filter to image elements and likely others. It's possible an author could re-invert the images if they only looked at inverted colors MQ. NO smarts to avoid extra invert
<dael> florian: If you're using CSS it wouldn't be a double invert.
<dael> AmeliaBR: Would cascade cancel?
<dael> smfr: Maybe your'e right. Not sure if it's CSs or programmatic. I think you're right
<dael> florian: Should check
<Rossen_> ack tantek
<dael> tantek: COuple of things. First is I don't think we should use reasoning door is open to justify adding something. Always a false dicotomy. We do things on spectrum where it can be better or worse.
<tantek> https://drafts.csswg.org/mediaqueries-4/#priv-sec
<fantasai> https://drafts.csswg.org/mediaqueries-5/ ?
<dael> tantek: Looked at security and privacy of MQ draft and it's out of date for reflecting how MQ can be used for fingerprinting. Granularity of fingerprinting from MQ has greatly increased since L3. Needs a callout
<dael> tantek: If it's a CR and not a REC we should update. Since it's informating we should be able to edit during CR
<chris> +1 to updating the S&P section
<smfr> img:not(picture>img), picture, video { filter: invert(100%); } /* Images and videos double-inverted. */
<smfr> }
<florian> q+
<dael> tantek: Given potential negative aspects I would like to see some actual use cases where feature is a strong benefit to an author. What is the actual strong use case where an author needs this today. Otherwise not sure it meets bar to include it over potential drawbacks
<dael> TabAtkins: Inverting images is main thing. Images of real stuff looks horrifying when inverted naively. Removing shqadows is good, but not nec. If we can focus on if images are inverted or not that's highest value
<dael> Rossen_: Sounds like smfr found the UA stylesheet that supports that WK does this through CSS b/c author style sheet won't double invert it
<dael> Rossen_: I see florian on the queue. I want to try and close on this.
<Rossen_> ack florian
<dael> florian: Brief comment. TO tantek on privacy and security the one in L4 is outdated. THis feature is in L5 which doesn't even have a privacy and security so we need to create one.
<dael> tantek: L5 needs to exist, L4 needs updated because it's not honestly reflective
<dael> Rossen_: Back to topic at hand. We know what WK does. We know inverted colors on both android and windows apply to full screen. What do we do with this MQ. Leave as is? Bring additional query that's excluding images or something?
<dael> florian: Include the bit of UA stylesheet WK has so if authors want this they know exactly how so we don't fight with WK
<AmeliaBR> +1 to standardizing the UA rule
<dael> Rossen_: You prop leave the feature definition as is and add example of WK UA stylesheet of how they do inversions and how can be used to mitegate.
<dael> AmeliaBR: I'd suggest most UAs impl
<dael> Rossen_: It's up to UAs to do it or not
<fantasai> +1 to AmeliaBR
<dael> AmeliaBR: WE can standardize UA stylesheet and important we do. WK rule filters on picture elements, not images inside so if someone filters all images you get a double inversion
<dael> AmeliaBR: Having a standard rule this is how you do it is more reliable
<chris> +1 to AmeliaBR
<florian> +1
<dael> Rossen_: Would that need to include SVG?
<dael> AmeliaBR: It would need to
<dael> Rossen_: Prop: Leave inverted colors as is, add webkit UA stylesheet as an example implementation for MQ L5
<dael> Rossen_: Additional comments or objections?
<AmeliaBR> s/would need/wouldn't need/
<dael> florian: I'm good with it as a normative addition to UA stylesheet
<dael> Rossen_: 2 resolutions then
<dael> TabAtkins: If you're going to fix images automatically you must do it via this CSS would be the second
<dael> Rossen_: First is about the original issue which is no change to invert colors MQ. Objections?
<dael> RESOLVED: Leave inverted colors as is, add webkit UA stylesheet as an example implementation for MQ L5 (no change)
<dael> Rossen_: Second is Add inversion rule to the UA stylesheet. Objections to that?
<dael> RESOLVED: Add inversion rule to the UA stylesheet
<dael> Rossen_: Third is an ask to authors to revisit privacy and security section for L4 and L5