- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 02 Jun 2021 23:42:49 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[mediaqueries-5] Remove (prefers-contrast) as a boolean, and replaced by a new color reduction media query`, and agreed to the following: * `RESOLVED: Add 'custom' property for defined color schemes that are not high or low` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [mediaqueries-5] Remove (prefers-contrast) as a boolean, and replaced by a new color reduction media query<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/6036<br> <dael> astearns: There are new proposals at the end of the issue<br> <dael> alisonmaher: Previously resolved to remove prefers-colors:forced. This issue was a follow up to prop a new MQ to capture intersections under redecuded complexity. Various proposals including adding back forced<br> <dael> alisonmaher: Summerizing various options<br> <dael> alisonmaher: If middle range is not a valid contrast preference one option is a new MQ to capture intersections<br> <dael> alisonmaher: Could leave spec as is and add examples to handle<br> <dael> alisonmaher: If middle range is valid, other options<br> <astearns> +1 to adding examples of mid-range things, regardless of outcome today<br> <dael> alisonmaher: If add back prefers-contrast:forced it captures the users in the middle range, but author confusion<br> <florian> q+<br> <dael> alisonmaher: Another is adjust the cut off between more and less to get middle range. Might also add confustion<br> <dael> alisonmaher: Another option is add a third value of middle to capture the preferences. Allows express neither high nor low, but not no preference<br> <TabAtkins> q+<br> <dael> alisonmaher: Personally leaning toward a new value, but curious rest of the group thoughts<br> <astearns> ack florian<br> <dael> florian: Thanks for bringing this. Middle value, probably name is a big part of usability. Naming aside, is this supposed to be same semantics as forced?<br> <dael> alisonmaher: Different. Forced value matched no matter the contrast preference. Middle would only match for users in the middle range. Only in forced color mode for now, but could make sense for future values as well<br> <astearns> ack TabAtkins<br> <dael> TabAtkins: This is reasonable to me. Fills in the case. Forced but not high nor low. That's the spot we wanted addressed. Use this as a bool to indicate general contrast preference. This is fine<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to distinguish middling luminosity contrast preference vs specific hue contrast preference that happens to have middling luminosity preference<br> <jcraig> q+<br> <dael> fantasai: My concern a little bit, don't know all usage, but this would be interpreted as I want grey on grey text, but not too grey. Not quite black on white, but more between and author would be encoraged to include that.<br> <dael> fantasai: Reason we had that is for causes when someone wanted a contrast in hue that was not low or high for luminosity.<br> <dael> fantasai: If you were going to have fusha on blue it's got a strong hue contrast, but not strong luminosity. THat's presumably middle but isn't want people would picture. I think adding a middle value would add confusion<br> <Rossen_> q?<br> <florian> q+<br> <dael> fantasai: I think anyone pulling out prefers-contrast:middle would be confusing<br> <dael> alisonmaher: Are you saying naming is confusing or it wouldn't make sense to query a middle value?<br> <dael> fantasai: Kinda both. How is author supposed to respond to prefers-contrast:middle?<br> <dael> alisonmaher: Not sure use cases. Making sure if a user i nthat ranger we would capture in prefers contrast bool. Not sure us cases to target middle by itself<br> <dael> fantasai: We're trying to capture contrasts not high nor low but specific. I think middle is not a good representation of that<br> <dlibby> q+<br> <dael> astearns: But there is A preference, just not high or low. Middle expresses the not high or low but may not be expressing the choosen colors<br> <jcraig> q+ to request that the prefers-contrast MF remain about contrast, and the forced-colors MF remain about forced colors<br> <jcraig> ack me<br> <Zakim> jcraig, you wanted to request that the prefers-contrast MF remain about contrast, and the forced-colors MF remain about forced colors<br> <astearns> ack jcraig<br> <dael> jcraig: I've caught up on the thread and thanks to alisonmaher about correcting my misunderstanding earlier. As far as I understand only current impl where this matches is impl with forced color that are not high or low contrast<br> <dael> jcraig: I believe were we landed on #5433 is this middle range may have people matching but doesn't rep anything suffiently about contrast so keeping out of contrast was preferably. BUt forced colors would remain about forced colors<br> <astearns> other discussion: https://github.com/w3c/csswg-drafts/issues/5433#issuecomment-785251576<br> <dael> jcraig: This group is matchable if you have not prefers-contrast: more and not less.<br> <dael> jcraig: I think goal of group was to get to something like prefers reduced color complexity. If we're trying to do that we need to name it something obvious to the author. I don't think middle is for a prefered reduction in complexity. Feel it's muddling<br> <dael> jcraig: Is the goal that the group wants to get rid of cforced-colors media preference?<br> <dael> alisonmaher: Main issue comes down to that do we agree middle range is a contrast preference. Different resolutions depending on the answer<br> <TabAtkins> q+<br> <dael> astearns: Are you looking to removed forced colors MQ?<br> <dael> alisonmaher: No. But seemed like matching the middle range in the bool is of interest.<br> <astearns> ack florian<br> <TabAtkins> q-<br> <TabAtkins> My q+ was to suggest "complex", yeah<br> <fantasai> lol, I'd have suggested "simple"<br> <Rossen_> Have we considered naming it "custom"<br> <fantasai> The preference isn't complex. It's for simple color contrast.<br> <dael> florian: I think I agree with fantasai that middle is the wrong name if we have it. Unusual or unspecific that indicates that there is a preference is better. That people would query that specificially, I suspect for bool is more likely but either way you could query.<br> <TabAtkins> We name it "--"<br> <fantasai> Just different from either high or low<br> <dael> florian: It's possible to query the middle value which is why I like both old and new<br> <fantasai> Rossen_, that could work...<br> <dael> florian: As to why reopen I thought I had lost the battle and gave up but immediately after it was closed there were question son how to deal with this and fremy posted good examples.<br> <dbaron[m]> I think it would help with the naming to understand who the users are who have this type of preference, and why they have it (and perhaps how essential it is to their ability to use the web).<br> <TabAtkins> The only purpose of this third value is to handle pages with reduced color palettes that can't otherwise be categorized as high or low contrast.<br> <dael> florian: Crux of the issue is it's 1 to 1 with prefers reduced complexity. Important thing is how it will be used. Typical thing in context of the bool query for prefers-contrast without a spec of high or low is to reduce color complexity of the page. Seems odd to have a query for that but fails to capture a set of the users<br> <dael> florian: When query with intent of reduce complexity this almost always gets you there, so why not make sure it gets all the way<br> <dael> florian: Given it was reraised and you agreed it was 1 to 1 with reduced color I thought why not<br> <dael> jcraig: Main goal is to get back to previous value of bool match?<br> <dael> florian: TO me, yes. If you use first contrast as a bool it would be useful if it matched odd contrasts. Not sure what you would use that to match and not want these people<br> <dlibby> q-<br> <dael> jcraig: My recollection is I do agree there could be a corrilation between a desire for reduced complexity and forced colors. Thought we settled that should be something as a clearly named MQ. COuld be if you have high or low contrast it would also match prefers-reduced-complexity<br> <florian> q+<br> <dael> jcraig: It could match @media for prefers contrast and prefers reduced complexity. Todya should be able to do it with @media prefers-contrast or forced-colors<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to express that the goal here is to make sure that everyone who has a contrast preference is captured under (prefers-contrast)<br> <jcraig> q+ to answer Alison's question that I don't think the `middle` value represents a contrast-specific preference... It does represent a color preference but not contrast.<br> <astearns> q+<br> <dael> fantasai: To go back to what is goal of issue- make sure everyone with any color contrast preference get captured under prefers-contrast:true. Low and high preference are captured under low and high keywords. WE want anybody with a contrast preference that's neighter low nor high luminosity are also captures under yes so they are captured<br> <astearns> ack florian<br> <dael> fantasai: That's separate...you will impl that as reducing color complexity but that's a question about what does pferfers contrast me<br> <fantasai> s/impl/often implement/<br> <fantasai> s/pferfers contrast me/prefers-contrast mean/<br> <fantasai> s/that's a/this is the/<br> <dael> florian: It's a question of consituancy priority. Put users first. Author thinking about the problem with all angles could get there however I think it is typical for authors to not think of every case and hope it's useful. I don't think anybody has example of piece of style you would write under bool prefers-contrast that wouldn't be useful to people with unusual scheme.<br> <dael> florian: Small group, but it is useful. If authors are writing and we could make it apply as useful I think we should. I don't think we should add intent-based queries with feature-based queries.<br> <jcraig> ack me<br> <Zakim> jcraig, you wanted to answer Alison's question that I don't think the `middle` value represents a contrast-specific preference... It does represent a color preference but not<br> <Zakim> ... contrast.<br> <dael> florian: If there are cases of adding the bool that shouldn't catch these people then the argument falls apart. But the argument that you could target isn't a good reason to exclude these people<br> <dael> jcraig: Answering alisonmaher from earlier I think she asked earlier do we agree middle is a contrast preference. My opinion is no. fantasai earlier mentioned prefers-contrast more would have a luminosity contrast value and less lower. Middle is luminosity value that doesn't rep contrast in either direction<br> <florian> q?<br> <florian> q+<br> <dael> jcraig: May also be color preference with hues, but that's circumsantial. May or may not be contrast preference in hue, but no preference in luminosity. So I don't think this represents a preference. To help users have to help authors understand what they're trying to do for the users<br> <Morgan> +1 to jcraig's opinion<br> <dael> astearns: I wanted to ask...I think we have a problem coming up with a name for the value b/c don't have a good idea of what contrast preference is expressed by having forced colors<br> <dael> astearns: Agree it would be nice to include people that have choosen forced colors in a prefers-contrast MQ b/c they have expressed preference in colors with some contrast. Can we define it to return true if forced colors is on and not add value?<br> <astearns> ack astearns<br> <dael> TabAtkins: Violation of current data model. Not impossible, but seems weird. Only reason trying to do something special is we can't think of a name I'd like to have a name. BUt this is not impossible. This MQ does a slightly different thing with bool than everything else<br> <astearns> ack florian<br> <dael> florian: Kind of disagree with jcraig that we should name different to cover everyone. Query specifically for high or low contrast makes sense. If we have those indiviaully and the bool people will sometimes use high or low or sometimes the color and that seems problematic.<br> <dlibby> q+<br> <astearns> ack dlibby<br> <dael> florian: I think bias to easily discoverable doing the right thing is how we get the platofrm to be usable<br> <dael> dlibby: Back to color preference with hues as sep from contrast. Wanted to check thoughts on forced-color affect prefers-contrast. That statement feels at odds with agreement. To extend forced-color effects prefers-contrast in most cases preference is to have it apply for all cases in the bool context<br> <TabAtkins> I'm happy with "custom"<br> <fantasai> +1, wfm<br> <florian> I'm happy with custom.<br> <dlibby> custom sgtm too<br> <dael> Rossen_: I put this in IRC; can we align with calling it custom and stray away from middle or not? Values can be higher or highest and what it comes down to is we're trying to say we know how to capture high and low and inbetween is a custom value that we want to allow authors to take advantage of. As far as naming goes custom makes sense to me<br> <dael> florian: wfm<br> <jcraig> q+ to custom is okay... I'm not convinced it's necessary, but I don't feel strongly enough to object<br> <dael> astearns: Lots of +1 on IRC<br> <jcraig> ack me<br> <Zakim> jcraig, you wanted to custom is okay... I'm not convinced it's necessary, but I don't feel strongly enough to object<br> <dael> jcraig: I'm not convinced it's nec, but not strong enough to object. Custom is a better name than middle. If that satisfies desire to keep bool and embed reduced complexity inferance I think it's probably okay. I can live<br> <dael> astearns: For my clarification, this 'custom' value would return true if forced colors were active?<br> <dael> jcraig: And the resulting contrast does name match more or less. More or less defined with luminosity contrast<br> <dael> astearns: Add a 'custom' value that matches if forced-colors is active but it's not high or low<br> <dlibby> s/high or low/more or less/<br> <dael> jcraig: I wouldn't leave it to be forced-colors. Has to do with defined color scheme. Custom color scheme that doesn't match more or less.<br> <dael> astearns: Yeah, any sort of defined color scheme that's not high or low<br> <dael> astearns: Obj?<br> <dael> RESOLVED: Add 'custom' property for defined color schemes that are not high or low<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6036#issuecomment-853452018 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 2 June 2021 23:43:16 UTC