Open pxlcoder opened 1 year ago
Should UAs be allowed to show a native picker on mobile? Alternately, should there be an opt-in way to get the native picker?
If you want the native picker, you should probably be using <select>
instead of <selectlist>
. In https://github.com/openui/open-ui/issues/524 it sounds like some people feel strongly about this.
Should UAs be allowed to adjust the default set of styles based on the platform? Should a separate set of common default styles be specified for mobile?
Making the picker larger or fill the screen on mobile could be good, but then authors may want to put additional styling on the changes for mobile made by the UA sheet, which would require them to match the selectors in the UA sheet which could be hard or impossible - I believe @una brought this up. What if the developer never tests for mobile and something about the mobile-specific UA sheet makes the listbox weird or unusable when combined with how the developer styled it?
If we don't end up changing the UA sheet for mobile, then it should still be easy for the author to make their own styles that target mobile somehow. What changes for mobile do you have in mind? I suppose that making the font bigger could be acceptable, but changing the positioning maybe isnt...?
Having it be nice for mobile by default does sound ideal, but I think this is complicated.
Menu does not dismiss on scroll/zooming
This behavior doesn't sound super compelling to me. It looks like this helps the native picker on iOS avoid having to reposition itself, but that might not be an issue here since we are using anchor positioning to keep the listbox attached to the button.
https://selectmenu-polyfill.vercel.app/examples/edgedemos.html
The only issue I see here on mobile is that the text in the listbox is smaller than the text in the rest of the page which makes the options kind of hard to tap - but it's the same on desktop. Perhaps the author should be expected to make the size of the text in the listbox match the rest of the page...?
I'll agenda+ this, but I'd really like to know what UA styles for mobile you have in mind before we decide whether it's acceptable or not
Should UAs be allowed to show a native picker on mobile? Alternately, should there be an opt-in way to get the native picker?
If you want the native picker, you should probably be using
<select>
instead of<selectlist>
. In #524 it sounds like some people feel strongly about this.
I do feel there is a use case here where developers may want to have custom in-page styling, while still using the OS native picker. I know this is technically possible using appearance: none
with <select>
, but it's not trivial.
Given that the overall goal is customizability, I think it would be nice to allow for the picker "type" to be customized too.
Should UAs be allowed to adjust the default set of styles based on the platform? Should a separate set of common default styles be specified for mobile?
Making the picker larger or fill the screen on mobile could be good, but then authors may want to put additional styling on the changes for mobile made by the UA sheet, which would require them to match the selectors in the UA sheet which could be hard or impossible - I believe @una brought this up. What if the developer never tests for mobile and something about the mobile-specific UA sheet makes the listbox weird or unusable when combined with how the developer styled it?
This is a very valid point. Though, my worry is that the inverse is also true, where the developer never tests for mobile, and absence of any mobile-specific styling (author or UA), results in the listbox being difficult to use with the current styling.
If we don't end up changing the UA sheet for mobile, then it should still be easy for the author to make their own styles that target mobile somehow. What changes for mobile do you have in mind? I suppose that making the font bigger could be acceptable, but changing the positioning maybe isnt...?
I don't have a specific set of changes in mind at this time, but font-size
and/or increasing the default padding of list items (to ensure a larger tap target) are some possibilities.
Agreed that positioning could be risky, especially due to "developer never tests for mobile".
Having it be nice for mobile by default does sound ideal, but I think this is complicated.
I agree this is complicated, but I would like to explore our options to help ensure this is right for mobile. Maybe a first step is to see whether or not existing component libraries have special logic for constrained screen space.
https://selectmenu-polyfill.vercel.app/examples/edgedemos.html
The only issue I see here on mobile is that the text in the listbox is smaller than the text in the rest of the page which makes the options kind of hard to tap - but it's the same on desktop. Perhaps the author should be expected to make the size of the text in the listbox match the rest of the page...?
I do think it's easier to click options on desktop (vs. tap on mobile), since we have a pointer. This is the concern I had in mind with "developer never tests for mobile". With <select>
, this concern does not exist for the picker.
Mason is about to add some mobile styles to the listbox in the chromium prototype here: https://chromium-review.googlesource.com/c/chromium/src/+/4701692
The Open UI Community Group just discussed [selectmenu] Default appearance of the control on mobile devices
.
As discussed @pxlcoder I've changed the framing of this to be more general about a user-agent being able to fall back to a preferred solution based on their perceived expectations of a poor UX due to a developer not doing adequate testing in certain environments. Please add additional context or clarifications.
The discussion around styles themselves will be usecase driven and a part of #552 which will aim to define ALL styles; not necessarily just for mobile.
@pxlcoder it's worth also looking at #689 as it's somewhat related that devs at times do want native solutions; so while this issue is about potentially detecting and falling back in some manner; that one is about giving authors an opt-in (and is it even necessary)?
The chromium prototype has a media query for mobile and changes styles for the listbox based on it, and based on feedback from @una and @nt1m I'm not sure it's a great idea.
What seems best based on the idea that we should provide something usable on mobile and that we should allow developers to have mobile styling while ensuring that we have usable styles by default is to show the OS native picker by default and have an attribute to opt out of this with no user-agent stylesheet that targets mobile.
Showing the native picker which presumably can't show rich content but only text, this could result in weird behavior by default if the author doesn't provide a usable text representation of each option. I suppose that we should require that authors provide usable text for each option anyway for accessibility reasons too, right...?
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.
Opening this issue to start a discussion on whether
<selectmenu>
should have a different default appearance, or special behaviors on mobile devices.Compared to the native
<select>
picker on iOS:<selectmenu>
appear to be smaller by defaultThis brings up the following set of questions:
Test pages
Related issues: #524, #688