[css-ui] UA stylesheet for appearance:base <select>

[josepharhar]

I'd like to propose a UA stylesheet for <select> which applies when the <select> has size=1, no multiple attribute, and appearance:base.

Based on the discussion here and the proof of concept in the chromium prototype I implemented, we can make these styles only apply when <select> has appearance:base.

Styles from #10908 - the names were resolved, but not necessarily the properties:

select option::check {
  content: '\2713' / '';
}
select option:not(:checked)::check {
  visibility: hidden;
}
select::select-arrow {
  padding-inline-start: 0.5em;
  display: block;
  content: counter(fake-counter-name, disclosure-open);
}

Styles from #10909

select {
  border: 1px solid currentColor;
  background-color: color-mix(in lab, currentColor 10%, transparent);
  color: inherit;
}
select:enabled:hover {
  background-color: color-mix(in lab, currentColor 20%, transparent);
}
select:enabled:active  {
  background-color: color-mix(in lab, currentColor 30%, transparent);
}
select:disabled {
  color: color-mix(in srgb, currentColor 50%, transparent);
}

::picker(select) {
  color: CanvasText;
  background-color: Canvas;
  border: solid;
}

select option:enabled:hover {
  background-color: color-mix(in lab, currentColor 20%, transparent);
}
select option:enabled:active {
  background-color: color-mix(in lab, currentColor 30%, transparent);
}
select option:disabled {
  color: color-mix(in lab, currentColor 50%, transparent);
}

Remaining properties to be resolved on:

select {
  /* Padding prevents the text from sticking to the borders. */
  padding: 0.25em;

  /* These min-size rules ensure accessibility by following WCAG rules:
   * https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html
   * The 1.2em is there to make sure that options without text don't change
   * the block size of the button. */
  min-block-size: max(24px, 1.2em);
  min-inline-size: 24px;

  /* display and box-sizing come from existing UA styles for select which
   * happen to be interoperable. I don't have a strong opinion on keeping
   * them or changing them. */
  display: inline-block;
  box-sizing: border-box;
}

select > button:first-child {
  /* Prevents duplicate box decorations */
  display: contents;

  /* Prevents button activation behavior so select can handle events */
  interactivity: inert;
}

select::picker(select) {
  /* box-sizing is set to match the button. */
  box-sizing: border-box;

  /* Scrollbars in the picker are OK */
  overflow: auto;

  /* This is a stylistic choice from the selectlist element proposal.
   * Without it, we would get padding:0.25em everywhere from
   * the [popover] UA styles. I don't have strong opinions. */
  padding-block: 0.25em;
  padding-inline: 0;

  /* Anchor positioning */
  inset: auto;
  margin: 0;
  min-inline-size: anchor-size(self-inline);
  min-block-size: 1lh;
  position-area: block-end span-inline-end;
  position-try-fallbacks:
    block-start span-inline-end,
    block-end span-inline-start,
    block-start span-inline-start;
}

select option {
  /* These min-size rules ensure accessibility by following WCAG rules:
   * https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html
   * Unset if the author provides a child button element.
   * The 1.2em is there to make sure that options without text don't change
   * the block size of the option. */
  min-inline-size: 24px;
  min-block-size: max(24px, 1.2em);

  /* Centers text within the block (vertically). From OpenUI discussion:
   * https://github.com/openui/open-ui/issues/1026#issuecomment-2103187647. */
  align-content: center;
  display: block;

  /* Padding rules from chromium's pre-existing appearance:auto UA stylesheet.
   * Not currently interoperable. I don't have opinions. */
  padding-block-start: 0;
  padding-block-end: 1px;
  padding-inline: 2px;

  /* From chromium's pre-existing appearance:auto UA stylesheet. Not already interoperable.
   * Not sure what it was for, I'd be happy to change it to normal/unset. */
  white-space: nowrap;
}

select optgroup {
  /* Padding is from chromiums pre-existing appearance:auto UA stylesheet.
   * I don't have opinions, we could remove it. */
  padding-inline: 2px;

  /* font-weight makes optgroups visually distinct from options. */
  font-weight: bolder;
}

select optgroup option {
  /* Padding indents options to visually show which ones are part of the optgroup. */
  padding-inline-start: 20px;

  /* Undo font-weight:bolder rule from optgroups. */
  font-weight: normal;
}

[nt1m]

I would prefer punting this until we've discussed general design principles for appearance: base in #10866 which would influence this issue somewhat. I really believe thinking about this holistically aside outside of just one single form control is important to not repeat mistakes that were previously done.

[nt1m]

Some feedback:

• The checkmark icon deserves its own pseudo (::check? maybe, something that's reusable with for checkbox/radios)
• The dropdown icon deserves its own pseudo (::select-arrow? not super convinced by the name myself, but 🤷 )
• select::picker(select) -> ::picker(select)
• Styles should be minimal: ::picker() probably shouldn't include a box-shadow
• There's a lot of uses of system colors, I know that's prior art, but we're thinking of dropping that for appearance: base across the board, since in 100% of the cases, people want to override it
• There's use of custom fonts, we're also thinking appearance: base should probably just inherit the font for all controls since a custom font probably one of the annoying defaults for form controls.

The last 2 points somewhat link to #10866 , and it might be good to discuss this in person at TPAC to find a set of consistent approaches to make this work holistically across all controls. We have many more ideas that are not covered by this comment alone

[mfreed7]

I would prefer punting this until we've discussed general design principles for appearance: base in #10866 which would influence this issue somewhat. I really believe thinking about this holistically aside outside of just one single form control is important to not repeat mistakes that were previously done.

Love this approach, by the way. I think it's a great idea to set down some guiding principles that we can refer back to as we design all of the controls. I added a few comments on #10866 (comment).

• The checkmark icon deserves its own pseudo (::check? maybe, something that's reusable with for checkbox/radios)

Makes sense. We were fairly conflicted on the use of ::before. One possibility is ::marker but that's got other restrictions that might not make sense for <select> use cases. So maybe ::check or ::checkmark.

• The dropdown icon deserves its own pseudo (::select-arrow? not super convinced by the name myself, but 🤷 )

Makes sense.

• select::picker(select) -> ::picker(select)

Agree.

• Styles should be minimal: ::picker() probably shouldn't include a box-shadow

Likely fine, though the drop-shadow does help users distinguish that this is a popover picker "above" the in-page display. Perhaps we could find a less opinionated set of values?

• There's a lot of uses of system colors, I know that's prior art, but we're thinking of dropping that for appearance: base across the board, since in 100% of the cases, people want to override it

The really nice thing about system colors, though, is that they handle dark mode. We believe the defaults for all controls should work well in both light and dark mode. Instead of system colors, we could use light-dark() but that just feels like more work for not much benefit, when the system colors do that already.

• There's use of custom fonts, we're also thinking appearance: base should probably just inherit the font for all controls since a custom font probably one of the annoying defaults for form controls.

Makes sense, and agree with the annoying defaults comment.

[nt1m]

One possibility is ::marker but that's got other restrictions that might not make sense for <select> use cases.

::marker is linked to display: list-item; so unless we want to make <option> element list-items, I'm not sure it's appropriate. Maybe @fantasai has opinions here :)

The really nice thing about system colors, though, is that they handle dark mode. We believe the defaults for all controls should work well in both light and dark mode. Instead of system colors, we could use light-dark() but that just feels like more work for not much benefit, when the system colors do that already.

There are alternatives that work in dark mode that don't involve light-dark() / system colors, while allowing easy overrides. We can probably discuss this in person at TPAC.

[lukewarlow]

Colours chosen have other configs to potentially account for such as contrast preferences. One other benefit of system colours beyond just light and dark is they automatically adjust when using forced colors mode too. While it's likely to be overridden in most cases, it's possible that base appearance is used in a CSS reset but not actively overridden and imo (though others may disagree) we should make the default base styles as accessible and usable as possible, while maintaining the customisability.

As mentioned though there's alternatives to system colours.

[tabatkins]

The checkmark icon deserves its own pseudo (::check? maybe, something that's reusable with for checkbox/radios)

Could you elaborate on why this is? I don't necessarily object to having a specialized pseudo-element, but the reason we've avoided using ::before/::after in the past for CSS-defined things is the potential for it to conflict with existing author-provided code using those pseudos. That isn't the case here - these are brand new elements, impossible to target by any existing CSS no matter how general.

[nt1m]

The checkmark icon deserves its own pseudo (::check? maybe, something that's reusable with for checkbox/radios)

Could you elaborate on why this is? I don't necessarily object to having a specialized pseudo-element, but the reason we've avoided using ::before/::after in the past for CSS-defined things is the potential for it to conflict with existing author-provided code using those pseudos. That isn't the case here - these are brand new elements, impossible to target by any existing CSS no matter how general.

The developer might choose ::before / ::after to do something else with it (add emojis? fancy selected option indicator? add a counter?), if they find out they need to override the default UA stylesheet usage, it's not really a great experience.

[josepharhar]

Thanks for the discussion! I created separate issues for pseudo-elements and colors:

• [css-ui] Pseudo-elements for checkmark and dropdown icon for appearance:base <select> #10908
• [css-ui] Colors to use for appearance:base <select> #10909

There's use of custom fonts, we're also thinking appearance: base should probably just inherit the font for all controls since a custom font probably one of the annoying defaults for form controls.

So should we set all of the font longhands to inherit? Or initial or another special value? What is "the font for all controls"?

[fantasai]

Set the font properties to unset if you need to; they inherit by default, so ideally just leave them alone.

[css-meeting-bot]

The CSS Working Group just discussed [css-ui] UA stylesheet for appearance:base `<select>` , and agreed to the following:

• RESOLVED: font properties won't be set in the UA style sheet

The full IRC log of that discussion

<chrishtr> jarhar: there has been good discussion in the issue, and I've created two sub-issues for some topics
<chrishtr> jarhar: don't know if there is anything specific to resolve in the issue right now?
<chrishtr> fantasai: we could resolve to inherit the font?
<dbaron> yeah, +1 to inheriting the font
<chrishtr> ntim: think it could be good to delay this discussion to after or during TPAC
<chrishtr> fantasai: agree in general
<chrishtr> q+
<chrishtr> fantasai: also for all form controls and not just select
<astearns> ack fantasai
<chrishtr> jensimmons: would be best to discuss then/later
<chrishtr> jarhar: I'd like to discuss things like which pseudo elements we should add, how to specify colors, ...
<chrishtr> fantasai: let's reschedule so that the breakout is first?
<chrishtr> astearns: we could have tentative discussions at the breakout and then finalize them at the group later
<fantasai> s/breakout is first/breakout agenda is rescheduled into the OpenUI joint meeting/
<sanketj_> https://github.com/whatwg/meta/issues/326
<keithamus> scribe+
<keithamus> chrishtr: while we do want consistent styles, `<select>` is being worked on this year and we need to ensure we don't unreasonably delay decisions based on that.
<keithamus> chrishtr: we can use it as a place to set precedent for the others
<keithamus> astearns: So here is the precedent, but if we make a mistake we can change them as we integrate into the larger set?
<keithamus> chrishtr: sure we can make changes later.
<ntim> (can't talk right now) I'm hoping that TPAC gives enough time to resolve most things regarding UA stylesheets! My goal is more to help drive select's direction not block its progress :)
<jarhar> +1 to using unset for font properties
<ntim> (or not setting the font at all)
<chrishtr> RESOLVED: font properties won't be set in the UA style sheet
<chrishtr> jarhar: this issue was created because accessibility experts are concerned about authors ending up with inaccessibile structures
<fantasai> i/jarhar:/Topic: Content Model/
<fantasai> github: https://github.com/whatwg/html/issues/10317
<chrishtr> jarhar: we should discuss which are allowed so as to preserve accessibility. I worked with accessibility experts from OpenUI and came up with a list of elements which should be allowed within select: divs, spans, img, text within options but outside
<RRSAgent> I have made the request to generate https://www.w3.org/2024/09/19-css-minutes.html fantasai
<chrishtr> jarhar: and legend elements as child of optgroup to replace label
<chrishtr> jarhar: this has the same a11y mapping but is more styleable
<jarhar> q?
<astearns> ack chrishtr
<emilio> q+
<chrishtr> jarhar: my HTML spec PR is ready to go so from my perspective it's ready. should we go with this approach?
<astearns> ack emilio
<chrishtr> emilio: curious if we're going to have special rendering for legend like we have for fieldset, or are there any other special rendering rules?
<astearns> pr: https://github.com/whatwg/html/pull/10586
<chrishtr> emilio: if you put a legend into a fieldset the the rendering is quite special. the first thing gets moved up to the top regardless of where it is in the DOM, and other layout tree reparenting.
<chrishtr> emilio: hoping we don't have to do any of that
<astearns> q+
<chrishtr> jarhar: my preference is also not to do anything special. didn't come across any need to have special rendering in prototyping in Chromium. I just set up the a11y mappings and changed the rendering of the optgroup element so it would stop rendering the label attribute part when there is a legend child
<chrishtr> fantasai: on the PR: it says div and span, but not various other elements like em or bdo. why not?
<chrishtr> jensimmons: there are so many other elements that seem reasonable?
<chrishtr> fantasai: ruby also
<chrishtr> jarhar: these are good points and should be included within option elements. these rules are about content outside option elements.
<astearns> ack fantasai
<chrishtr> jarhar: maybe we can use a more broad rule for inside-option parts
<chrishtr> fantasai: span or other inline elements don't belong outside option
<chrishtr> fantasai: div allowed but not span because span is inline
<chrishtr> astearns: are there tests?
<chrishtr> jarhar: the tests for the content model: not sure how to do that. in the Chromium implementation, we render everything but use developer tooling to guide people towards accessible outcomes. tl;dr I don't know how to test it in WPT.
<astearns> ack astearns
<astearns> zakim, end meeting

[josepharhar]

I took @nt1m's styles from webkit for buttons and put them in the OP, as well as our last resolution on inheriting fonts.

[josepharhar]

Based on the discussions so far, it sounds like we probably shouldn't have a box shadow, so I am removing that from the proposed styles in the OP. I'm also replacing ::before and ::after with ::check and ::select-arrow

[josepharhar]

I updated the issue description to separate the styles which are being discussed/resolved in other issues and the styles which still need review/resolutions. Please take a look and let me know if yall have any recommendations!

[josepharhar]

I added comments to all of the properties in the "still need review/resolutions" portion of UA styles in the issue description. Please take a look!

[css-meeting-bot]

The CSS Working Group just discussed [css-ui] UA stylesheet for appearance:base `<select>` .

The full IRC log of that discussion

<chrishtr> jarhar: have a list of additional properties proposed for the UA stylesheet. Think we should just go through them one-by-one.
<chrishtr> first rule: padding: 025em
<chrishtr> without this rule, the text in the button would stick to the borders, this centers it
<chrishtr> there is a caveat that it changes to 0 if the developer provides a child button element. That is there because if the the developer provides it, then we should just use that button and not add on extra box deccoration
<chrishtr> emilio: the select has a border right?
<chrishtr> jarhar: going to propose to remove the border actually
<chrishtr> jarhar: that way you don't have two borders
<chrishtr> jarhar: this was discussed on a separate issue with tim
<jensimmons> q+
<astearns> ack fantasai
<emilio> q+
<chrishtr> fantasai: what is the box model we're trying to style in this case? what boxes exist and what formatting context does it have? Is the select a bock box or a flexbox.
<chrishtr> jarhar: display: inline-block should answer that question (there is a proposed UA rule for it)
<chrishtr> fantasai: and it directly contains text? and if there is a provided button it shows the button?
<chrishtr> fantasai: there was a discussion about a pseudo elements, where did that go?
<chrishtr> jarhar: we decided not to have a fallback UA pseudo element in this case, and instead the select element itself should be it
<chrishtr> fantasai: if there is a button element, is block layout what you want for it? don't think so because we want the button to align with the border right?
<chrishtr> jarhar: yes
<chrishtr> jarhar: think we could do several adjustments if the button is there
<annevk> (display: contents might make focus funky too)
<chrishtr> fantasai: from an author's perspective should not see things change just because you added markup
<masonf> What if we add `select>button {border:0; padding:0}` instead? And leave select's borders and padding.
<emilio> `select > button { display: contents }`? :)
<astearns> ack jensimmons
<fantasai> or maybe select > button { display: contents; }
<chrishtr> jensimmons: interesting that we have styling that depends on content
<chrishtr> jensimmons: don't know of another case that works that way
<chrishtr> jensimmons: not sure if authors would be confused by that or not
<chrishtr> jensimmons: for the sake of these conversations more visuals would be n ice
<astearns> q+
<chrishtr> jensimmons: don't know what to think right now but want to help get it done, there might be bikeshedding.
<masonf> Some common examples and use cases are detailed here: https://developer.chrome.com/blog/rfc-customizable-select
<chrishtr> jensimmons: can't tell
<astearns> ack emilio
<chrishtr> emilio: maybe the button shouldn't have decorations and should delegate that to the select element. display:contents on the button
<chrishtr> emilio: that may be a simpler option that avoids magic
<chrishtr> emilio: also have feedback on the min sizing
<keithamus> q+
<chrishtr> emilio: 24px may be too big
<chrishtr> emilio: white-space: normal seems find
<chrishtr> emilio: 2px block and 1px inline padding already exists?
<chrishtr> emilio: overall, the fewer rules the better
<chrishtr> emilio: display:contents could explain has behavior
<annevk> q+ to bring up the topic of how this relates to base styling of other controls
<masonf> q+
<chrishtr> emilio: maybe also make it !important
<astearns> ack fantasai
<chrishtr> fantasai: agree display: contents on the button make sense
<chrishtr> fantasai: no need for !important
<chrishtr> fantasai: considering pixel values for padding, I am in favor of em because it'll scale with font sizing
<chrishtr> fantasai: font-relative is good
<annevk> (.25em seems quite big, that's 4px)
<chrishtr> fantasai: not sure why 0.25, where did that come from?
<fantasai> s/0.25/1.2em/
<dbaron> many of these things are based on the existing UA stylesheet rules for <select>
<chrishtr> emilio: agree that em paddings are nicer. but also think that if we can avoid making different appearance:base specific CSS values that's better. the less differences the better.
<chrishtr> emilio: if existing padding is ok then let's try to accept it
<jarhar> q?
<jensimmons> q+
<chrishtr> astearns: uncomfortable with having a switch on select content that is not expressed in the UA stylesheet
<emilio> `select:has(> button) { ... }` should work
<chrishtr> astearns: if we have things in the UA style sheet that depends on some state we should avoid that and fix it
<astearns> ack astearns
<ntim> I like Elika's suggestion of making button display: contents
<annevk> (I agree with that to an extent, there's definitely things that are just not worth generalizing to CSS syntax.)
<jensimmons> Totally agree with Alan — secretly putting a switch to the styles in the engine is even more magical. It can totally be done in CSS.
<chrishtr> keithamus: in favor of the rule as it stands. 24px minimum size is useful. should consider a11y, and WCAG recommends that
<chrishtr> keithamus: I'd prefer even larger but smaller gets quite problematic
<masonf> Rule #3 here says we need to follow WCAG: https://github.com//issues/10866
<annevk> (E.g., detecting iso-8859-8-i.)
<chrishtr> keithamus: 0.25em is also good, a lot of design systems use it
<chrishtr> keithamus: need good defaults for modern-day practices and a11y practices. This is an opportunity to set good defaults.
<astearns> +1 to not always following current styling
<fantasai> strong +1 to keithamus
<chrishtr> keithamus: should avoid making it too complicated, but since it's easy for authors to customize it doesn't get in their way
<annevk> Can't it just be `select > button`?
<chrishtr> keithamus: display: contents is problematic, might be confusing to developers. also might have a11y problems
<chrishtr> keithamus: if you have a button in the select then probably the button should be in the AT, but if it's display:contents that would mess this up
<astearns> q?
<astearns> ack keithamus
<astearns> ack annevk
<Zakim> annevk, you wanted to bring up the topic of how this relates to base styling of other controls
<chrishtr> annevk: one meta point is that as we decide on these rules it'll have implications for base styles for other controls
<chrishtr> annevk: if we decide padding or sizing here then it should make sense for other controls
<chrishtr> annevk: don't want to have to revisit for other form controls
<chrishtr> annevk: with regards to display: contents, there are a lot of implications of display: contents for focus and so on that make it tricky
<chrishtr> annevk: if you just use a child selector then we could override its border and padding to be 0?
<emilio> So `select > button { appearance: none; padding: 0; border: 0 }`?
<chrishtr> annevk: if you're styling this button will its appearance be?
<astearns> ack masonf
<chrishtr> mason: one rule we're following is to follow WCAG, which is where 24px came from
<chrishtr> s/mason/masonry/
<chrishtr> s/mason/masonf/
<chrishtr> masonf: agree that we could have a rule like what Emilio wrote to remove appearance and put 0 padding and border
<jensimmons> q-
<chrishtr> jarhar: the way we implemented it is that if the button is present then focus delegates to it, including focus rings
<chrishtr> jarhar: if there is no button then the select element itself gets the focus
<emilio> display: contents on the button seems like a nicer fix for the focus issue tbh :)
<emilio> q+
<chrishtr> masonf: others said let's inherit padding when possible from appearance: auto. I think we should fix them to be good.
<astearns> ack fantasai
<Zakim> fantasai, you wanted to disagree with emilio, our priority should be to be a good, accessible, interoperable base for styling, not consistent with existing styles
<annevk> I think if the `button` is being styled in the UA style sheet we need to figure out `appearance: base` for it.
<astearns> +1 to not making !important rules in the UA stylesheet if we can avoid it
<annevk> (I use webirc.w3.org and it keeps dropping me from the channel. I wish we'd use something that's not IRC.)
<chrishtr> fantasai: wanted to agree with Mason's sentiment that we should not optimize for avoiding rules that override auto, we should instead make a good and consistent base style without worrying about auto
<keithamus> q+
<chrishtr> fantasai: the button stuff sounds really confusing, since if you have a button you have to style that and not the select, and if not the select.
<chrishtr> fantasai: the button should be a markup extra that somehow doesn't need that complication
<astearns> ack emilio
<chrishtr> fantasai: if the purpose of the button is to clarify hierarchies then limit to that, and make it display: contents !important
<chrishtr> emilio: happy to concede on the padding
<fantasai> +1 emilio
<chrishtr> emilio: the focus shenanigans: display: contents would be simpler. then the rules for outlines would be simpler, since you'd always focus the select and not the button
<astearns> ack keithamus
<chrishtr> keithamus: one thing we might consider is that this is going to get integrated into sites that already have a lot of CSS, including around buttons
<chrishtr> keithamus: they will also have CSS around focus, active, etc
<masonf> q+
<chrishtr> keithamus: making the button a transparent part of the select might be a moot point, because the author is going to have button styling already in their theme, which they'd have to undo
<astearns> ack masonf
<chrishtr> masonf: following on that, if it was a custom element, you'd likely do the thing where you delegate styling. feels odd to have HTML that has a button and the button is not a regular button
<jarhar> q?
<chrishtr> masonf: display: contents seems weird from that perspective
<jarhar> q+
<ntim> q+
<astearns> ack jarhar
<annevk> What's the use case for the custom button? How does display: contents not invalidate that use case?
<chrishtr> jarhar: back when we were working on earlier iterations for this project, there was a way to put anything you want into the slot. now that I'm hearing people express concerns about different ways to handle this button, I'm thinking the original model was quite nice. could we go back to that?
<chrishtr> jarhar: we can't reuse the slot element, but maybe a new element or concept?
<jensimmons> No, we should use <button> not a <div> + new slot thing.
<chrishtr> annevk: the slot API is a web developer API.
<jensimmons> q+
<chrishtr> annevk: don't care about the button element that much, it's the content?
<chrishtr> annevk: maybe an appearance:base button could help?
<astearns> ack ntim
<chrishtr> ntim: before thinking about the styles with the button case, want to step back - what use cases will people use buttons for?
<chrishtr> ntim: if it's used for a split button then display: contents is probably not right
<keithamus> q+
<chrishtr> ntim: would be nice to see a list of use cases
<masonf> Some examples with custom buttons here: https://developer.chrome.com/blog/rfc-customizable-select
<chrishtr> jarhar: the main purpose of the button is to allow the developer to provide a way to put anything they want in the base element
<chrishtr> jarhar: a big use case is declaratively copying the selected option into the button
<chrishtr> jarhar: without providing them with a button, it precludes them putting their own or rich content into the in-page select element part
<chrishtr> jarhar: without doing this we'll miss most use cases
<masonf> q+
<chrishtr> ntim: does it allow for split buttons?
<chrishtr> jarhar: there has been a lot of discussion at OpenUI with experts
<annevk> q+ why do we need both button and selectedoption?
<annevk> q+ to ask why do we need both button and selectedoption?
<chrishtr> jarhar: split buttons have different a11y mapping, and they recommend using a completely different element for that, so split buttons is out of scope at the moment
<astearns> ack jensimmons
<chrishtr> jensimmons: an interesting thing about this project is understanding what it means to make a UA stylesheet. definitely think padding should be font-dependent. But if I we designing a design system I'd use line height units.
<chrishtr> jensimmons: we're trying to fix some decisions made back in the 90s
<annevk> q-
<chrishtr> jensimmons: we're not making the world's best design system though, just providing a base styling. might not be the perfect thing for them, but to find a way to match the new with the old
<chrishtr> jensimmons: without confusing authors
<astearns> ack keithamus
<chrishtr> keithamus: to extend on that point, we're not building this for people who are building on design systems or building a design system, these are defaults. design systems will very likely override most of these.
<chrishtr> keithamus: need to make sure it has accessible defaults, and that the styles aren't too difficult to override
<ntim> If the only use case is for the button is selectedoption, it makes sense to me from a styling perspective that button gets `display: contents`
<astearns> ack masonf
<fantasai> In that case, wouldn't you just style select { display: flex; } ?
<chrishtr> masonf: roughly +1 to what jen and keith said. agree authors will reset it. Minimal is better.
<chrishtr> masonf: we've been staring at this screen for an hour, but it's a quarter of the entire proposed style sheet
<chrishtr> masonf: suggest we iterate in the issue instead of live
<keithamus> it might be worth testing it against a bunch of popular CSS Reset libraries to ensure they don't break it in bad ways
<chrishtr> astearns: want to amplify Joey's point that the justification is in the comment, please reply on the issue

[annevk]

One thing that this illustrates to me is that we need to think about the other controls as well as we don't want the styles for select to be inconsistent with button for instance. (And in fact we potentially have to figure out button in order to allow it to be nested inside select.)

[josepharhar]

Based on the discussion last week, I made the following changes:

• Set display:contents on the button in order to remove duplicate box decorations as a replacement for removing box decorations for the select element when there is a child button because changing styles based on the child button got negative feedback.
• Set interactivity:inert on the button (made possible by this resolution) in order to move event handling from the button to the select element. This also allows us to remove a bunch of hacks to make the button work, such as using delegatesFocus on the select element, in Define base appearance for <select> whatwg/html#10629