- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 19 Mar 2026 15:41:12 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-forms-1] different border-radius on select vs picker looks janky`, and agreed to the following: * `RESOLVED: ::file-picker-button matches button` * `RESOLVED: the shape of the color picker will match the shape of a select` <details><summary>The full IRC log of that discussion</summary> <jarhar> lwarlow: openui discussed and resolved to remove the border radius from select, the in page part, so the picker and in page part match<br> <jarhar> lwarlow: then i have follow up questions: what do we want to do regarding other controls<br> <jarhar> lwarlow: buttons we are in agreement need the border radius so they can be distinguished from text inputs<br> <jarhar> lwarlow: for color input, do we want border radius there? other place would be the file input button<br> <jarhar> fantasai: for the file input button, its a button so it should look like a button<br> <jarhar> fantasai: for the color input, id probably lean towards having border radius just to make it clear that its clickable<br> <jarhar> astearns: you could say the same thing about select<br> <jarhar> masonf: there is a difference that it has a picker icon<br> <jarhar> fantasai: youre not going to be confused about whether you can interact with it<br> <jarhar> lwarlow: that does lead to the question: if we have border radius on color, that does have a picker. are we going to run into the same situation?<br> <jarhar> ntim: were going to run into the same issue with the mismatched border radius<br> <jarhar> fantasai: so it needs to be a square<br> <jarhar> masonf: should you put a picker icon on it and then make it square?<br> <jarhar> lwarlow: color is an interesting one since its a rounded<br> <jarhar> lwarlow: it is a button for all intents and purposes<br> <fantasai> s/a rounded/often rounded/<br> <jarhar> lwarlow: i worry that if we resolve to do a border radius there then were going to have to think about the border radius doesnt match<br> <jarhar> lwarlow: unless we make the color input circular<br> <jarhar> annevk: is select not round as well?<br> <jarhar> lwarlow: it is currently, but it was discussed in openui and here to remove it from that because the border radius mismatched between the picker and the in page part<br> <jarhar> annevk: but thats weird because then we have a button that doesnt have a border radius. how do you know youre supposed to pick it?<br> <jarhar> masonf: the picker icon<br> <jarhar> masonf: or click into the text and find out that its a picker<br> <jarhar> annevk: i thought the issue was that the borders ended up touching<br> <jarhar> ntim: thats something else<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/13520#issuecomment-3928257620<br> <jarhar> masonf: for this color picker, by the time we get to customizing the picker for color input we will be retired<br> <jarhar> masonf: for this one i think its ok to focus on the in page part<br> <jarhar> astearns: shall we resolve that the file picker button is round?<br> <jarhar> masonf: there is something inside of it that looks like a button, and then theres something else outside of it? were talking about the inner button, right?<br> <lwarlow> Yeah the ::file-selector-button<br> <jarhar> astearns: yes<br> <masonf> +1<br> <lwarlow> +1<br> <jarhar> fantasai: i would say that the file picker button should match button<br> <fantasai> RESOLVED: ::file-picker-button matches button<br> <lwarlow> It's file-selector-button btw not picker<br> <jarhar> astearns: should we also say that the color picker should be like a select?<br> <masonf> +1<br> <jarhar> astearns: if we say that the color picker should be like a select, then it can adapt if someone comes back and says the select needs to be rounded<br> <jarhar> annevk: if we enhance file input to have a dropdown for take a photo etc. then youd have the same kind of thing right?<br> <jarhar> astearns: thats a different control<br> <jarhar> dbaron: that ones also different since its ua generated<br> <lwarlow> q+<br> <jarhar> annevk: it could be stylable through a bunch of pseudo elements<br> <jarhar> masonf: thats even less likely than a customizable color picker<br> <fantasai> Options for color picker button: a) match select [currently square] b) match button [currently rounded] c) circular d) square<br> <jarhar> lwarlow: i was thinking of a middle step picker like datalist<br> <astearns> ack lwarlow<br> <jarhar> lwarlow: if file input had this middleman step, like take a photo now or open the native file picker<br> <jarhar> masonf: arent there security/privacy issues about that revealing whether theres a camera?<br> <jarhar> lwarlow: i think its important that these are consistent<br> <jarhar> annevk: can the picker be rounded?<br> <jarhar> fantasai: but datalist is square<br> <jarhar> masonf: text things are square and button things are rounded<br> <jarhar> annevk: does it look bad if its the other way around? where the picker is rounded and the in page thing is square. would that still look bad? i think the main thing that makes it look bad is no gap between them<br> <jarhar> lwarlow: i would argue that it doesn't look bad, and i think that the would you ship this question is moot because you can customize them<br> <jarhar> ntim: ideally they would be usable without any styles<br> <jarhar> lwarlow: its more impotant to be consistent between controls than to make sure that button and picker are perfect<br> <jarhar> masonf: these are design choices, people wont like them in 5 years<br> <jarhar> ntim: how about everything has a border radius, and we use background to differentiate buttons and inputs<br> <jarhar> ntim: hover state on buttons would become default state<br> <jarhar> lwarlow: using color alone for meaning is not good<br> <jarhar> ntim: im just throwing out ideas<br> <jarhar> lwarlow: the simplicity right now is nice<br> <jarhar> ntim: theres already one for the hover state<br> <jarhar> lwarlow: the hover state is a derivation of the others<br> <jarhar> ntim: if you want a different background that would override the hover state<br> <jarhar> astearns: can we go back to the consistency argument and say that color should match select?<br> <jarhar> ntim: i think a square color input is probably not a problem, but im also not a ui expect<br> <jarhar> ntim: *expert<br> <jarhar> lwarlow: im fine with making them consistent<br> <masonf> +1<br> <jarhar> proposed resolution: the shape of the color picker will match the shape of a select<br> <jarhar> annevk: theres one other button that might make us lean towards squares which is the image button<br> <jarhar> annevk: if you give that one rounded corners, youre removing some content<br> <lwarlow> +1<br> <jarhar> lwarlow: i think that one not having rounded borders is ok becaues the actual rendering is based on the image<br> <jarhar> lwarlow: if people are using image buttons they deserve display:none!important<br> <jarhar> RESOLVED: the shape of the color picker will match the shape of a select<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13520#issuecomment-4091090153 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 19 March 2026 15:41:13 UTC