[selectlist] Should UAs be able to "fallback" to native implementation if a poor UX is detected?

[pxlcoder]

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:

• Items in <selectmenu> appear to be smaller by default
• Menu does not dismiss on scroll/zooming

This brings up the following set of questions:

• Should UAs be allowed to show a native picker on mobile? Alternately, should there be an opt-in way to get the native picker?
• 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?

Test pages

• https://selectmenu-polyfill.vercel.app/examples/edgedemos.html

Related issues: #524, #688

[josepharhar]

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.

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...?

[josepharhar]

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

[pxlcoder]

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.

[josepharhar]

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

[css-meeting-bot]

The Open UI Community Group just discussed [selectmenu] Default appearance of the control on mobile devices.

The full IRC log of that discussion

<gregwhitworth> Topic: [selectmenu] Default appearance of the control on mobile devices
<gregwhitworth> github: https://github.com//issues/787
<masonf> q+
<gregwhitworth> akeerthi: I filed this issue on how it should appear on mobile and the in-page control and the picker itself
<gregwhitworth> ack gregwhitworth
<gregwhitworth> q+
<gregwhitworth> akeerthi: first part is should there be defaults and should the UA fallback to a different style when they deem appropriate
<gregwhitworth> ack masonf
<gregwhitworth> masonf: I thought we had an issue for this but thank you for opening it
<gregwhitworth> masonf: it is appropriate that the UA overrides the styles to override that then in most cases the norm that the developer styles win
<gregwhitworth> masonf: the concern is a good one
<gregwhitworth> masonf: developers don't think about the default styles
<gregwhitworth> masonf: I think the default styles should include media queries
<flackr> +1
<gregwhitworth> masonf: they then can do what they want to with their own media queries; the right option is both
<ntim> q+
<jarhar> ill scrobe
<jarhar> *scribe
<jarhar> greg: i have a very strong disagreement that you feel the UA should
<brecht_dr> q+
<jarhar> greg: the whole purpose of what were doing is that they cant touch anything and have any expectations of consistencies
<jarhar> greg: my expectation, in the csswg the normal argument that gets brought up every 2 years, what about some mythical device noones thought about
<jarhar> greg: this was discussed internally before the hololens was introduced. how are things going to be styled, foldable devices, before they were publicly known
<jarhar> greg: my expectation is what you said in the second one - there should be a media query for it and there should be standardized styles for it
<jarhar> greg: we can technically go build these however we want, 9 million different ways
<scotto_> q+
<akeerthi> q+
<jarhar> greg: we should have media queries, whether thats by is it coarse. what if youre on a touch screen windows device?
<jarhar> greg: in that scenario, i want them to apply
<jarhar> greg: thats what i expect us to come out with, no borders no paddings but in these media queries these are the scenarios where we have a default user agent stylesheet
<jarhar> greg: as we see in chromium, we have a user agent style that is on top of that, potentially more specific, thats something we need to argue about
<jarhar> greg: the developer stuff would win on top of that
<masonf> q?
<masonf> q+
<gregwhitworth> ack gregwhitworth
<jarhar> greg: i would almost never want the first statement that mason said, the only time i could see that being an argument is when we dont have a media query that exists for the user agent to do the right thing
<gregwhitworth> ntim: I actually have an argument against UA styles
<gregwhitworth> ntim: if the developer does not take into account mobile UA styles
<gregwhitworth> ntim: then they might have unexpected results
<gregwhitworth> ntim: they haven't tested on mobile and they find things that are behaving things occur unexpected ways
<flackr> q+
<gregwhitworth> ntim: I'd be in favor of showing the native picker when it's appropriate
<gregwhitworth> ack nt
<gregwhitworth> ack ntim
<gregwhitworth> ack brecht_dr
<gregwhitworth> brecht_dr: it's important that stylng behaves as expected, I expect it to be exactly the same on any device
<gregwhitworth> brecht_dr: if I give it a width on 500px width and some may not have that space then there should be a way to allow the default way to show
<gregwhitworth> q+
<gregwhitworth> brecht_dr: I want it to be the same thing unless I explicitly say something else on some other screen/device
<gregwhitworth> ack scotto_
<gregwhitworth> scotto_: it must have been a different issue but I was concerned about this and any type of default UA fallback and because anyone can put things into this but we can't have a native select count as a fallback because whatever they put in there is completely thrown away
<flackr> +1 to scotto_
<flackr> q-
<gregwhitworth> scotto_: you've now created a disparity in the various content and we need to have viewport styling and not call it mobile styling because what does that mean?
<gregwhitworth> scotto_: but we can't throw away the content that will just swap out one thing for the other
<gregwhitworth> ack akeerthi
<gregwhitworth> akeerthi: I think it's important when the UA would swap out and when the watch case and it would be the option for the UA to fallback to the native picker
<flackr> q+
<gregwhitworth> akeerthi: any research done in how they handle these
<gregwhitworth> ack masonf
<gregwhitworth> masonf: component libraries do not do anything native; most of them they don't use build in select so on a watch
<gregwhitworth> masonf: it might make sense to pause this issue and move to issue #5XX and how many situations would they handle
<gregwhitworth> masonf: to gregwhitworth point that do the right thing
<gregwhitworth> masonf: what we do here is what we do there
<akeerthi> q+
<gregwhitworth> masonf: let's go usecase driven?
<jarhar> ill scriber
<jarhar> greg: basically, thats what i was going to say. when we pitched this to the csswg to make sure we didnt waste time in openui, 3 years ago,
<ScottKellum> q+
<jarhar> greg: one of the use cases i showed was actually a watch face where you select the middle one and it wraps it around in a circle, you scroll around, and it goes back to the selected option in the middle
<jarhar> greg: lets get the default ugly styles and put them in the media queries
<jarhar> greg: theres a ton we have to cover, theres a lot of use cases, what are all those base scenario on the foldable ones
<jarhar> greg: the entire notch thing when ios came out with that. it wasn't hey were just gonna fallback all web content magically, no were gonna introduce a paradigm, heres the usable space thing
<jarhar> greg: i am very in opposition to what brecht pointed out. it has to be consistent, or else were gonna have "may" or "should" with these styles
<jarhar> greg: you could make it so your styles are display:flex instead of grid and then the properties ive added no longer apply
<jarhar> greg: +1 to going use case by use case because it will highlight us missing primitive in a media query than devs arent going to test our stuff so devs need a native solution. not that i disagree with what yall are solving here
<jarhar> greg: devs unfortunately are not going to test across the spectrum
<jarhar> greg: but that is why we want one standard set of styles, so that we can check it on the different platforms
<jarhar> greg: when some newfangled device comes in the future like jarvis and its only voice, how do we handle it? we need a new media query
<gregwhitworth> ack gregwhitworth
<gregwhitworth> ack flackr
<gregwhitworth> flackr: +1 to scotto_
<gregwhitworth> flackr: we could possibly force the default UA styles, even worse than somewhat being default usable and is trying to define a usecase
<gregwhitworth> flackr: using the default styles is we can force the default UA styles and I still don't think we should do that
<gregwhitworth> q+
<gregwhitworth> ack akeerthi
<gregwhitworth> I think masonf proposals it will be very annoying and will show the full proposal of things
<gregwhitworth> akeerthi: I think there may still be explorations there as do they use media queries today?
<masonf> q?
<gregwhitworth> akeerthi: I think there may still be scenarios where we'll need to fall back to the native picker
<gregwhitworth> ack ScottKellum
<gregwhitworth> ScottKellum: with just looking at other cases where there are differences in apple watch and had the meta tag and now we have to add that to everything on mobile to scale things correctly and stop apple from doing that transform and the hover states are completely different. As a standards body I would want to have standards everywhere to be consistent. That doesn't mean that device manufacturers won't choose to add a toggle
<gregwhitworth> ScottKellum: we need to trust people to test things appropriately
<jarhar> greg: rob, to your statement, i dont think we should enforce a user agent stylesheet even
<jarhar> greg: that was masons proposal to define user agent styles
<jarhar> greg: here is the styles that you will ship with your user agent stylesheet
<jarhar> rob: thats not what im trying to say
<jarhar> rob: that was not my intention, my intention is that when youre on the watch, the developer doesnt know what theyre doing, were going to use the ua sheet instead of their styles
<jarhar> greg: just to reiterate, what is going to end up happening, aditya more than happy to help out with research with component libraries
<jarhar> greg: now that we have container queries, we could do container queries for select
<jarhar> greg: the user agent stylesheet, we are going to have a "must" in whatwg, its going to be 400 lines of css is my guess
<jarhar> greg: its going to be more than a display:block, here is every part and here is the default
<jarhar> greg: to adityas point, i have not tested every salesforce component on a watch, because we ship an ios app
<jarhar> greg: i think its great for us to do the research, and thanks for the clarification rob, that is the user agent stylesheet
<masonf> Note: we're 3 minutes over time
<jarhar> greg: i want to pivot discussions to figure out a way to fallback to native solution that could be implementation details, whether theyre using their own css or using a completely different component
<jarhar> greg: were using some other component completely
<masonf> q?
<jarhar> greg: we should open an issue where we resolve concretely on an issue about that
<jarhar> greg: now that we have broader folks on the group
<jarhar> greg: this issue pivots into do we fall back. are there scenarios ever that we enable a user agent to pivot to a native solution? implementation details aside
<gregwhitworth> ack gregwhitworth
<gregwhitworth> Zakim, end meeting

[gregwhitworth]

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)?

[josepharhar]

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...?

[github-actions]

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.