[css-forms-1] Find a way to avoid double border between ::picker() and button

[nt1m]

The double border between the ::picker() and the button looks slightly unpleasant:

Some options to fix it:

1. add spacing on top of the popover (not my preferred option given it's one more property override), so the picker is spaced away from the button.
2. add negative margin around the popover (not my preferred option given it breaks when you start to have different border-widths on the button, and it's also annoying to override)
3. anchor the popover to the padding-box of the button instead of the border-box (@fantasai told me there was an extension to anchor positioning that would allow that).

Personally in favor of 3 given it's the least pain for developers. I don't know how this would look like in the UA sheet though (potentially position-area: padding-box block-end inline-start or something)

@lukewarlow @josepharhar @fantasai @jensimmons

[lukewarlow]

Do you mean you're in favour of 3? If so I think I agree (out of those 3 options).

[nt1m]

Oh yeah, sorry I originally only typed 2 options

[josepharhar]

We previously thought about fixing this with a margin at the top of the picker, but then removed it: #10857 (comment)

I don't really care that much about this as long as it doesn't break any sites if we change it.

[nt1m]

The third option should not break existing sites as there's no extra property being set. It does require implementing whatever extension is needed for anchor positioning though.

[emilio]

FWIW I think changing this by default would be unexpected. Anchoring to the border-box seems fine to me and matches non-customizable <select>s in all non-macOS platforms.

[lukewarlow]

I mentioned in the call here but to re-iterate this change would almost definitely break an existing select design of mine where the pickers top border width is 0. With this that buttons bottom border would go missing too.

[mfreed7]

I'm really afraid we're on a very slippery slope towards a very opinionated design system in the UA stylesheet for customizable select. The design principle is "The controls are recognizable and usable on their own without additional styles." I'd argue (perhaps strongly) that nothing about the double border makes this unrecognizable, or unusable. E.g. the OP says this "looks slightly unpleasant" which is a design choice, not something that affects usability. I'd lean more heavily on this point of the principles: "They do not have a strong voice & tone of their own, and are visually as simple as possible."

[sorvell]

The design principle is "The controls are recognizable and usable on their own without additional styles."

The principles are great as a guide but clearly there's a need for interpretation and judgment.

The styles are consistent across controls…in look & feel.

There's also this, and I suggest that if rounding and borders are used at all, they should be consistent and apply to the control, as a whole.

This leads me to the proposal here.

[css-meeting-bot]

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

The full IRC log of that discussion

<lwarlow> 1+
<lwarlow> q+
<jarhar> q-
<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
<jarhar> picker menu is actually coming from the ?? that was the idea
<jarhar> fantasai: the downside of that is that there are some designs that want it to look outside to outside
<jarhar> masonf: that is a new property?
<jarhar> fantasai: yes, position-anchor-box i think
<jarhar> fantasai: alternative is to put -1 margin on it
<masonf> q+
<jarhar> fantasai: which would overlap the 1px border
<astearns> ack lwarlow
<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
<jarhar> lwarlow: ideally we should be setting properties that we need to set, but we shouldnt set more than that
<jarhar> lwarlow: margin -1 feels slightly weird
<jarhar> lwarlow: the other thing with changing to the padding box would be better
<jarhar> lwarlow: it looks less weird
<jarhar> lwarlow: i will say that would break my existing select
<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
<jarhar> astearns: the padding box could be overriden in your case
<jarhar> lwarlow: yes but it doesnt at the moment and it works in production, thats the point - it could break designs
<jarhar> lwarlow: i suspect that design does exist in the wild already, but probalby not too much
<jarhar> lwarlow: thats worth being aware
<astearns> q+
<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?
<jarhar> lwarlow: you still end up with the double border
<astearns> ack masonf
<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
<jarhar> masonf: its fully functional, it just looks weird to most people
<jarhar> masonf: we should just prefer fewer rules to more rules. each rule is a thing for a developer to go undo
<jarhar> masonf: personally i think that if somebody puts out a reset stylesheet for base appearnace then its a failure on us
<jarhar> masonf: it should be minimal enough that its a reset
<keithamus> q+
<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
<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
<jarhar> masonf: primarily my objection is the growth of the ua stylesheet
<jarhar> astearns: i agree with luke, having a -1 hack to solve this doesnt sound right
<jarhar> astearns: contra masons concerns about keeping things simple, the proper way to do that would be have a variable
<jarhar> astearns: do we have css variables in the ua stylesheet? should we never put them in there?
<jarhar> fantasai: yes
<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
<jarhar> masonf: unless the devleoper could change the variable
<astearns> ack astearns
<astearns> ack keithamus
<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
<lwarlow> They're custom properties as well not variables ;) so the UA property is just a property.
<jarhar> keithamus: could css have a border collapse? these two elements, if there adjacent, one of their borders should collapse
<jarhar> keithamus: probably a wild idea, but it would have utility beyond select
<jarhar> fantasai: i think what you want is position-anchor-box
<jarhar> fantasai: not true in the general case where you ahve a sibling relationship, tables do border collapsing
<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
<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
<jarhar> astearns: even though we are going to have a principle about not being weird, thats just one principle to balance against the rest
<masonf> q+
<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
<keithamus> q+
<astearns> ack masonf
<jarhar> masonf: we havent decided to add a non weird thing, we opened an issue to discuss which i will be against
<jarhar> masonf: keep the web weird, i dont think that should be a criteria
<lwarlow> The longer we leave it the larger the compat issue is worth being aware of.
<jarhar> masonf: what you said is right, this property doesnt exist yet
<jarhar> masonf: developers who think this looks weird can use the property
<jarhar> masonf: as we add new stuff to the web, devleopers can use it
<jarhar> masonf: you can use it on customizable select but you dont have to break the web
<lwarlow> +1
<zcorpan> q+
<astearns> ack keithamus
<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
<astearns> ack Zakim
<astearns> ack zcorpan
<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
<masonf> I think the black border looks weird. It should be hotpink.
<jarhar> q+
<astearns> ack jarhar
<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.
<lwarlow> Maybe we can resolve no change?
<masonf> +1
<zcorpan> +1
<jarhar> fantasai: we can come back to this when anchor box stuff is specced
<lwarlow> A can kick is a no change for now at least I guess
<jarhar> astearns: as keith mentioned, we may not be able to use the new thing depending on how long this sticks around
<jarhar> masonf: we should open an issue for changing the ua stylesheet over time when new stuff is added
<jarhar> astearns: we already have a basic principle of not breaking the web and consider bakcwards compat
<jarhar> astearns: in a case by case basis, there may be a way to update base styles that doesnt have compat concerns
<jarhar> proposed resolution: close this no change for now
<masonf> +1
<jarhar> fantasai: ill take that back to the team and look at speccing stuff we had decided a couple years ago
<jarhar> astearns: this anchor thing has been waiting for that long?
<lwarlow> +1
<jarhar> RESOLVED: close this no change for now
<jarhar> annevk: maybe lets not resolve on that for now, we want to check back with the team
<jarhar> proposed resolution: strike that and just leave the issue as-is for now
<lwarlow> +1
<keithamus> +1
<jarhar> RESOLVED: strike that and just leave the issue as-is for now
<masonf> proposed resolution: cancel daylight savings globally