- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 19 Feb 2026 16:30:09 +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`.
<details><summary>The full IRC log of that discussion</summary>
<jarhar> ntim: we received feedback that the border radius mismatching on the picker and button makes alignment look off<br>
<jarhar> ntim: i agree, and our simplest proposal to address that is to put border-radius:inherit on the picker<br>
<jarhar> ntim: all the other proposals internally involed adding spacing and i think that would break more things<br>
<jarhar> fantasai: im not sure that tweaking the spacing would break more things because people are often going to change the spacing, but this works the best<br>
<emilio> q+<br>
<jarhar> fantasai: it results in it looking reasonably good<br>
<masonf> q+<br>
<jarhar> fantasai: pretty robust solution<br>
<astearns> ack emilio<br>
<lwarlow> q+<br>
<jarhar> emilio: is there any precedent for inheriting it like this? should we just set the same default and if they change it they can change the picker?<br>
<jarhar> emilio: people may remove the border altogether on the button<br>
<astearns> q+<br>
<jarhar> fantasai: usually the author is going to either have a border or background thats different and they can set it to something else. having a border radius zero on select then making the picker rectangular also is a nice thing<br>
<jarhar> emilio: seems fine, but appearance base generally does rely more on inheritance anyways<br>
<jarhar> ntim: the idea is that if you make the button square then the picker wont look off<br>
<jarhar> emilio: but if you set a percentage border radius then it looks weird, so id rather have a default on both<br>
<jarhar> fantasai: i think youd notice that immediately<br>
<jarhar> emilio: it seems very easy to change the border radius on an already working thing<br>
<jarhar> emilio: in general percentage border radius will behave weird<br>
<jarhar> emilio: simplest solution is just setting the same radius by default<br>
<astearns> ack masonf<br>
<jarhar> masonf: not against changing it if we have to change it, we should focus on it being stylable easily. appearance base 99% of people will be setting their own border radius, so the default doesnt matter as much<br>
<jarhar> masonf: i do want to point out lukes comment - buttons are rounded and not button things are not rounded. the picker is not a button, so its not rounded. are we sure thats not correct?<br>
<jarhar> ntim: appearance base controls should not look somewhat broken by default, thats the rationale that lead to this<br>
<jarhar> ntim: ideally people should be able to set appearance base and have something that works for their site without any express styling<br>
<jarhar> masonf: im curious if its broken. it looks like a picker to me<br>
<jarhar> fantasai: it looks super weird and our devrel said that we need to not have things look super weird<br>
<jarhar> masonf: the one in the original post looks very styled, thats not what it looks by default<br>
<jarhar> masonf: its only not styled in the border radius of the picker<br>
<emilio> q+<br>
<jarhar> ntim: i posted a followup comment<br>
<jarhar> masonf: im not a designer<br>
<astearns> ack lwarlow<br>
<jarhar> astearns: personally i think the first or third example in tims comment look fine to me. i dont see a big usability difference, but im also not a designer<br>
<jarhar> lwarlow: if were going to do this, i think inherit is the right value. if youre making your select button completely round, youre doing something weird, and youll want a different border radius for your picker and your button<br>
<jarhar> lwarlow: maybe you have a picker with button and text and a flag<br>
<jarhar> lwarlow: needing to set the border radius in two places seems weird<br>
<jarhar> lwarlow: i dont think its broken in its current state. i think its fine<br>
<jarhar> lwarlow: i actually dont think making the picker round actually makes it look that much better<br>
<emilio> Doing something like `select:not(:first-child) { border-top-left-radius: 0; border-bottom-left-radius: 0 }` on a toolbar seems like it also would end up with weird results<br>
<jarhar> lwarlow: theres an example i posted in the issue just now of whether picker is wider than the button, where having the two rounded bits looks weird<br>
<jarhar> lwarlow: its the sort of thing that people are goig to customize<br>
<jarhar> lwarlow: i dont necessarily think its needed here<br>
<jarhar> lwarlow: if we do a rounded picker here we will have to do rounded pickers everywhere<br>
<jarhar> lwarlow: rounded pickers dont seem super common, native ones are not, except maybe on ios<br>
<jarhar> lwarlow: generally speaking theyre pretty square, it feels weird to round them<br>
<jarhar> ntim: the macos select is round<br>
<jarhar> lwarlow: yeah i guess its got a smaller radius<br>
<jarhar> lwarlow: id be ok with changing it. i do wonder if it might break existing designs<br>
<jarhar> lwarlow: if we make it inherit its less likely to break designs. if we make it 0.5 then they have to change it<br>
<jarhar> emilio: i disagree. theres tons of things that are reasonable to do, like changing the border radius at the start of a toolbar<br>
<jarhar> lwarlow: how does it work if you customize the border on specific sides?<br>
<jarhar> emilio: it will inherit<br>
<jarhar> emilio: i dont think inherit is what we want<br>
<astearns> ack dbaron<br>
<jarhar> lwarlow: i think youve persuaded me<br>
<masonf> I just commented on the issue - MacOS has border radii on the button and the picker, but they're *different* from each other.<br>
<jarhar> dbaron: if were going to do this, we should not do inherit. i dont feel that strongly.<br>
<jarhar> dbaron: one reason is that using inherit as a default value for a non inherited property is really unusual, and i think its going to trip people up just because its surprising<br>
<dbaron> luke's example that I'm mentioning: https://github.com/w3c/csswg-drafts/issues/13520#issuecomment-3922989178<br>
<lwarlow> We inherit border radius for radio buttons "checkmark" fwiw<br>
<jarhar> dbaron: second reason is realted to lukes example in the issue which i think is what you were just talking about where to do that example luke put in the issue you might want to say if the select is open, then set the two bottom radiuses to zero, and set to the two top ones to whatever on the picker<br>
<jarhar> dbaron: that will inherit to the picker and thats goig to be weird<br>
<jarhar> fantasai: in that case youre already setting border radius on the picker<br>
<jarhar> dbaron: you might not be if youre only doing the overrides to zero<br>
<jarhar> lwarlow: you might have your picker be square and then have the select be rounded at the top and square at the bottom. if we made this change it would break that<br>
<jarhar> lwarlow: either way we break that, but at least with setting a value its slightly less broken<br>
<jarhar> fantasai: i think inherit would make it more matching and more correct in more cases<br>
<lwarlow> q?<br>
<jarhar> astearns: we should probably prioritize making the defaults look the way we want over making it slightly easier to implement changes<br>
<jarhar> astearns: im perfectly fine making people set radius in two places if what we come up with looks better in the default case<br>
<jarhar> astearns: slight balancing of concerns there<br>
<jarhar> astearns: luke you said that there are other pickers that are square?<br>
<jarhar> lwarlow: color picker for example is a square box<br>
<jarhar> lwarlow: firefox currently has an os one thats afully separate window, but in other browsers its just square<br>
<jarhar> lwarlow: time date and all of those<br>
<jarhar> lwarlow: even in desktop safari i dont think most of those are rounded, but maybe im misremembering<br>
<jarhar> lwarlow: ultimately, some are and some arent<br>
<astearns> ack astearns<br>
<jarhar> lwarlow: the date ones in safari are slightly rounded but not to this extent<br>
<jarhar> astearns: argument for consistency with other pickers is maybe not the way to go<br>
<jarhar> astearns: should we take this to a wider set of designers by bringing this to openui?<br>
<jarhar> astearns: i worry that we make a change because the apple designer goes this way and a google designer goes the other way<br>
<jarhar> lwarlow: its shipped in chrome as is. we could debate about this endlessly. its not materially broken<br>
<jarhar> lwarlow: no change is the easiest approach here<br>
<jarhar> lwarlow: its very easy to update<br>
<masonf> q?<br>
<masonf> q+<br>
<jarhar> lwarlow: people can change it in their designs, people are probably going to do the thing in my example<br>
<jarhar> lwarlow: the default should be it works, and it does<br>
<jarhar> lwarlow: personally id rather keep it as is than break things<br>
<astearns> ack emilio<br>
<jarhar> emilio: inheritance i think is bad. it feels magic and will trip people up, and gets wrong results in things that are not corner cases<br>
<jarhar> emilio: saying pickers have radiuses seems easier<br>
<jarhar> emilio: keeping them square is also fine<br>
<astearns> ack fantasai<br>
<jarhar> fantasai: we got pretty strong feedback on our side that the current styling is not acceptable. whether we go with making both of them square or both of them round, theres some openness for what we do, but the current styling is something that apple is really unhappy about<br>
<jarhar> fantasai: i can come up with examples where inheriting is better, and none where having them separate would be better<br>
<jarhar> emilio: strong disagree<br>
<lwarlow> Should maybe timebox this?<br>
<jarhar> fantasai: if we want to get more input from more people, lets do that<br>
<jarhar> fantasai: the current styling is apparently too problematic for us<br>
<astearns> ack masonf<br>
<jarhar> masonf: im happy to bring it to openui. chrome shipped this a year ago, we havent had any bug reports at all from users or developers<br>
<jarhar> fantasai: i suspect theyre always styling it<br>
<jarhar> masonf: maybe the solution to the VP problem is to show them the border radius<br>
<jarhar> fantasai: they commit code to webkit<br>
<fantasai> s/VP//<br>
<jarhar> ntim: that does prove theres a problem because nobodys using the default styling<br>
<emilio> It seems nobody would complain to just set a default border-radius as an interim solution?<br>
<jarhar> masonf: that is the entire point of this control<br>
<jarhar> masonf: i agree with luke, its better not to change it<br>
<jarhar> masonf: existing users will be confused by inheriting<br>
<jarhar> astearns: i see 3 ways forward. one is to leave things the way they are. another is to set default styles to have border radius. another is to go to openui<br>
<fantasai> We'd be opposed to no change.<br>
<jarhar> astearns: i expect the apple folks would prefer adding border radius. would getting more opinions from openui be good?<br>
<jarhar> fantasai: yes<br>
<jarhar> lwarlow: would that be inherited vs separate setting or rounded vs non rounded?<br>
<emilio> q+<br>
<jarhar> ntim: the ask is would you use appearance base as it is with its default styling if the picker and the button had different border radius? thats the ask<br>
<jarhar> ntim: thats what this feedback is about, we cant use this with its default styling<br>
<jarhar> astearns: id like to put this to openui folks and if there are more opinions in openui that current defaults are just unusuable as is, then we can change the rounded ones<br>
<masonf> I agenda+'d this one: https://github.com/openui/open-ui/issues/1375<br>
<jarhar> astearns: if we dont get people independently agreeing that square corners are unusualbe, then we close this no change<br>
<jarhar> fantasai: would you consider it acceptable to ship this in a website with no changes? if not, what would you change in the default stylesheet<br>
<emilio> q-<br>
<jarhar> astearns: were either goig to get the opinion that its fine as is, or a set of ten changes<br>
<jarhar> masonf: i just added an openui issue<br>
<lwarlow> q+<br>
<astearns> ack lwarlow<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-3928370089 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 19 February 2026 16:30:10 UTC