- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 04 Jul 2018 01:31:21 +0000
- To: public-css-archive@w3.org
The Working Group just discussed `color-filter`. <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: color-filter<br> <fantasai> github: https://github.com/w3c/csswg-drafts/issues/2875<br> <shane> Restaurant tonight is Long Chim<br> <fantasai> dino: Some background...<br> <fantasai> ScribeNick: fantasai<br> <shane> address for Long Chim: Corner of Pitt Street &, Angel Pl, Sydney NSW 2000<br> <fantasai> dino: Same way that Windows has done for decades, Apple's latest OS has a “dark theme”<br> <fantasai> dino: Where user has a checkbox where they can choose between light or dark mode<br> <fantasai> dino: You can see my browser is in dark mode atm<br> <fantasai> dino: System apps have implemented this<br> <fantasai> dino: Seems pretty popular<br> <fantasai> dino: This is about how you can apply something like that to the Web<br> <fantasai> dino: Particularly relevant to us for mail messages<br> <fantasai> dino: which are web pages<br> <fantasai> dino: What we wnated to do was automatically ocnvert a page to dark mode<br> <fantasai> dino: To do that, you want white to go to black, but you want hues to stay the same<br> <fantasai> dino: e.g. blue shouldn't become orange<br> <fantasai> dino: We had the idea to use color-filter<br> <fantasai> dino: This takes filters just like 'filter'<br> <fantasai> dino: But doesn't have ability to omove pixels<br> <fantasai> dino: It's a paint-time effect<br> <fantasai> chris: Is this a straight 255 minus effect?<br> <fantasai> dino: Yes<br> <fantasai> dino shows off invert()<br> <fantasai> dino: It's not like a regular filter. No stacking context. Just applies to colors<br> <fantasai> dino: colors of gradients, anywhere a <color> appears<br> <fantasai> dino: DOesn't affect images<br> <fantasai> dino: Because when you switch to dark theme, you don't want to have images invert<br> <fantasai> dino: or emoji colors to invert<br> <fantasai> etc.<br> <fantasai> dino: We don't actually wantto just invert the colors<br> <fantasai> dino: Here's an example - invert(0.83) hue-rotate(180deg) saturate(3)<br> <fantasai> dino: white goes to dark gray, bump saturation to compensate for grayishness, and then hue-rotate gets our colors back to what they would be without inversion<br> <fantasai> dino: Works nicely. Better on my laptop than on the projector here.<br> <fantasai> dino: This other column does some additional tweaks using JS, to look a little better.<br> <fantasai> dino: Anyway, this is what we're using to display mail messages now<br> <fantasai> dino: We have heuristics, if a marketing mail sets bgcolor, we won't do it<br> <fantasai> dino: but for plaintext or simple HTML messages, we'll apply the filter<br> <fantasai> dino: What we've got here is not Web-exposed, just in Mail<br> <fantasai> dino: We can talk more later about Media Queries and how to interact with the Web<br> <fantasai> dino: But a Web page could e.g. change colors manually in response to a media query, or they could use color-filter<br> <fantasai> dino: It's just maths on red/green/blue channels of the colors<br> <fantasai> dino: images are untouched<br> <fantasai> dino: No stacking context<br> <fantasai> dino: It's inherited, so you can undo it in a subtree<br> <fantasai> chris: Initial value?<br> <fantasai> dino: none<br> <fantasai> chris: You say not images, but some parts of CSS are <image>s...<br> <fantasai> dino: Gradients is a good example. If your bgimage is a gradient, you apply it to the coors in the image<br> <fantasai> leaverou: What about color variables?<br> <fantasai> fantasai: Gets applied when you apply the color<br> <fantasai> TabAtkins: But you don't want to double-apply for typed variables<br> <fantasai> ...<br> <leaverou> s/What about color variables?/What about custom properties that have been defined to accept <color>?/<br> <fantasai> xidorn: Is it applied during cascading or what?<br> <fantasai> emilio: Computed value is not affected<br> <fantasai> fantasai: used-value time operation<br> <fantasai> astearns: currentColor<br> <fantasai> fantasai: probalby fine<br> <fantasai> heycam: <canvas> ?<br> <fantasai> dino: Woudln't apply to canvas<br> <fantasai> dino: Currently implemented not for Web, in apps ike Mail etc.<br> <fantasai> dino: We think it makes sense for the Web<br> <fantasai> dino: as a way to help authors adjust page<br> <fantasai> leaverou: What about color modification functions?<br> <fantasai> TabAtkins: Amelia asked that already in the issue. I think having both is useful<br> <fantasai> leaverou: Are there uses other than dark themes?<br> <fantasai> dino, chris: high-contrast<br> <fantasai> dino: One of the greatest benefits we've found, before this people with vision issue sthat didn't like bright content would be constantly swapping between inverted/non-inverted mode<br> <fantasai> dino: And that's a screen-time effect<br> <fantasai> dino: And then we had to uninvert the images to make that useful for them<br> <fantasai> dino: And then also create all these stackign contexts, which aaffects the page<br> <fantasai> dino: So this is pretty nice.<br> <fantasai> dino: So this might be a nice forced option<br> <fantasai> dino: That the user could apply, e.g. "I want to see this web site dark"<br> <fantasai> leaverou: Does it also apply to colors in inline SVG?<br> <fantasai> dino: Yes<br> <dbaron> This seems like a reasonable feature, although I'm skeptical about the readability of the mail in the use case Dean described given the massive differences in perceived luminance between the R, G, and B channels. (e.g., blue on black is hard to read, as is green on white)<br> <fantasai> leaverou: Woudn't this be ...<br> <fantasai> leaverou: You can have bitmaps inside an SVG<br> <fantasai> leaverou: Seems like it would interact badly<br> <fantasai> dino: Could have a UA rule that sets it back to none<br> <fantasai> dino: We've mostly experimented with Mail. Haven't tried to apply to the Web yet<br> <fantasai> heycam: What if page wants to try handling it themselves?<br> <fantasai> dino: This is a complicated topic, wanted to deal later, but let's talk about it now<br> <fantasai> dino: If the browser is being told to apply dark mode automatically, what should we do?<br> <fantasai> dino: If there's a media query that allows the page to detect if the user wants dark mod<br> <fantasai> dino: Should the browser automatically flip th epage or not?<br> <fantasai> dino: It would be very odd for MQ to trigger behavior change<br> <fantasai> fantasai: We do have precedence<br> <fantasai> frremy: On Windows 8, if you resize an application to be in phone mode, we would scale the website down, except if it used @viewport<br> <fantasai> florian: That's not a media query. @viewport is *supposed* to have an effect on the page<br> <fantasai> florian: Opera did that for projection media type.<br> <tantek> similarly with full screen<br> <fantasai> dbaron: Been done before, but not a good idea. Poor API<br> <fantasai> dino: API I think that would provide it is also bad<br> <fantasai> dino: it's <meta viewport><br> <fantasai> ...<br> <fantasai> florian: MS has an alternative to that, it's a property<br> <fantasai> florian: can say "for this subtree, I've done it"<br> <fantasai> emilio: Could say color-filter: noe<br> <fantasai> florian: *If* the browser is doing this with color-filter and not some other mechanism<br> <fantasai> dino: So you'd set that property on the body<br> <fantasai> fantasai: Can we use html , not body?<br> <fantasai> heycam: Is this about high-contrast?<br> <fantasai> Rossen: yes<br> <fantasai> dino: The only thing I dn't like about that is it forces you to resolve style before you decide whta you've got to do<br> <fantasai> dino: meta tag doesn't have that problem<br> <fantasai> dino: but then can't exclude part of the page<br> <fantasai> Rossen: In practice, ppl tend to opt out of things like menus and ...<br> <fantasai> dino: So that's actually main reason we don't want to do it automatically<br> <tantek> what about where web devs have matched color related values with colors in images?<br> <fantasai> dino: form-controls look weird<br> <fantasai> s/form/built-in form/<br> <fantasai> dino: but ppl don't use built-in form controls that much, they use boostrap etc.<br> <tantek> Tab: WAT<br> <fantasai> TabAtkins: Uhhh,, no???<br> <fantasai> TabAtkins: The whole point is that built-in form controls work properly on.e.g. apple watch<br> <fantasai> florian: We've discussed similar model for auto-adjustment of colors for printing<br> <fantasai> florian: Where authro might want the browser to not make changes to the colors, because they already turned on colors and stuff<br> <fantasai> florian: “Browser has magic adjustments. I want to opt out on this part of the page.”<br> <fantasai> dino: It worries me a bit that including any style sheet could override this<br> <fantasai> florian: meta tag seems the wrong layer to do it<br> <fantasai> fantasai: That's true of viewport meta in general. SHould be in style sheet<br> <fantasai> dino: Suppose you include your favorite UI library. It supports dark mode.<br> <fantasai> dino: Should it put "I support dark mode" property on the html?<br> <fantasai> frremy: No, you set the property on the elements in your framework. Not on the whole page<br> <fantasai> dino: So bounding to a tree<br> <fantasai> florian: It's just a property. You *can* use it on <html>, but could apply only to components.<br> <fantasai> tantek: Did you talk about use case of matching colors in a JPEG?<br> <fantasai> dino: Could just set the filter to none<br> <fantasai> florian: Could use property to express two different things<br> <fantasai> florian: “Dear Browser, don't do it, because I've done it myself.” vs “Dear Browser, don't do it, because here it's not appropriate”<br> <fantasai> dino: So property is nice there, can say "Don't use on this color of red, because it has to match the red of these shoes" but rest of page is fine<br> <fantasai> heycam: Are we considering possibility of meechanisms other than color-filter() being set to handle these cases?<br> <fantasai> heycam: Because if not, then maybe we don't need a separate filter<br> <fantasai> dino: So far color-filter has been enough for us, but we've only been looking at mail<br> <fantasai> dino: Haven't tried browsing the web to see what happens on random content<br> <fantasai> astearns: It's the exceptions I'm worried about<br> <fantasai> astearns: In mail, generally the bg is set on the canvas<br> <fantasai> astearns: but on web pages could be arbitrary div<br> <fantasai> dino: We found a lot of messages that don't set a bgcolor<br> <astearns> s/canvas/body/<br> <fantasai> dino: but content sets bg the white<br> <fantasai> dino: that's why we couldn't layer mail over a gray application background<br> <fantasai> dino: had to put some smarts into analyzing the page<br> <fantasai> dino: If we can detect that the page wants a white background, because it's set some things to white...<br> <fantasai> dino: But so far color-filter has been enough<br> <fantasai> dino: Good news is implementation is quite easy<br> <fantasai> dino: Just at the point of where you're asking for the color value<br> <fantasai> dino: It's great, makes it easy to be a render-time effect<br> <fantasai> dino: math is pretty easy<br> <fantasai> dino: can also cache the values<br> <fantasai> heycam: Some properties to control the color space that we interpolate in<br> <fantasai> heycam: for animations and gradients<br> <fantasai> heycam: That would happen with origianl color values before transofrming them?<br> <fantasai> dino: Don't think there's case wher eyou d'want to change colors *and* change interpolation space<br> <fantasai> dino: No idea why red-blue gradient, why if you invert it you'd want it to be in linear-rg<br> <fantasai> rgb<br> <fantasai> dino: If you ask for gradient colors, you get filtered colors, and then interpolate like gradient said to<br> <astearns> s/wher eyou d'want/where you'd want/<br> <fantasai> dino: Of course could put property with a media query if you wanted<br> <fantasai> chris: So this modification happens last, just before rendering<br> <fantasai> dino: Right.<br> <fantasai> dino: Computed style is still the original color<br> <fantasai> dino: While we're talkign about this, maybe talk about MQ<br> <fantasai> dino: Our current one that we use internally, is prefers-dark-interface<br> <fantasai> dino: Think it's more prefers-dark-content<br> <fantasai> TabAtkins: prefers-dark<br> <fantasai> dino: Lines up with prefers-*<br> <fantasai> dino: User is requesting that they prefer this type of content<br> <fantasai> florian: I'm supportive of prefers-type MQs,<br> <fantasai> florian: Question is what is the other options?<br> <fantasai> florian: Can you express no preference in addition to expressing preference for light?<br> <fantasai> ...<br> <fantasai> dino: prefers-dark: light seems weird<br> <TabAtkins> `color-pref: goth | prep;`<br> <fantasai> fantasai: Just rename it to something else, e.g. prefers-colors: light | dark | any<br> <fantasai> ...<br> <fantasai> heycam: Say you have a site which is already dark, like DaringFireball, and you turn on the browser option "Please automatically make this dark for me"?<br> <fantasai> heycam: Are there options to keep it dark?<br> <fantasai> dino: I think we need to be careful to say that "Please make this dark for me" can't be a universial hammer<br> <fantasai> dino: It's hard to tell<br> <fantasai> dino: E.g. we try with scrollbarls, to try to guess whether page is light or dark and make scrollbars match<br> <fantasai> dino: Because DaringFireball sets bgcolor which is neither white nor back<br> <fantasai> dino: we probably wouldn't change anything<br> <fantasai> heycam: Is that a case where the author should indicate they already support dark?<br> <fantasai> dino: Question is, does anyone want to force bright?<br> <fantasai> dino: If you set bgcolor to hot pink, might say that you support dark and they'll get hot pink anyway<br> <fantasai> dino: Also for mail you'd get hot pink<br> <fantasai> dino: ...<br> <fantasai> florian: Do ppl anticipate forced-darkening of pages?<br> <fantasai> dino: There are a lot of users who seem to want that<br> <fantasai> dino: They've set up shortcuts to invert the page<br> <fantasai> dino: They toggle this on and off as they browse different pages<br> <fantasai> florian: If you have prefers-dark and forced-dark on at the same time, what does that mean?<br> <fantasai> dino: ...<br> <fantasai> dino: If the page says 'I did dark mode' then we wouldn't force it<br> <fantasai> dbaron: Did some experiments with this sort of color inversion maybe 8-10 yrs ago<br> <fantasai> dbaron: One problem I ran into in the end, and dino's example with mail was showing it, is that you can't actually do a good job of preserving both satuaration and lightness contrast at the same time<br> <fantasai> dbaron: because the contributions of red green and blue channels to luminance is very very different<br> <fantasai> dbaron: In the difference of white vs black, the luminance perception of that is 70% green 23% red and 7% blue or something like that<br> <fantasai> dbaron: which means that fully saturated blue is quite readable against white, but unreadable against black<br> <fantasai> dbaron: and fullysaturated green is quite readable against black and unreadable against white<br> <fantasai> dino: Which is why my third column was there, it bumped dark blues to lighter blues... blends a light-ish blue over every color ...<br> <fantasai> astearns: I expect as your designer looks at more and more pages, they would find additional tweaks they'd want to make to the filter<br> <fantasai> astearns: I can see the usefulness for this feature for browser UI<br> <fantasai> astearns: as something you can toggle, and you can flip it back if it isn't working<br> <fantasai> astearns: from a design perspective<br> <fantasai> astearns: I can't imagine someone wanting to tweak their colors with such a blunt hammer<br> <chris> for sTGB it is 21.26% red 71.52% green 7.22% blue<br> <fantasai> astearns: Create a light them and a dark theme as a designer, never going to be a filter that'll get you from one to the other<br> <chris> s/sTGB/sRGB/<br> <fantasai> astearns: So from UA perspective I see the usefulness<br> <fantasai> astearns: But from author perspective I can't see the use case<br> <chris> zakim, this meeting spans midnight<br> <Zakim> I don't understand 'this meeting spans midnight', chris<br> <chris> rrsagent, this meeting spans midnight<br> <RRSAgent> ok, chris; I will not start a new log at midnight<br> <astearns> s/see the use case/see the use case for the color-filter property/<br> <fantasai> Rossen: Thank you for demos and explanations, and that's a wrap for this issue.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2875#issuecomment-402336773 using your GitHub account
Received on Wednesday, 4 July 2018 01:31:26 UTC