Select menus - faster, option to use the native menu instead of our custom menu

[toddparker]

The performance of the custom menus can be slow on older devices with either lots of selects or long selects so we should create a custom-styled select element that triggers a click/tap on the native select to open the native menu.

We could change the way selectmenu works so that keyboard navigation actually focuses on the select element, which toggles the focus state on the button to orient sighted users. This way, we'd get the semantics of the select when browsing on a screen reader. clicking the select would trigger the open() method just like clicking the button does. At that point, focus would jump to the menu as it already does, but it the role might be clearer after having clicked a real select menu.

Using the native menu should be a global config option and also set on individual selects via JS or data- attribute. We need to skip the custom menu creation logic in our script if the native menu is used to avoid overhead.

We're wondering if the native select menu should be the default so we err on the side of responsiveness. There are downsides to using the native menu (lack of optgroup support on some devices, inconsistent UI, can't use our custom placeholder option feature, multi-select doesn't work on WebOS) but for a normal select on most popular platforms, the native is pretty slick and fast. We could recommend opting in to the custom select if you need better multi-select support or want to use optgroups in the docs. Thoughts?

[seantbrady]

My opinion is that the native select behavior should be the default.

1) Users will already be accustomed to the select behavior that is native to their platform.
2) Native keyboards are already popping up and down creating an "inconsistent UI". If we're using the native keyboards, it seems that we would also want to use native selects. 3) This will also make native apps (e.g., those using PhoneGap) feel more native.

There are definitely advantages to the custom selects, so these should be maintained as an option.

[johnbender]

Scott appears to have begun work on this in the nativeselectmenu branch.

[toddparker]

Yes, he's pretty far along with adding this feature. Thoughts on whether the native menu should be the default?

[chenchen]

Yes, I agreed with seantbrady, the behavior of native select menu differently on mobile device, such as iphone and android. I was trying to modify the source code to make jQM to avoid the select tag. Unfortunately, the event can not be passed to the select menu on the mobile device. The native select menu would't receive any of events, such as click, change, focuse or keydown.

[toddparker]

@johnbender - do you want to take this one?

[johnbender]

update:

this is nearly complete in my local nativeselectmenu branch, though it currently still adds the markup in both cases.

[johnbender]

data-native attribute check for native select menus Closed by 244e46b8edacc5a4af852eb6fd3d98c0369ab127