Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[selectmenu] Decide on standardized default styles for appearance:base-select #552

Open
mfreed7 opened this issue Jun 23, 2022 · 9 comments
Labels
select These are issues that relate to the select component

Comments

@mfreed7
Copy link
Collaborator

mfreed7 commented Jun 23, 2022

Per the resolution on 536, we will have <selectmenu> come with default styles that are standardized. (These can be opted-out via selectmenu {appearance:auto} in CSS.)

This issue is to brainstorm/bikeshed what those default styles should be. One interesting point, raised by @jonathantneal, is that perhaps the default styles should use media queries for things like dark mode and perhaps screen size.

Purely as a way to see what types of styles might be needed, here is a link to the Chromium prototype's stylesheet for <selectmenu>. It contains styling for the button, icon, options, and the listbox. We will likely need to decide on a set of defaults for each of these things. Ideally, the standardized CSS can be shortened significantly from the .css file I linked above. Just enough to make it easy to use and clear. What is the minimum CSS that achieves that goal?

Thoughts? Proposals?

@mfreed7 mfreed7 added the select These are issues that relate to the select component label Jun 23, 2022
@github-actions
Copy link

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.

@github-actions github-actions bot added the stale label Dec 21, 2022
@josepharhar josepharhar added the agenda+ Use this label if you'd like the topic to be added to the meeting agenda label Mar 25, 2023
@josepharhar
Copy link
Collaborator

I propose that we use the stylesheet mason linked for appearance:none.
It is worth noting that we are currently developing the regular (not none) appearance and wish for that appearance to be implemented across browsers as well.

@github-actions github-actions bot removed the stale label Mar 26, 2023
@mfreed7
Copy link
Collaborator Author

mfreed7 commented Mar 31, 2023

I propose that we use the stylesheet mason linked for appearance:none.

We're working on an improved version of the base styling for <selectmenu> so let's not resolve on the old version just yet. Soon, though.

It is worth noting that we are currently developing the regular (not none) appearance and wish for that appearance to be implemented across browsers as well.

So actually, the appearance:none CSS is what we'd like to standardize. The appearance:auto look and feel is the one that can be customized by different UA's, and doesn't need to be standardized.

@josepharhar josepharhar removed the agenda+ Use this label if you'd like the topic to be added to the meeting agenda label Apr 4, 2023
aarongable pushed a commit to chromium/chromium that referenced this issue Aug 17, 2023
See [1] and [2] for context, but this CL adds a media query for touch
(coarse pointer) and small screen (<500px), and enlarges the display
and touch targets for <selectmenu>.

Note: the coarse pointer query is currently commented out, to make
it easier to test behavior on desktop systems.

[1] openui/open-ui#536 (comment)
[2] openui/open-ui#552

Bug: 1121840, 1467829
Change-Id: Ic5f7ec0c2fe948ef9fa4c8480595f9f9ed5b4df7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4701692
Reviewed-by: Joey Arhar <jarhar@chromium.org>
Commit-Queue: Joey Arhar <jarhar@chromium.org>
Auto-Submit: Mason Freed <masonf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1184795}
@mfreed7
Copy link
Collaborator Author

mfreed7 commented Aug 17, 2023

This comment is likely premature. But given the discussion on #787 (comment), I wanted to kick start the conversation around what some interoperable default styles might look like for <selectlist>.

Here's very roughly what's implemented in the Chromium prototype at the moment:

selectlist {
  display: inline-flex;
  user-select: none;
  font-family: sans-serif;
  font-size: .875em;
}

selectlist::-internal-selectlist-button {
  /* This is applied to the in-page button - selector above TBD */
  color: FieldText;
  background-color: Field;
  border: 1px solid ButtonBorder;
  border-radius: 0.25em;
  cursor: default;
  display: inline-flex;
  flex-grow:1;
  flex-shrink:1;
  font-size:inherit;
  appearance: none;
  align-items: center;
  overflow-x:hidden;
  overflow-y:hidden;
  padding: 0.25em;
  text-align: inherit;
}

selectlist option {
  font-size: .875em;
  padding: 0.25em;
}

selectlist option:hover {
  color: SelectedItemText;
  background-color: SelectedItem;
  cursor: default;
  user-select: none;
}

selectlist optgroup {
  padding-bottom: 0.75em;
}

selectlist optgroup > option {
  padding-left: 0.75em;
}

selectlist optgroup:last-child {
  padding-bottom: 0;
}

selectlist option:disabled {
  color: GrayText;
  background-color: initial;
}

selectlist option:disabled:hover {
  background-color: transparent;
}

selectlist::-internal-selectlist-listbox {
  /* This is applied to the contained popover listbox - selector above TBD */
  padding: 0.25em 0;
  overflow: auto;
  border: 1px solid rgba(0, 0, 0, 0.15);
  border-radius: 0.25em;
  box-shadow: pick a good default box shadow that separates the picker from the page;
  box-sizing: border-box;
}

selectlist::-internal-selectlist-listbox {
  background-color: Field;
}

/* Pointer:coarse --> make the options larger and easier to pick */
@media (pointer: coarse) {
  selectlist option {
    padding: 0.5em;
    font-size: 1em;
  }
}

/* Pointer:coarse and max width in physical units --> make the listbox take over more of the screen */
@media (pointer: coarse) and (max-width: 10cm) {
  selectlist::-internal-selectlist-listbox {
    inset: 0;
    margin: auto;
    max-height: 50%;
    padding: 0.25em 0;
    box-shadow: none;
    border-radius: 0.5em;
    border: none;
  }
  selectlist::-internal-selectlist-listbox::backdrop {
    background-color: rgba(0, 0, 0, .7);
  }
}

@media (pointer: coarse) and (max-width: 3cm) {
 /* Very small screen styles here? E.g. watch face */
}

There are a number of things missing or questionable above, such as positioning (which will require anchor positioning). But I wanted to put this out there, so we can start really seeing what styles we're talking about, and simplify/converge on a small, good set of default CSS values to use. I'm not arguing that the Chromium styles above need to be the final styles, I'm just providing a starting point for the discussion about:

  1. What a set of interoperable, non-opinionated styling might look like.
  2. What selectors and conditions need to be considered.
  3. What media queries might need to be included.

aarongable pushed a commit to chromium/chromium that referenced this issue Aug 18, 2023
This has no behavior changes. Mostly I wanted to remove one extra
repeated selector set, but I also ended up re-ordering the properties
to organize them a bit better. (We're starting to talk about them on
[1] so cleanliness matters.)

[1] openui/open-ui#552 (comment)

Bug: 1121840
Change-Id: Id29bd62d3347a8b2ac28d0d698cef4ff90c0f69e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4792068
Reviewed-by: Di Zhang <dizhangg@chromium.org>
Commit-Queue: Mason Freed <masonf@chromium.org>
Commit-Queue: Di Zhang <dizhangg@chromium.org>
Auto-Submit: Mason Freed <masonf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1184981}
Copy link

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.

@github-actions github-actions bot added the stale label Feb 14, 2024
@josepharhar
Copy link
Collaborator

In the current state of things, we won't get to change the styles for the select element itself since we are using the css appearance property to switch into the new mode, but we still get to add pretty much all the styling by adding styles which target the child button, datalist, and option elements.

@lukewarlow
Copy link
Collaborator

Just a note for something that came up in todays meeting, I think we should be making field-sizing: content the new default for appearance: base-foo; styles. The legacy fixed styles shouldn't exist going forwards.

@mfreed7 mfreed7 changed the title [selectmenu] Decide on standardized default styles for appearance:none [selectmenu] Decide on standardized default styles for appearance:base-select May 3, 2024
@josepharhar
Copy link
Collaborator

In the current state of things, we won't get to change the styles for the select element itself since we are using the css appearance property to switch into the new mode, but we still get to add pretty much all the styling by adding styles which target the child button, datalist, and option elements.

Nevermind, we can make separate styles by using the -internal-appearance-auto-base-select() function I implemented here: https://chromium-review.googlesource.com/c/chromium/src/+/5389566

Just a note for something that came up in todays meeting, I think we should be making field-sizing: content the new default for appearance: base-foo; styles. The legacy fixed styles shouldn't exist going forwards.

appearance:base-select turns the entire select into plain elements which aren't affected by custom layout code, at least I sure hope so. What difference would this make? I'd be happy to add it to the UA stylesheet, I suppose that maybe I don't understand the field-sizing property very well.

@lukewarlow
Copy link
Collaborator

appearance:base-select turns the entire select into plain elements which aren't affected by custom layout code, at least I sure hope so. What difference would this make? I'd be happy to add it to the UA stylesheet, I suppose that maybe I don't understand the field-sizing property very well.

That might be enough. I think adding it to the spec would at least make it crystal clear what the intention here is. Ensuring that a different implementation doesn't accidentally leave behind any left overs such as relayout boundaries.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
select These are issues that relate to the select component
Projects
None yet
Development

No branches or pull requests

3 participants