[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::checkmark {
  content: '\2713' / '';
}
select option:not(:checked)::checkmark {
  visibility: hidden;
}
select::picker-icon {
  /* margin-inline-start pushes the icon to the right of the box */
  margin-inline-start: auto;
  display: block;
  content: counter(fake-counter-name, disclosure-open);
}

Styles from #10909

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

::picker(select) {
  /* Same properties as popover and dialog */
  color: CanvasText;
  background-color: Canvas;
  border: 1px solid;
}

select option:enabled:hover {
  background-color: color-mix(in lab, currentColor 10%, transparent);
}
select option:enabled:active {
  background-color: color-mix(in lab, currentColor 20%, 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.
   * optically centered to account for half leading */
  padding-block: 0.25em;
  padding-inline: 0.5em;

  /* Match <button> */
  border-radius: 0.5em;

  /* 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, 1lh);
  min-inline-size: 24px;

  /* box-sizing comes from existing UA styles which happen to
   * already be interoperable. */
  box-sizing: border-box;

  /* Push picker icon to the right of the box and have some space
   * in between it and the text. */
  display: inline-flex;
  gap: 1em;
}

select > button:first-child {
  /* Prevents button from setting font, color, or background-color */
  all: unset;

  /* 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;

  /* Remove [popover] padding which
   * prevents options from extending to edges */
  padding: 0;

  /* Anchor positioning and scrollbars */
  inset: auto;
  margin: 0;
  min-inline-size: anchor-size(self-inline);
  min-block-size: 1lh;
  /* Go to the edge of the viewport, and add scrollbars if needed. */
  max-block-size: stretch;
  overflow: auto;
  /* Below and span-right, by default. */
  position-area: block-end span-inline-end;
  position-try-order: most-block-size;
  position-try-fallbacks:
    /* First try above and span-right. */
    block-start span-inline-end,
    /* Then below but span-left. */
    block-end span-inline-start,
    /* Then above and span-left. */
    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 1lh 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, 1lh);

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

  /* centering + gap between checkmark and option content */
  /* also easily reversed, when checkmark should be inline-end */
  display: flex;
  place-items: center;
  gap: 0.5em;

  /* Makes options with long text widen picker instead
   * of making options tall. */
  white-space: nowrap;
}

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

select optgroup option {
  /* Undo font-weight:bolder rule from optgroups. */
  font-weight: normal;
}

select legend,
select option {
  /* spacing ownership moves to children */
  /* space inline from border edges */
  /* this creates a full bleed hover highlight */
  padding-inline: 0.5em;
}

[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

[brechtDR]

I really don't like the button having an all: unset with the latest UA style update. It creates a confusing developer experience as most will expect a button to have certain things, such as a display property set to inline-block, letting you add paddings right away.

[nt1m]

I really don't like the button having an all: unset with the latest UA style update. It creates a confusing developer experience as most will expect a button to have certain things, such as a display property set to inline-block, letting you add paddings right away.

Not sure where you see all: unset?

[josepharhar]

I really don't like the button having an all: unset with the latest UA style update. It creates a confusing developer experience as most will expect a button to have certain things, such as a display property set to inline-block, letting you add paddings right away.

Not sure where you see all: unset?

I just added it to the issue description. It came out of my code review to add display:contents in chromium. I added a comment explaining why it is needed.

[nt1m]

I really don't like the button having an all: unset with the latest UA style update. It creates a confusing developer experience as most will expect a button to have certain things, such as a display property set to inline-block, letting you add paddings right away.

The idea is that select is where you should set your button styles (because that's always how it's been...).

[brechtDR]

I just added it to the issue description. It came out of my code review to add display:contents in chromium. I added a comment explaining why it is needed.

I understand the reason behind it, but I feel like it's "one more caveat" that people will trip over a few times.

for example, a developer might quickly start prototyping something :

select > button { 
  padding: 1cqmin; 
  border: 1px solid #c0ffee; 
}

After doing that, a developer goes to watch the change on the page and wonders why the button doesn't have padding. Looks it up and finds out that he/she needed to add the display property, in contrast to a button anywhere else, where user-agent styles are set to display: inline-block.

That being said, I'm not trying to push on changing this, but I believe it is something we should be aware of when going forward with this. It can potentially be a common pitfall / frustration for developers, especially at first. It's at the least going to bring a small amount of confusion.

[fantasai]

On the contrary, one of the benefits of select > button { display: contents; } is that it means if you add a <button> inside the select markup, you won't accidentally pick up the generic button { ... } border/background/etc. styles that currently only apply to standalone buttons. And as @nt1m notes, the developer trying to style the button really should be styling the select anyway.

[josepharhar]

I just updated the UA styles again with some changes I worked on with @argyleink mostly to remove small px padding rules and using flex on the select and options to make ::picker-icon and ::checkmark push to edges and easier to use.

[josepharhar]

I talked with @nt1m and @fantasai about the proposed styles from my last comment and got some feedback:

• use margin-inline-start:auto instead of justify-content:space-between to push the ::picker-icon to the right
• remove the 1px margin at the top of the picker which was used to separate the borders of the picker and the button
• padding-inline on options and padding-block/padding-inline on button looks good
• borders of picker and button should be consistent and they should be 1px (picker uses the initial value)
• border-radius, if we use it, should be in em units instead of px, like 0.25em

I plan on incorporating these into the proposed styles

[css-meeting-bot]

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

The full IRC log of that discussion

<gregwhitworth> jarhar: presents presentation
<chrishtr> If you have any questions or feedback about Joey's deck, feel free to post them here and we can discuss async / on the GitHub issue.
<argyle> margin-inline-start instead of justify-content, how come? justify-content will continue to work if authors put checkmarks on the inline-end, where inline-start only works for checkmarks at the start
<emilio> Can we avoid flex / border-radius? The less we change the general layout model the better, IMHO...
<dbaron> fantasai: ...
<dbaron> fantasai: Advantage of background-color is it's something authors will almost always override. IF we do put a background color it's more likely to run into color contrast than if we use a border-radius.
<brecht_dr> q+
<dbaron> fantasai: We should try to make minimal differences. I'd probably go with a or b and not c so there's fewer things to override.
<dbaron> brecht_dr: I agree with ??
<dbaron> brecht_dr: Resetting things gets tedious, fewer things to reset is better.
<masonf> title: foo
<fantasai> Slides for this session: https://lists.w3.org/Archives/Public/www-archive/2024Nov/att-0003/appearance-base-colors.pdf

See Joey's slide deck

Open Questions

• Should we visually distinguish buttons and inputs somehow?
  • Use border-radius: 0.25em.
  • Use background: /* mostly translucent currentcolor color-mix() */.
  • Use border-radius + background-color.
  • Use neither; keep the styles absolutely minimal.
• If we distinguish buttons and inputs, which one should select look like?
  • Like buttons.
  • Like inputs.

For the first question, the advantage of using background only is that authors will almost always want to override it anyway, so it rarely needs an extra reset. The disadvantage is that, unlike border-radius, it will impact the color contrast.

[fantasai]

Comments on some of the stylesheet details.

• I think ::picker(select) should be minimally styled and match all other pickers, so probably shouldn't have border-radius.
• align-content and place-content are redundant, since align-content is a shorthand of place-content.
• We should have a consistent gap value, not 1em one place and 0.5em in the other. :)

[josepharhar]

Thanks for the feedback @fantasai !

From irc:

emilio: Can we avoid flex / border-radius? The less we change the general layout model the better, IMHO...

@emilio Can you elaborate on why using flex is not ideal? I think it greatly improves the ::picker-icon by pushing it to the end of the box. If we don't do that with flex, is there another way to do that?

border-radius I'm going to have a harder time defending, but yeah was an open question about styling buttons in appearance:base.

[tabatkins]

Yeah, I think using inline-flex is pretty much a necessity here. It is simply the case that inline-block is not sufficient to do any real UI layout; flex is table-stakes for this sort of thing.

border-radius I'm less pressed about.

Use background: color-mix(current-color ...).

By the by, this is an unusable value. The partial transparency means the button background is mostly the underlying background color; if that (an unpredictable value) doesn't contrast with the text, the text becomes unreadable. This only looks reasonable because, in your demos, the underlying background is white, which contrasts with the black text.

What you actually want is color-mix(currentcolor 10%, contrast-color(currentcolor max)) or similar.

[josepharhar]

I think ::picker(select) should be minimally styled and match all other pickers, so probably shouldn't have border-radius.

Done

align-content and place-content are redundant, since align-content is a shorthand of place-content.

Thanks for pointing this out, I removed align-content

We should have a consistent gap value, not 1em one place and 0.5em in the other. :)

I changed them to both be 0.5em

[nt1m]

Use background: color-mix(current-color ...).
By the by, this is an unusable value. The partial transparency means the button background is mostly the underlying background color; if that (an unpredictable value) doesn't contrast with the text, the text becomes unreadable. This only looks reasonable because, in your demos, the underlying background is white, which contrasts with the black text.

That is how the system is meant to work. currentColor over transparency is supposed to work as long as you do the right thing on the parent element. The point here is like it works mostly like putting a plain <div> on the page.

FWIW, the only point of the semi-transparent background-color was to differentiate buttons from inputs, but I'm also OK just going full transparent, and just use the border-radius to differentiate buttons from inputs.

[tabatkins]

That is how the system is meant to work. currentColor over transparency is supposed to work as long as you do the right thing on the parent element. The point here is like it works mostly like putting a plain

on the page.

Okay, but that's not how buttons, inputs, or selects work. You can safely use those over any background, without having to set their color/background at all, because they all have opaque backgrounds. Using transparency to mimic the appearance of buttons in some conditions doesn't seem great; it's certainly novel, and I think we need a pretty good justification for this novelty, versus the standard patterns of either "fully opaque default color" or "fully transparent".

(I don't have an opinion about whether they should be opaque or transparent, I just don't like this novel "mostly transparent" style.)

[josepharhar]

Open Questions

• Should we visually distinguish buttons and inputs somehow?

  • Use border-radius: 0.25em.
  • Use background: /* mostly translucent currentcolor color-mix() */.
  • Use border-radius + background-color.
  • Use neither; keep the styles absolutely minimal.

• If we distinguish buttons and inputs, which one should select look like?

  • Like buttons.
  • Like inputs.

I think that select should look like a button, and that buttons should be distinguished from inputs by just having a border-radius, and they should share a fully transparent background with inputs. Hover and active styles for buttons can still use color-mix().

[css-meeting-bot]

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

• RESOLVED: have the same border radius for base appearance for selects and buttons, conditional on giving others not present a week to review.
• RESOLVED: use transparent background color for base appearance selects, buttons, and inputs

The full IRC log of that discussion

<keithamus> jarhar: we discussed colors last time. Some discussion in the thread; fantasai made a nice list. I made a recent comment to use the same background color for both and distinguish with border radius only
<keithamus> jarhar: I;d like to get a resolution if possible
<fantasai> https://github.com//issues/10857#issuecomment-2515767151
<keithamus> annevk: Tim and Jen aren't here - can we do a tentative resolution to hear feedback from them?
<keithamus> astearns: we'll often take a full resolution with the caveat in it, waiting to act until people are able to take a look
<keithamus> annevk: thats workable
<keithamus> astearns: so one at a time, jarhar suggested we _only_ use border radius, not background or color to distinguish. Can you go into reasoning?
<keithamus> jarhar: alternative to using same background to both is inputs having transparent, and buttons having color mix.
<keithamus> jarhar: in some offline discussions I recall Tim making it fully transparent, also Tab likes fully transparent more. It sounds fine.
<keithamus> jarhar: People seem to have a preference for fully transparent.
<keithamus> astearns: So background and background color out because of the transparency possibility? Border radius was the original option presented, is there anything beside radius?
<keithamus> jarhar: good question
<keithamus> astearns: not opposed, just want to make sure we're deciding right
<fantasai> Could use box-shadow
<lwarlow> q+
<keithamus> jarhar: with the objective in mind of trying to use background-color for select - why I'm interested in this resolution - I'm not saying we can't make further distinctions but I'd like to settle on border-radius/background color
<astearns> ack lwarlow
<keithamus> lwarlow: my preference would be buttons/inputs/selects all have the same base style. I'm not sure adding border-radius facilitates anything?
<keithamus> lwarlow: background color doesn't change anything... border radius is going to be changed. I don't think it makes sense to have a default.
<keithamus> lwarlow: open question of should we distinguish them; probably no from me. A uniform look for interactive elements.
<keithamus> q+
<keithamus> lwarlow: inputs have popups with their own inputs, an input isn't that different to a select.
<jarhar> keithamus: im not disagreeing with luke but i think border radius is fine. other thing is text align right? i imagine that text align center is on buttons and selects and text align left is on inputs. is that something that we're going to do?
<fantasai> +1 to text-align
<keithamus> masonf: text align start in select, button is unset.
<fantasai> +1 to astearns's point
<keithamus> astearns: we can certainly consider it as part of the stylesheet but not a distinguishing mark
<lwarlow> Personally I see text-align start more for selects and inputs but not for button
<keithamus> astearns: I think in most cases inputs are start aligned, but text aligned is inherited from other content - so a UI centered aligned will have centered aligned inputs
<jarhar> q?
<masonf> q+
<keithamus> ack keithamus
<jarhar> q+
<keithamus> annevk: if you have an input element with an initial value and you have a button can you distinguish by just looking at them?
<keithamus> annevk: if they just have a border?
<astearns> ack masonf
<keithamus> masonf: to clarify, we seem to have agreed we're not using the 10% background and going fully transparent?
<keithamus> astearns: that's my understanding
<keithamus> masonf: the thing I wanted to say, being able to distinguish inputs vs buttons vs selects - the one that seems special is the button. Clicking on others isn't destructive, a button _does_ something, you click on it and oops it was a submit button
<keithamus> masonf: making input/select is fine, and we should focus more on button for this discussion
<astearns> ack jarhar
<keithamus> jarhar: my goal was to align selects with buttons as opposed to inputs
<keithamus> jarhar: in the interests of distinguishing between the two, border radius is a good way to do that, since it's on the table right now. As for text-align I haven't explored in a ton of detail. Some content to think about.
<lwarlow> q+
<keithamus> jarhar: Right now just interested in the border color, background color, border radius
<keithamus> jarhar: so are people okay with border radius?
<astearns> ack lwarlow
<keithamus> astearns: I suspect people are fine with not changing background colro
<keithamus> astearns: I suspect people are fine with not changing background color
<keithamus> lwarlow: 0.25 and 0 are effectively the same - I can't tell the difference with my eyesight. If we want to distinguish them we should also use a colour
<keithamus> fantasai: thats a quarter of a font-size. Should be significant
<keithamus> lwarlow: my eyesight might be bad
<keithamus> annevk: 4 css pixels? Not a whole lot.
<keithamus> q+
<astearns> ack keithamus
<keithamus> keithamus: font-weight: bold might be useful in addition too
<fantasai> We could do 0.5em
<fantasai> https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22border%3A%20solid%201px%3B%20padding%3A%200.25em%3B%20border-radius%3A%200.5em%22%3Etest%3C%2Fdiv%3E
<keithamus> masonf: buttons with more border radius to make it look different - half an em for the button to show its really rounded could show it's different.
<keithamus> annevk: I would assume we'd use the same style for button and select
<keithamus> annevk: I'm concerned about the distinction between text controls and buttons
<keithamus> annevk: can you click it vs edit it is a thing you might want to tell by looking at it
<keithamus> masonf: but for the user nothing scary about - if you click it and nothing bad happens
<keithamus> q+
<keithamus> masonf: you can abort without penalties
<keithamus> masonf: but button is scary
<fantasai> +1 masonf
<keithamus> annevk: but last time we came to the conclusion that select style impact how we style button
<fantasai> s/you can/for select, you can/
<lwarlow> q+
<keithamus> annevk: if we only use border radius to distinguish, is that sufficient or not?
<keithamus> annevk: the select concerns get grouped with button
<keithamus> annevk: select could look like a text input... I thought jarhar was also doing that
<keithamus> masonf: cursor style tells you a bit about it too
<astearns> ack keithamus
<jarhar> keithamus: select and buttons have visually distinct style because of dropdown marker. but also to masons point of buttons doing the dangerous thing, i think it is ambiguous. if we are deciding based on that factor, buttons don't always do the dangerous thing. a lot of buttons in websites are to build select equiavelent things. to annes point,
<jarhar> there is validity in making combobox and select visually distinct. one of those is ediable and one is read only. there should be a distinction. theres a caret but thats not sufficient
<jarhar> keithamus: both points are correct to a degree, but theres probably additional distinguishing things to add.
<jarhar> keithamus: text inputs we can have them as border with no border radius with no background, normal font weight
<jarhar> keithamus: select could be styled like a button. but we know that selects arent going to be dangerous because they have visual treatment
<jarhar> keithamus: combobox needs to look like a mish mash of the two. have the triangle but look like an input?
<jarhar> keithamus: buttons need to have a style but authors can decide how dangerous theyre going to be and they can style them
<jarhar> keithamus: thats how i see it. i think we should have a very distinguishable style for buttons and selects should look like buttons. editable form controls should have a distinguishable style
<astearns> ack lwarlow
<keithamus> lwarlow: keithamus touched on some of what I am thinking; buttons aren't always dangerous. customisable select is very literally a button that opens a popover. I think that we're using a button element in a select says they should be treated relatively similar
<keithamus> lwarlow: border radius alone is _probably_ enough, we just need to figure out a value
<keithamus> lwarlow: something masonf touched on around the cursor is a good point too
<keithamus> qq+
<astearns> ack keithamus
<Zakim> keithamus, you wanted to react to lwarlow
<keithamus> ack keithamus
<keithamus> fantasai: I think 0.5em would be a better size for border radius
<keithamus> fantasai: masonf's point was compelling on where to use it. That's all I have
<masonf> So the variables we have available to distinguish input, select, button are: border-radius, text-align, cursor, and the presence of ::picker-icon.
<keithamus> astearns: sounds like we're converging on select and buttons using the same border-radius
<emilio> +1 on making buttons and select the same
<keithamus> masonf: should background-color be included in that?
<jarhar> proposed resolution: have the same border radius for base appearance for selects and buttons, conditional on giving others not present a week to review.
<keithamus> +1
<dandclark> +1
<masonf> +1
<fantasai> wfm
<keithamus> emilio: +1 on making select/button similar, but I am still uneasy about adding border-radius only on appearance base. The more computed value time dependencies we add the more we complicate reasoning about css.
<keithamus> astearns: can you describe cvt issue you're seeing?
<keithamus> emilio: appearance effecting border-radius
<keithamus> emilio: either with magic css that UAs can only use or with magic adjustments after we've.... it feels very odd
<keithamus> emilio: it makes dependency tracking between properties more annoying
<keithamus> emilio: I'd like to change as little as possible for appearance base styles
<jarhar> q+
<astearns> ack fantasai
<keithamus> annevk: yeah I feel like we're revisiting old ground. appearance base opts into new ground where you can apply with an internal at-rule or a value function to open the ability to make a good default style sheet for these controls
<keithamus> annevk: if we need to litigate each property for the improved style sheet that's gonna take up a lot of time
<keithamus> emilio: its something we can do when we think its needed but border-radius is presentational.
<keithamus> astearns: so while we're not re litigating the entire idea of a style sheet we should be conservative about it
<keithamus> masonf: we should think of it as a new control but not be chained to the past.
<fantasai> +1 to masonf
<masonf> q?
<keithamus> annevk: the discomfort for me is not so much... the argument from emilio seems to be implementation difficulty, not that border-radius is bad for these controls. I have a problem with that argument, not how conservative we are
<keithamus> annevk: I have a problem with saying no against a property because it's hard to implement
<emilio> not implementation difficulty
<astearns> ack jarhar
<emilio> More like hardness of reasoning about it as an author
<masonf> q+
<keithamus> jarhar: making properties change based on appearance has been implemented in chrome for some time now, at first it was more complicated due to the css parser changes needed, but Andrej from the style team did a refactor that made all the magic parsing go away and we have a new internal base appearance thing for pretty much any property
<keithamus> jarhar: I did need to set the appearance base to be a high priority property but it's worked so far and I'm using it a lot and it's working great. I have no worries with changing any of these properties we're discussing
<astearns> ack masonf
<keithamus> masonf: I think authors won't think about the magic required, they'll just look at the new styles
<keithamus> q+
<astearns> ack fantasai
<keithamus> fantasai: from an author perspective you're switching between two different style modes. There's no intra-property dependencies, it's just a different base style sheet.
<jarhar> keithamus: we have two concreate user bases here. one is theyre never going to customize anything and they need sensible defaults. anyone who is going to customize these styles, theyre going to customize as much as they need to. if they need to change the border radius they will
<jarhar> fantasai: its also an obvious one to change
<astearns> proposed resolution: have the same border radius for base appearance for selects and buttons, conditional on giving others not present a week to review.
<keithamus> +1
<masonf> still +1
<jarhar> +1
<jarhar> RESOLVED: have the same border radius for base appearance for selects and buttons, conditional on giving others not present a week to review.
<jarhar> proposed resolution: use transparent background color for base appearance selects, buttons, and inputs
<keithamus> +1
<masonf> +1
<fantasai> +1
<lwarlow> +1
<jarhar> RESOLVED: use transparent background color for base appearance selects, buttons, and inputs

[nt1m]

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

• RESOLVED: have the same border radius for base appearance for selects and buttons, conditional on giving others not present a week to review.
• RESOLVED: use transparent background color for base appearance selects, buttons, and inputs

The full IRC log of that discussion

Sounds good to me.

[emilio]

I just realized that some of the "either magic at-rule or appearance-base-based value" might be observable via revert, right? What is the behavior of the magic at-rule wrt revert?

cc @nt1m @josepharhar

[nt1m]

I just realized that some of the "either magic at-rule or appearance-base-based value" might be observable via revert, right? What is the behavior of the magic at-rule wrt revert?

cc @nt1m @josepharhar

Can you file a new issue about the behavior of revert for appearance: base? I'd expect it to revert to the appearance: base default styles, but I think it would probably be up for discussion.

[josepharhar]

I made some changes to the proposed colors based on the meeting:

• Changed border-radius from 0.25em to 0.5em based on resolution to use border-radius and @fantasai's feedback to increase it to 0.5em.
• Changed background-color to transparent for select based on the resolution and changed 20% and 30% active and hover colors to 10% and 20% now that 10% is no longer being used by default