- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 24 Apr 2019 16:34:37 +0000
- To: public-css-archive@w3.org
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`
<details><summary>The full IRC log of that discussion</summary>
<dael> Topic: Remove or expand inverted-colors<br>
<dael> github: https://github.com/w3c/csswg-drafts/issues/3858<br>
<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.<br>
<dael> florian: Becaue wording was ambig. there were questions if it triggered during a smart invert. Also expand to all things like night mode.<br>
<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<br>
<dael> dbaron: Is spec clear on what inversion means in this context?<br>
<dael> florian: Prob not. It's graphical operation that effects all pixels. It's not clear if it's different for every pixel<br>
<dael> dbaron: And if you want to correct images you need to know what inversion operation to do<br>
<dael> florian: Good point, should clarify. I don't know if there's multiple ways done in practice<br>
<dael> TabAtkins: 2 ways. Safari does fancy that doesn't invert images<br>
<dael> florian: Not that one. It's within the non-smart is there a hue rotate, inversion around gray point?<br>
<dael> TabAtkins: I think math is the same between everybody.<br>
<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<br>
<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<br>
<dael> florian: But if we conflait the 2 you get the wrong answer for a system<br>
<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.<br>
<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<br>
<dael> TabAtkins: Android has every single pixel inverts mode<br>
<dael> florian: OSX has that<br>
<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<br>
<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<br>
<dael> florian: Please invert images, please remove shadows?<br>
<dael> TabAtkins: Yes<br>
<dael> fantasai: It's a bit overkill<br>
<dael> TabAtkins: Agree. Removing is better<br>
<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.<br>
<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<br>
<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<br>
<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<br>
<dael> AmeliaBR: When talking 2 MQ is it 2 keyword values for inverted colors?<br>
<Rossen_> q?<br>
<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<br>
<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<br>
<dael> florian: Could, but easy to misuse.<br>
<dael> AmeliaBR: Up to the spec to be more specific about what things mean<br>
<dael> florian: I don't think can fix bad API design with good documentation<br>
<dael> TabAtkins: Most usable as 2. You can do mitegations on images for on MQ and color on the other.<br>
<dael> florian: Existing stays as is and add one for inverted images?<br>
<dael> fantasai: No, current is full screen inversion.<br>
<dael> TabAtkins: Defined as that but can change definition<br>
<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 (* )<br>
<dael> fantasai: Shipping now<br>
<AmeliaBR> q+<br>
<tantek> this is iOS 12.1 BTW<br>
<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<br>
<tantek> +1 to that<br>
<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.<br>
<dael> florian: Fair<br>
<Rossen_> ack dbaron<br>
<Zakim> dbaron, you wanted to bring up question of whether users expect this information to be exposed to web pages<br>
<tantek> q?<br>
<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<br>
<tantek> q+<br>
<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<br>
<Rossen_> ack AmeliaBR<br>
<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<br>
<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<br>
<florian> q?<br>
<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<br>
<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.<br>
<TabAtkins> https://github.com/w3c/csswg-drafts/issues/3807#issuecomment-481868265 Comment from Dean about history of Apple's inversion<br>
<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<br>
<dael> florian: If you're using CSS it wouldn't be a double invert.<br>
<dael> AmeliaBR: Would cascade cancel?<br>
<dael> smfr: Maybe your'e right. Not sure if it's CSs or programmatic. I think you're right<br>
<dael> florian: Should check<br>
<Rossen_> ack tantek<br>
<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.<br>
<tantek> https://drafts.csswg.org/mediaqueries-4/#priv-sec<br>
<fantasai> https://drafts.csswg.org/mediaqueries-5/ ?<br>
<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<br>
<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<br>
<chris> +1 to updating the S&P section<br>
<smfr> img:not(picture>img), picture, video { filter: invert(100%); } /* Images and videos double-inverted. */<br>
<smfr> }<br>
<florian> q+<br>
<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<br>
<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<br>
<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<br>
<dael> Rossen_: I see florian on the queue. I want to try and close on this.<br>
<Rossen_> ack florian<br>
<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.<br>
<dael> tantek: L5 needs to exist, L4 needs updated because it's not honestly reflective<br>
<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?<br>
<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<br>
<AmeliaBR> +1 to standardizing the UA rule<br>
<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.<br>
<dael> AmeliaBR: I'd suggest most UAs impl<br>
<dael> Rossen_: It's up to UAs to do it or not<br>
<fantasai> +1 to AmeliaBR<br>
<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<br>
<dael> AmeliaBR: Having a standard rule this is how you do it is more reliable<br>
<chris> +1 to AmeliaBR<br>
<florian> +1<br>
<dael> Rossen_: Would that need to include SVG?<br>
<dael> AmeliaBR: It would need to<br>
<dael> Rossen_: Prop: Leave inverted colors as is, add webkit UA stylesheet as an example implementation for MQ L5<br>
<dael> Rossen_: Additional comments or objections?<br>
<AmeliaBR> s/would need/wouldn't need/<br>
<dael> florian: I'm good with it as a normative addition to UA stylesheet<br>
<dael> Rossen_: 2 resolutions then<br>
<dael> TabAtkins: If you're going to fix images automatically you must do it via this CSS would be the second<br>
<dael> Rossen_: First is about the original issue which is no change to invert colors MQ. Objections?<br>
<dael> RESOLVED: Leave inverted colors as is, add webkit UA stylesheet as an example implementation for MQ L5 (no change)<br>
<dael> Rossen_: Second is Add inversion rule to the UA stylesheet. Objections to that?<br>
<dael> RESOLVED: Add inversion rule to the UA stylesheet<br>
<dael> Rossen_: Third is an ask to authors to revisit privacy and security section for L4 and L5<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3858#issuecomment-486321397 using your GitHub account
Received on Wednesday, 24 April 2019 16:34:39 UTC