[selectmenu] Customization - OS-native UIs

[travisleithead]

This issue was migrated from https://github.com/MicrosoftEdge/MSEdgeExplainers/issues/369

@jcgregorio opened the issue on 2020-07-29

How would <select> work on Mobile platforms, where OS-native UIs are used for some control popups? Would we switch to the browser popup if we detect that a developer has applied any custom styles or markup for it?

Yes.

OS-native UIs are a pox on developers and it should be, in my opinion, a goal of this work to remove all of them from the browser.

@dandclark commented on 2020-07-29

Yeah, I think the best outcome here is that the customizable controls never use OS-native UIs, while the old, non-customizable versions of the controls could continue to use them as they do now. I wrote some thoughts on this over at https://github.com/WICG/open-ui/issues/143#issuecomment-664690025.

@hwikyounglee were you able to get in touch with the Android Chrome team to learn their thoughts on not using OS-native UIs for customizable controls? cc @gregwhitworth who had asked about this. As I commented at https://github.com/WICG/open-ui/issues/143#issuecomment-664690025, I suspect that developers who need control customizability would already not be getting OS-native controls, because they'll be rolling their own control implementations e.g. with custom elements.

@mfreed7 commented on 2020-08-07

I would be very curious to hear more developers' voices on this issue. It seems to be contentious, and I've heard good arguments on both sides. I tend to lean toward the comments above - having a developer-customizable experience that is the same on all platforms should reduce both developer burden and interop problems. However, I'm also sensitive to the argument that some platforms need a different, custom/different interface for some types of form controls, both because of space and interface constraints, but also to provide a level of platform look and feel that aids user comfort and familiarity.

One, more simple, example is the existing <select> control. Most browsers use a platform-native <select> on desktop Mac, while using a custom <select> that is more stylable on all other platforms. It would seem that having the more-customizable custom <select> on all platforms would be the best, but there are many arguments made to keep them separate.

@una commented on 2020-08-12

Native mobile <select> brings users so many UI improvements: a zoomed-in view, automatic focus control, larger text, etc. Why not allow for these to be customized or to retain some styling? This way, developers are still able to control styling, and the mobile experience is less distinct from desktop, while still providing some of the small-screen / touch accessibility features?

@dandclark commented on 2020-08-13

Native mobile <select> brings users so many UI improvements: a zoomed-in view, automatic focus control, larger text, etc. Why not allow for these to be customized or to retain some styling? This way, developers are still able to control styling, and the mobile experience is less distinct from desktop, while still providing some of the small-screen / touch accessibility features?

I think the difficulty is that the full level of customizability we are proposing, where the author can supply arbitrary HTML and styles for the control, is not feasible to apply to OS-native control UIs that are written outside of the web platform. Perhaps some smaller degree of customizability such as acccent color could be applied to these if we can get sufficient buy-in from the mobile OS vendors. But the problem is that if a developer provides totally new HTML/CSS for their custom <select> then it might not be appropriate to ignore it and instead use e.g. the iOS native one when running on an iPhone.

[gregwhitworth]

@travisleithead what are your goals for this thread? I'm personally in favor of closing this issue given that I believe that standards bodies, Open UI, and browser vendors have realized there is a spectrum of customization that authors desire. Yes, Open UI is focused on providing the "full level" of customization that @dandclark refers to but the web platform as a whole is not neglecting the other scenarios.

ccing @una @mfreed7 to weigh in just in case there is more they'd like to discuss on this issue

[github-actions[bot]]

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.