- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 17 Apr 2019 17:01:30 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Holistic review/proposal of color-modifying things`, and agreed to the following:
* `RESOLVED: start a new Color Adjust draft`
* `RESOLVED: Add forced-colors MQ to MQ spec`
* `RESOLVED: Add forced-color-adjust property as an opt to into new spec`
<details><summary>The full IRC log of that discussion</summary>
<dael> Topic: Holistic review/proposal of color-modifying things<br>
<dael> github: https://github.com/w3c/csswg-drafts/issues/3807<br>
<dael> TabAtkins: fantasai and I have been watching with mild concern as various color modifying things have come about. Wanted to make sure they all corrdinated. Put together an issue that reviews all of it. For the most part people are doing same and that's good. Have a few suggestions that are minor<br>
<dael> TabAtkins: Dark mode- The spec Rune put together based on our plan which basically matches Safari is good except long names. Hvae suggested shorter names. preferred-color-scheme we wanted to call color-scheme. That's about it for dark mode.<br>
<fantasai> s/preferred/supported/<br>
<dael> TabAtkins: MS high contrast prop works pretty well<br>
<dael> TabAtkins: Set of system colors we support has a few with appropriate names. Outlined those in issue with additional color names if we want to give access to authors via MQ<br>
<dael> TabAtkins: If doing forced color scheme and bg is light or dark should also trigger light or dark mode MQ.<br>
<dael> TabAtkins: You can do things like remove shadows based on it being dark or whatnot<br>
<dael> TabAtkins: Question about inverted colors, but should discuss sep<br>
<dael> TabAtkins: Main thing. Suggestion of modified names<br>
<dael> TabAtkins: [missed...audio issues]<br>
<dino> 🎁+<br>
<dael> TabAtkins: Main thing is first this suggested shortened name for dark mode and meta tag. Only shipping impl is Safari b/c they shipped before a spec. No one else has shipped. So resolution if we change names or not.<br>
<dael> smfr: Reason we choose prefers; we need to make clear to authors this is user's preferred appearance for the page. Similar to preferred reduced motion MQ.<br>
<dael> TabAtkins: MQ is good. It's supported-color-scheme property and meta we want to rename.<br>
<fantasai> @media (prefers-color-scheme: light | dark | no-preference)<br>
<fantasai> color-scheme: only? && [light | dark | <custom-ident>]+<br>
<fantasai> <meta name=color-scheme content="(same values)"> sets initial value of 'color-scheme' on the root<br>
<fantasai> proposal ^<br>
<dael> dino: I was going to say MQ has been in MQ spec for a long time<br>
<dael> astearns: Given that, smfr is rename okay?<br>
<dael> AmeliaBR: It's drop 'supported' in 'supported-color-scheme'<br>
<fantasai> If we can change system colors to compute to themselves, then 'color-scheme' changes the used values of the system colors on the element. If not, 'color-scheme' on the root does so for the whole page. In either case, the affected system colors are at least the set defined for "high contrast".<br>
<dael> florian: But not for MQ?<br>
<fantasai> 'color-scheme' must also affect input & scrollbar styling.<br>
<dael> AmeliaBR: MQ keeps 'preferred'<br>
<dael> smfr: Think okay<br>
<fantasai> s/preferred/prefers/<br>
<dael> fremy: Wondering, on the issue color-scheme is written as a singular. Is that intentional?<br>
<dael> TabAtkins: Property names are always singular so we went with that.<br>
<dael> fremy: Okay, sounds good. If you thought about it I'm fine<br>
<dael> astearns: Other discussion on if we should have 'supports' in prop name?<br>
<dael> dino: Not changing values, jsut removing prefix?<br>
<dael> fantasai: We also fixed the grammar. Current allows light or dark or only keyword. Defined to parse and not throw out additional IDs.<br>
<dael> TabAtkins: As far as we know this matches what you intended<br>
<dael> smfr: Sounds fine<br>
<fantasai> Proposal is to rename supported-color-scheme to color-scheme<br>
<dael> dino: Reading in #3807 in light/dark color scheme proposal. That's what to look at?<br>
<dael> TabAtkins: Yeah<br>
<dael> dino: I think we're okay with that<br>
<dael> smfr: Allow only to be at end?<br>
<dael> TabAtkins: Either spot because it matches general CSS. only light and light only make sense<br>
<dael> astearns: Other questions about change from supported-color-scheme to color-scheme ?<br>
<fantasai> smfr, you can't do "light only dark"<br>
<fantasai> smfr, but "only light dark" and "light dark only" are fine<br>
<dael> Rossen_: Reviewing this prop it aligns closely with some internal work we did on this in terms of wordsmithing and aligning. Thanks for taking the time TabAtkins and fantasai. It aligns with how I hoped this would mash together and make sense of all the darks and lights. +1 and thank you<br>
<dael> astearns: Prop: Add the color-scheme property with updated grammar to a spec instead of supported-color-scheme<br>
<dael> TabAtkins: Yes. Not sure if there's an existing spec that fits. Maybe colors but I'm not sure. Either Colors or a new spec<br>
<dael> AmeliaBR: THis goes into larger discussion. Debated last week where adjust for forced colors goes. Maybe in same place as new color-scheme<br>
<dael> TabAtkins: Yes. High contrast stuff should be same place as light/dark. That should be either Color or a new spec<br>
<dael> florian: Feels coherent enough to be a sep spec and feels it will move faster<br>
<dael> fantasai: Discussion was appendix to MQ until we figure out where it goes<br>
<dael> AmeliaBR: Other property these are related to is appearance. It's turning on or off default UA styles. Not sure what spec that's in<br>
<dael> florian: That's CSS UI L4. It's a bit of a stretch but only a little one<br>
<dael> TabAtkins: Can we make a color adjust spec?<br>
<dael> fantasai: Sure<br>
<fantasai> s/make/just make/<br>
<dael> Rossen_: We can always have one more spec :)<br>
<fantasai> s/color adjust/color-adjust/<br>
<dael> astearns: Obj to start a new Color Adjust draft?<br>
<dael> RESOLVED: start a new Color Adjust draft<br>
<dael> astearns: Who will edit?<br>
<dael> TabAtkins: fantasai and I<br>
<dael> astearns: Who else<br>
<dael> Rossen_: Rune and I should put time on this and put our edits<br>
<dael> tantek: sgtm<br>
<dael> s/tantek/Tab<br>
<dael> astearns: I'm appointing Rune and Rossen as editors, TabAtkins and fantasai can provide feedback. Let's spread out editing<br>
<dael> Rossen_: Resolutions for MQs?<br>
<dael> astearns: Let's resolve on color scheme. Obj to Add the color-scheme property with updated grammar to Color Adjust spec instead of supported-color-scheme<br>
<dael> AmeliaBR: Meta tag too?<br>
<dael> astearns: Yes<br>
<dael> dbaron: I think I said what I didn't like last time we discussed this.<br>
<dael> florian: Don't think resolved<br>
<dael> dbaron: My concern is we have a set up where all pages on web work with light form controls. Many pages break with dark. On systems where browser can choose they tend to light.<br>
<dael> dbaron: This is designing around a few recent OS changes rather than say a general system them change a user has made. It's not clear to me this is impl across OS themes. It's a step forward and backward. All pages work with light, many broken in dark. this allows pages to say work with dark, but also allows broken in light and i"m not happy about that<br>
<dael> dbaron: Want to have a page say I'm happy with a dark theme. Not happy about page overriding user choice<br>
<dael> AmeliaBR: You okay taking this up in spec discussion? Sounds like you're concerned about the only keyword interacting with list of preferences. I'm not sure that blocks actual concept<br>
<dael> dbaron: Once there's a spec it will ship. WE need to discuss before<br>
<dael> fantasai: Well it shipped w/o a spec<br>
<fantasai> already<br>
<dael> astearns: Would concern be addressed if we did grammar such that you could not exclude supporting a light scheme?<br>
<dael> dbaron: I believe so. I'm not up on semantics of current proposal.<br>
<dael> TabAtkins: Ignoring future compat with other schemes. IT's saying I'm fine with light or dark or I'm only fine with light or only fine with dark. If at the moment 'only' works on light you can say I only do light or you can say I allow dark and if user wants that give it to me<br>
<dael> astearns: That does seem more widely implementable<br>
<dael> dbaron: I think that would help<br>
<dael> dbaron: Still some edge cases where we couldn't do that<br>
<dael> florian: Neither light nor dark systems?<br>
<dael> dbaron: Or we don't know. We can just draw a control.<br>
<dael> astearns: Another way addressing this is to have an implicit auto where there is a browser default that this prop cannot opt out of.<br>
<dael> astearns: If the color scheme is set to only dark if browser only has one set of form controls it can display with those auto controls<br>
<dael> AmeliaBR: THat's clear in Rune spec. It's a matter of if browser has >1 color scheme the only is asking author pref to override user. BUt it presumes >1 color scheme<br>
<dael> TabAtkins: Per current processing if you only have 1 color scheme it selects that. Only filters to values unless the set would be empty<br>
<dael> dbaron: Nice spec says that but reality is if 99% browsers have both the 1% will have to do something b/c otherwise pages break<br>
<dael> florian: That's the situation today. If your UI is orange on pink too bad for you.<br>
<dael> dbaron: I'm concerned about Linux. Most users have light form controls. Edge case will expand from set of Linux users with dark controls to all Linux users<br>
<dael> TabAtkins: On pages that are only dark and break in a bad way with a light form control<br>
<dael> TabAtkins: Those don't exist now so it's theoretical future pages<br>
<dael> astearns: How about this. Resolve on putting color scheme in the spec with an issue noting we are concerned about backwards compat and need some way of expressing that it is okay to display things with the controls you've got<br>
<dael> florian: Prefer to start with restricted grammar. Then if we relax later it's easier.<br>
<dael> AmeliaBR: Restricted grammar is do not allow dark only. You can say light only or light and dark but you can't say an only that doesn't include light.<br>
<dael> florian: Yes<br>
<dael> fremy: I still don't...it's removing a possibility that's a legit use case. We are assumign this new feature that doesn't work well on an OS that can chnage. If this becomes a problem Linux can do what every other system does and fix it.<br>
<dael> florian: Compat problem. It's about writing a web page that says it doesn't work on existing OSs<br>
<dael> fremy: That happens all the time. You need a webcam to do a skype call. I don't like spec around limitations of one system<br>
<dael> astearns: CSS is long lived. I can see a new OS that's very concerned about its controls and it will never show a dark mode.<br>
<dael> Rossen_: Are we solving anything? Feels like we're rambling<br>
<dael> astearns: Current suggestion is we put color-scheme in with a change to grammar such that you can only express the only keyword for the light theme<br>
<dael> astearns: Heard concerns it's too restrictive. But it can relax in future<br>
<dael> fremy: If you have a toggle on website that says I want dark theme you can't have dark form controls.<br>
<dael> florian: You can ask for dakr, just not on OSs that can't do it<br>
<dael> fremy: Doesn't work. If you have a website with a toggle and user clicks I want dark theme if the OS has a light you get light<br>
<AmeliaBR> For clarification, I am not supporting the "restricted grammar". But I am very supportive of adding the property to the spec with an open issue.<br>
<dael> fantasai: We're either adding this or not. Apple has shipped. Might be able to get away with not adding only, but we can debate on another day<br>
<dael> fremy: So you can still do dark light for what I want<br>
<dael> resolved: Add the color-scheme property and meta with updated grammar and no 'only' property to Color Adjust spec instead of supported-color-scheme<br>
<dael> fantasai: MS had what they called high contrast MQ and high contrast adjust but they said same is used for low contrast so calling it high contrast is confusing<br>
<dael> fantasai: TabAtkins and I suggest calling it forced-colors<br>
<dael> fantasai: MQ for forced-color-adjust. Rather than diff keywords color scheme relying on dark mode switch so only none or active in the MQ<br>
<AmeliaBR> Strong +1 to the forced-colors name<br>
<dael> astearns: Concerned it's too abstract. contrast-adjust might be better<br>
<dael> fantasai: Not adjusting. This is fixed colors and we're forcing on you<br>
<fantasai> s/fixed colors/fixed set of colors/<br>
<fantasai> @media (forced-colors: none | active) {...}<br>
<florian> I like forced-colors<br>
<fantasai> forced-color-adjust: auto | none<br>
<dael> Rossen_: Forced color desc well. Another name is user-color-scheme. That implies user choose that and only problem is too close to prefers-color-scheme. Forced-colors is fine<br>
<dael> astearns: Other concerns?<br>
<dael> florian: Question- earlier talked about interact with prefers-color-scheme have prefers-contrast, interact?<br>
<fantasai> "The (prefers-contrast) MQ is unrelated and unchanged."<br>
<dael> fantasai: prefers-contrast is same and nothing changes<br>
<dael> TabAtkins: It's orthogonal which is why want to get away from work contrast<br>
<dael> florian: But if forced color scheme has something dramatic you can infer prefered contrast<br>
<dael> TabAtkins: Prefers contrast is different.<br>
<dael> AmeliaBR: Important to keep naming clear. Have set of prefers MQs that tells author user expressed a preference. forced-colors is very different so it's important to have a very different name that emphasizes the override. Also really important that it doesn't make any assumptions about what hte colors are<br>
<fantasai> TabAtkins^: prefers-contrast is about letting author adjust things to match the contrast preferences. This is about you're using this set of colors, too bad.<br>
<dael> AmeliaBR: Key feature for authos is that you're not going to know what colors will be used<br>
<aja> fwiw, implementers, consider support for :has along with the meta, eg :root:has(meta) {--set-some-variables-on-root}}<br>
<dael> florian: Not opposed. Little confused why you can infer prefer high if it's dark but can't infer prefer light<br>
<dael> fantasai: What about lime green on pink. What does that mean? Is it high or low?<br>
<dael> florian: Weird contrast ^-^<br>
<dael> fremy: Agree with florian . Should be in spec. UA can decide to do these things, but we shouldn't spec it. User is allowed to decide they want high contrast. You can put a note saying you can be smart. I like proposal of not forcing this but UA can do smart things<br>
<dael> florian: I'm sold<br>
<dael> Rossen_: Can we go back to forced-colors and not talk contrast?<br>
<dael> astearns: Is high contrast prop in a spec?<br>
<dael> Rossen_: Which? One we prop?<br>
<dael> fantasai: One you prop. There's enough explainers we can write a spec.<br>
<dael> astearns: Prop: Add a forced-colors MQ into the new draft?<br>
<dael> Rossen_: Or MQ, whichever<br>
<dael> fantasai: In MQ<br>
<dael> TabAtkins: Forced-color MQ into MQ spec<br>
<dael> astearns: Objections to adding forced-colors MQ to MQ spec<br>
<dael> RESOLVED: Add forced-colors MQ to MQ spec<br>
<dael> astearns: forced-color property in the new spec<br>
<dael> TabAtkins: Indicates on a sub tree don't force colors I know what I'm doing.<br>
<dael> Rossen_: Should go in color adjust<br>
<dael> Rossen_: Fitting to be in color adjust spec<br>
<dael> florian: Presumably the adjust thing on print goes with it?<br>
<dael> fantasai: We should move it, yeah<br>
<dael> astearns: Obj to adding forced-color-adjust property as an opt to into new spec?<br>
<dael> RESOLVED: Add forced-color-adjust property as an opt to into new spec<br>
<dael> AmeliaBR: In draft from Rossen_ and melanierichards lots of issues about interaction between author and UA will go. Is that into new spec?<br>
<dael> TabAtkins: Yes<br>
<dael> AmeliaBR: fremy had diff prop for same thing so that discussion would happen in this spec?<br>
<dael> TabAtkins: Yep<br>
<dael> astearns: We'll have continued discussion for this new spec, what goes in , and changes<br>
<dael> fantasai: Reoslve to move print-color-adjust?<br>
<dael> astearns: Obj?<br>
<dael> resolved: Move print-color-adjust property into the new spec<br>
<dael> astearns: I'll leave agenda+ on the new items<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3807#issuecomment-484176211 using your GitHub account
Received on Wednesday, 17 April 2019 17:01:33 UTC