- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 21 Nov 2024 16:53:41 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-ui] Colors to use for appearance:base `<select>` ``, and agreed to the following: * `RESOLVED: Use currentColor for borders, inherit the color, transparent background color (for in-page controls). Use system colors for pickers.` <details><summary>The full IRC log of that discussion</summary> <gregwhitworth> ntim: presenting a presentation on proposed colors<br> <gregwhitworth> q?<br> <masonf> q+<br> <gregwhitworth> ack masonf<br> <gregwhitworth> masonf: thank you for the preso and history lesson<br> <gregwhitworth> masonf: my question is about forced colors and I assumed we would need the MQ but it seems like you found we may not need to do that?<br> <gregwhitworth> ntim: it's always ensured with currentcolor and transparent background<br> <dbaron> The resolution https://github.com/w3c/csswg-drafts/issues/11097#issuecomment-2489223857 from yesterday might be relevant here<br> <gregwhitworth> ntim: you don't get the semantic colors that the user has defined<br> <gregwhitworth> q?<br> <gregwhitworth> dbaron: yesterday the CSSWG had a discussion around forced-color and color-mix and it doesn't allow you to override the colors as it falls back to the set<br> <gregwhitworth> ntim: that may mean that we don't need the special color<br> <brecht_dr> q+<br> <gregwhitworth> dbaron: the flip side is the risk that in forced colors mode there is no way to identify disabled style<br> <gregwhitworth> ack fantasai<br> <Zakim> fantasai, you wanted to request a copy of the slides for the minutes<br> <gregwhitworth> ack brecht_dr<br> <gregwhitworth> brecht_dr: the one example you showed us with the one covered in yellow<br> <gregwhitworth> brecht_dr: I'm curious if this works but is this something that can be annoying that you're using this in forced colors?<br> <gregwhitworth> brecht_dr: I don't know but I would like to know as this would be annoying<br> <gregwhitworth> ntim: the idea is not only for HC but also for cognitive disability for instance everything that is blue is a button<br> <gregwhitworth> ntim: everything that is green is a text input, etc<br> <gregwhitworth> ntim: the user preference is the thing to respect here regardless<br> <masonf> q+<br> <gregwhitworth> ntim: we want to force system colors in forced-colors mode and the theory of how is to just do what works<br> <gregwhitworth> ack masonf<br> <gregwhitworth> masonf: the first one is the proposal about transparency and currentcolor and system colors<br> <argyle> q+<br> <gregwhitworth> ack argyle<br> <gregwhitworth> argyle: I'm curious if this proposal that we would like ghost styling for all form inputs as though it's a div with a border and would have no background<br> <gregwhitworth> fantasai: correct<br> <gregwhitworth> masonf: by default, of course the dev could add one<br> <gregwhitworth> argyle: we have colors in system colors<br> <gregwhitworth> fantasai: but none that are garaunteed to have contrast with system colors<br> <gregwhitworth> q+<br> <gregwhitworth> masonf:<br> <gregwhitworth> masonf: what is the problem<br> <gregwhitworth> argyle: I see more issues with this than currentcolor with system colors than this<br> <gregwhitworth> fantasai: it's the background that is underneath unless you change the color on the input<br> <gregwhitworth> fantasai: you can get into this today<br> <gregwhitworth> fantasai: you can set the color without setting the background color today and true since CSS1<br> <gregwhitworth> argyle: I would have assumed everything is accessible by default<br> <gregwhitworth> argyle: it comes with healthy defaults for background + text, etc<br> <ntim> PROPOSED RESOLUTION: Use currentColor for borders, inherit the color, transparent background color (for in-page controls). Use system colors for pickers.<br> <ntim> We force system colors in forced colors mode, figure out what would be the best mechanism.<br> <gregwhitworth> fantasai: you'll get this if you set the color to the background that doesn't contrast with the background<br> <gregwhitworth> argyle: I don't know a design system that is ghost alone<br> <gregwhitworth> ntim: Material Design<br> <gregwhitworth> ntim: the proposal inherits the color from the parent element<br> <gregwhitworth> argyle: they have an inherited contrast and they could have good contrast out of the box<br> <gregwhitworth> anne: none of the HTML elements have their own background<br> <gregwhitworth> anne: that's the reasoning behind this proposal<br> <gregwhitworth> anne: isn't that the point of this<br> <gregwhitworth> argyle: I thought the principle was to make this "safe" and accessible by default<br> <gregwhitworth> fantasai: what is the difference between this and an H3<br> <gregwhitworth> argyle: I'm not saying they're the same<br> <fantasai> or a <strong> element<br> <gregwhitworth> anne: they have the same requirements<br> <gregwhitworth> anne: how are they different<br> <gregwhitworth> argyle: they have states and interactivity<br> <gregwhitworth> argyle: they're quite different<br> <brecht_dr> q+<br> <gregwhitworth> anne: none of those impact the styles<br> <gregwhitworth> ntim: people expect backgrounds behind them is that we expect them and there is no extra background requirement<br> <davidleininger> q+<br> <chrishtr> q+<br> <gregwhitworth> argyle: if you want to go super minimal and that's the most minimal starting place and you're saying people will fix it<br> <gregwhitworth> fantasai: if it's not they have bigger problems<br> <jarhar> q?<br> <gregwhitworth> ack brecht_dr<br> <gregwhitworth> brecht_dr: I do think it's important to have base because you decided to set it to that but I do understand from argyle and differentiation from that and a div<br> <gregwhitworth> brecht_dr: if you have a border on an H3 and an interactive element right from the start<br> <gregwhitworth> brecht_dr: I'm not sure if that is right<br> <gregwhitworth> fantasai: we don't have a border on H3 on it<br> <masonf> On a white background, that's the case today though.<br> <gregwhitworth> fantasai: maybe you want to make some style changes then<br> <gregwhitworth> brecht_dr: I agree on that<br> <fantasai> +1 masonf<br> <gregwhitworth> brecht_dr: you want something is contrasted and not contrasted<br> <chrishtr> qq+<br> <masonf> gregwhitworth: when we kicked off appearance:base, the styles will be interoperable. That was fundamental.<br> <dandclark> q+<br> <masonf> gregwhitworth: when you do appearance:base, you know how everything will be. We did a lot of research on forced contrast. In theory, even today you can collide colors.<br> <masonf> gregwhitworth: interoperable styles - we have the same DOM and same styles. I'd prefer background colors, because that's how I build them, but I can easily do that. Just add a background-color. I'll always do that.<br> <masonf> gregwhitworth: Tim, there's a difference between popovers and inlines, right? On popovers there will be a background color.<br> <masonf> Tim: right.<br> <gregwhitworth> ack gregwhitworth<br> <gregwhitworth> ack chrishtr<br> <Zakim> chrishtr, you wanted to react to brecht_dr<br> <masonf> ack chrishtr<br> <gregwhitworth> chrishtr: the most important thing is compatible styles that are easy to override and the second most is consistency with how elements work with the web<br> <gregwhitworth> chrishtr: second thing we can stroll poll<br> <masonf> Straw poll: 1) transparent background colors, 2) system colors<br> <gregwhitworth> ack davidleininger<br> <gregwhitworth> davidleininger: I want to be clear on appearance: base is that currentcolor comes into inputs as that doesn't currently work<br> <gregwhitworth> davidleininger: there are so many other little things that can impact this<br> <gregwhitworth> fantasai: we inherit from the parent, not from the body<br> <gregwhitworth> davidleininger: if it inherits from the parent and it inherits from the parent and it's a mismatch how do we handle that?<br> <dbaron> Is the straw poll just about the in-page part of the controls?<br> <fantasai> Should be, yes<br> <gregwhitworth> ntim: the text color inherits from the parent and the background of parent inherits as well so as long as the contrast is correct then this should work<br> <gregwhitworth> davidleininger: I can see this not having a reasonable pair and you're putting a background on a fieldset but it's not meant to be transparent, I can see it causing potential issues and maybe that's something we're ok with<br> <gregwhitworth> ntim: you'll want to set the text color on the fieldset if you're setting the background<br> <masonf> Straw poll: for *in-page controls* (not popover pickers): 1) transparent background colors, 2) system colors<br> <argyle> "base" could learn alot from the wildly popular "headless ui" libs, since that sounds like what this group is hoping "base" can be?<br> <argyle> https://nerdy.dev/headless-boneless-and-skinless-ui#headless-ui<br> <gregwhitworth> davidleininger: I'm not going to lose sleep over it<br> <fantasai> masonf, you forgot about inheriting the color :)<br> <gregwhitworth> anne: so they would not set the color property<br> <gregwhitworth> davidleininger: people build things in terrible ways all the time<br> <gregwhitworth> davidleininger: I'm going to throw this standard element inside of this element and it's going to house the form but the form is white and they use a div that is grey background and they apply appearance: base and it's a grey one now there is no background<br> <gregwhitworth> davidleininger: the have had a white background for so long that it could mess with things<br> <gregwhitworth> anne: they could not use the H3 in that context<br> <chrishtr> q?<br> <masonf> fantasai, yeah. Colors *are* inherited, they're just overridden in the current stylesheet. Right?<br> <gregwhitworth> anne: if you set display: none on your root should we disable that?<br> <gregwhitworth> davidleininger: we're not making that the default<br> <gregwhitworth> masonf: the label on the element on the would not have contrast<br> <gregwhitworth> ack dandclark<br> <gregwhitworth> dandclark: I'll agree with gregwhitworth and chrishtr is the priority and either of these options are viable for that<br> <masonf> +1 to fantasai's version of the poll. Just to be completely transparent. ;-)<br> <gregwhitworth> dandclark: apologies if I missed this and we need to have multiple colors such as range, seems like we're locked into one foreground color?<br> <gregwhitworth> dandclark: how would you expect that to work<br> <gregwhitworth> ntim: we could use mixes of current color with lumances and have one color, etc<br> <argyle> #2<br> <masonf> 1+<br> <dbaron> POLL: for *in-page* part of the control (not popover pickers): 1) inherit 'color', transparent 'background' or 2) use system colors<br> <masonf> 1<br> <chrishtr> 1<br> <ntim> 1<br> <fantasai> 1<br> <gregwhitworth> abstain<br> <astearns> abstain<br> <jarhar> 1<br> <dbaron> 1<br> <davidleininger> 2<br> <dandclark> 1<br> <emilio> 2<br> <brecht_dr> 2<br> <ntim> RESOLVED: Use currentColor for borders, inherit the color, transparent background color (for in-page controls). Use system colors for pickers.<br> <ntim> We force system colors in forced colors mode, figure out what would be the best mechanism.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10909#issuecomment-2491769385 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 21 November 2024 16:53:42 UTC