- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 05 Mar 2026 17:05:29 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-forms-1] Find a way to avoid double border between ::picker() and button`, and agreed to the following: * `RESOLVED: close this no change for now` * `RESOLVED: strike that and just leave the issue as-is for now` <details><summary>The full IRC log of that discussion</summary> <lwarlow> 1+<br> <lwarlow> q+<br> <jarhar> q-<br> <jarhar> fantasai: we were thinking that the thing that probably makes the most sense is an anchor positioning feature that has been resolved on but hasnt made it into the spec yet which tells which box you want to anchor to. default is border box, for a select it might make sense to anchor it to the padding edge in the block axis so that looks like the<br> <jarhar> picker menu is actually coming from the ?? that was the idea<br> <jarhar> fantasai: the downside of that is that there are some designs that want it to look outside to outside<br> <jarhar> masonf: that is a new property?<br> <jarhar> fantasai: yes, position-anchor-box i think<br> <jarhar> fantasai: alternative is to put -1 margin on it<br> <masonf> q+<br> <jarhar> fantasai: which would overlap the 1px border<br> <astearns> ack lwarlow<br> <jarhar> lwarlow: margin -1 i think would be a massive code smell for base appearance. you shouldnt need to do that kind of margin hack in the base styles<br> <jarhar> lwarlow: ideally we should be setting properties that we need to set, but we shouldnt set more than that<br> <jarhar> lwarlow: margin -1 feels slightly weird<br> <jarhar> lwarlow: the other thing with changing to the padding box would be better<br> <jarhar> lwarlow: it looks less weird<br> <jarhar> lwarlow: i will say that would break my existing select<br> <jarhar> lwarlow: the picker has its top border set to 0 width, and if you change it to anchor against the padding box that will overlap with the buttons border such that there will be no border<br> <jarhar> astearns: the padding box could be overriden in your case<br> <jarhar> lwarlow: yes but it doesnt at the moment and it works in production, thats the point - it could break designs<br> <jarhar> lwarlow: i suspect that design does exist in the wild already, but probalby not too much<br> <jarhar> lwarlow: thats worth being aware<br> <astearns> q+<br> <jarhar> lwarlow: with the proposed change from openui, where potentially select wont have a border radius, i guess this issue still occurs, but is it less bad?<br> <jarhar> lwarlow: you still end up with the double border<br> <astearns> ack masonf<br> <jarhar> masonf: we did resolve to remove border radius last week. we also resolved to add an issue to a non weird looking criteria to the design principles<br> <jarhar> masonf: its fully functional, it just looks weird to most people<br> <jarhar> masonf: we should just prefer fewer rules to more rules. each rule is a thing for a developer to go undo<br> <jarhar> masonf: personally i think that if somebody puts out a reset stylesheet for base appearnace then its a failure on us<br> <jarhar> masonf: it should be minimal enough that its a reset<br> <keithamus> q+<br> <jarhar> masonf: here, if the fix for this is to use a new property that doesnt even exist yet, that feels even worse, the reset sheet is growing<br> <jarhar> masonf: if theres a change that can be made in the existing set of properties, maybe thats better, but then i worry about compat as luke mentioned<br> <jarhar> masonf: primarily my objection is the growth of the ua stylesheet<br> <jarhar> astearns: i agree with luke, having a -1 hack to solve this doesnt sound right<br> <jarhar> astearns: contra masons concerns about keeping things simple, the proper way to do that would be have a variable<br> <jarhar> astearns: do we have css variables in the ua stylesheet? should we never put them in there?<br> <jarhar> fantasai: yes<br> <jarhar> zcorpan: variable doesnt solve the problem - if the author sets the border to zero, you still have a mismatch even if the ua stylesheet has a variable<br> <jarhar> masonf: unless the devleoper could change the variable<br> <astearns> ack astearns<br> <astearns> ack keithamus<br> <jarhar> keithamus: i wonder if theres a more generalized way to solve this, and i think designers often come to these issues with segmented buttons where they want buttons in between buttons to not have borders<br> <lwarlow> They're custom properties as well not variables ;) so the UA property is just a property.<br> <jarhar> keithamus: could css have a border collapse? these two elements, if there adjacent, one of their borders should collapse<br> <jarhar> keithamus: probably a wild idea, but it would have utility beyond select<br> <jarhar> fantasai: i think what you want is position-anchor-box<br> <jarhar> fantasai: not true in the general case where you ahve a sibling relationship, tables do border collapsing<br> <jarhar> fantasai: in this case theres not a parallel relationship, its dependent. you want to overlap the anchors border then you should anchor to its box<br> <jarhar> astearns: i agree that seems to be the ideal mechanism, but it isnt implemnented and not even specced yet, so i worry about relying on that<br> <jarhar> astearns: even though we are going to have a principle about not being weird, thats just one principle to balance against the rest<br> <masonf> q+<br> <jarhar> astearns: it might be minimal enough that we decide to elave the double border as weird until we get this anchor positioning mechanism widely supported, and then look at changing the ua stylesheet<br> <keithamus> q+<br> <astearns> ack masonf<br> <jarhar> masonf: we havent decided to add a non weird thing, we opened an issue to discuss which i will be against<br> <jarhar> masonf: keep the web weird, i dont think that should be a criteria<br> <lwarlow> The longer we leave it the larger the compat issue is worth being aware of.<br> <jarhar> masonf: what you said is right, this property doesnt exist yet<br> <jarhar> masonf: developers who think this looks weird can use the property<br> <jarhar> masonf: as we add new stuff to the web, devleopers can use it<br> <jarhar> masonf: you can use it on customizable select but you dont have to break the web<br> <lwarlow> +1<br> <zcorpan> q+<br> <astearns> ack keithamus<br> <jarhar> keithamus: regarding adding the feature later, luke you said that something would break? if were saying we can do this eventually that becomes more of a problem as implementations start to ship<br> <astearns> ack Zakim<br> <astearns> ack zcorpan<br> <jarhar> zcorpan: the double border probably only looks weird when the borders have the same color. if they are different, then maybe the opposite looks weirder<br> <masonf> I think the black border looks weird. It should be hotpink.<br> <jarhar> q+<br> <astearns> ack jarhar<br> <masonf> jarhar: those two borders technically have different colors. The select element inherits its color, and the picker sets CanvasText. They happen to be the same.<br> <lwarlow> Maybe we can resolve no change?<br> <masonf> +1<br> <zcorpan> +1<br> <jarhar> fantasai: we can come back to this when anchor box stuff is specced<br> <lwarlow> A can kick is a no change for now at least I guess<br> <jarhar> astearns: as keith mentioned, we may not be able to use the new thing depending on how long this sticks around<br> <jarhar> masonf: we should open an issue for changing the ua stylesheet over time when new stuff is added<br> <jarhar> astearns: we already have a basic principle of not breaking the web and consider bakcwards compat<br> <jarhar> astearns: in a case by case basis, there may be a way to update base styles that doesnt have compat concerns<br> <jarhar> proposed resolution: close this no change for now<br> <masonf> +1<br> <jarhar> fantasai: ill take that back to the team and look at speccing stuff we had decided a couple years ago<br> <jarhar> astearns: this anchor thing has been waiting for that long?<br> <lwarlow> +1<br> <jarhar> RESOLVED: close this no change for now<br> <jarhar> annevk: maybe lets not resolve on that for now, we want to check back with the team<br> <jarhar> proposed resolution: strike that and just leave the issue as-is for now<br> <lwarlow> +1<br> <keithamus> +1<br> <jarhar> RESOLVED: strike that and just leave the issue as-is for now<br> <masonf> proposed resolution: cancel daylight savings globally<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13527#issuecomment-4006447267 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 5 March 2026 17:05:30 UTC