ControlUICustomization - OS-native UIs

[jcgregorio]

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]

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 openui/open-ui#143 (comment).

@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 openui/open-ui#143 (comment), 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]

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]

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]

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.

[travisleithead]

This issue has been migrated to the OpenUI CG for continued discussion: openui/open-ui#524