| Jdlrobson | |
| Nov 16 2017, 7:15 PM |
| F10819621: IMG_6076.PNG | |
| Nov 16 2017, 7:22 PM |
| F10819624: IMG_6077.PNG | |
| Nov 16 2017, 7:22 PM |
| F10831805: Screen Shot 2017-11-16 at 11.21.45 AM.png | |
| Nov 16 2017, 7:22 PM |
| F10831804: Screen Shot 2017-11-16 at 11.21.38 AM.png | |
| Nov 16 2017, 7:22 PM |
On the Wikipedia homepage www.wikipedia.org the language selection dropdown uses a select element which works nicely on mobile, which both in Android/iOS uses a native dialog
The OOUI implementation uses divs and when these divs are long can be unusable on mobile and get clipped.
Current experience:
What it should actually work like
Please make sure clicking these elements triggers a native select element on mobile.
Notice how all options are not visible nor clickable:
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T158181 Aim for workflow equivalence for MediaWiki on desktop and mobile web | |||
| Declined | None | T67078 Allow feedback for mobile beta features like Desktop | |||
| Resolved | • Jhernandez | T104319 [GOAL]: Feature flag features on MobileFrontend | |||
| Resolved | None | T141087 [EPIC] Add feature management | |||
| Resolved | ovasileva | T67079 [Epic] Show what features are included in Beta | |||
| Resolved | ovasileva | T182217 Deploy `specialpages` feature branch (promote new Special:MobileOptions, fontchanger etc) | |||
| Resolved | • Nirzar | T109364 Promote fontchanger to stable (in feature branch) | |||
| Resolved | • Nirzar | T169369 Change font size controls to use small, regular, large and extra large buckets | |||
| Resolved | Volker_E | T180730 Dropdown widgets menu inferior on mobile - should use native `select` element for better mobile compatibility |
There are actually a few other reasons why we might want to use a <select> internally (whether or not we show it to the user). It would make JS and PHP-infused widgets more consistent (we keep the PHP-generated <select> when infusing and I'm sure there is some edge cases where this causes problems), and it would allow custom OOUI themes to display the native interface if the theme's author doesn't want to write custom styles.
Once we have a hidden <select>, that is synchronized with our visible UI, it should be a simple CSS change to make it visible instead.
Note that this might not be possible for DropdownWidget, as we allow the options' labels to contain HTML markup (while <option> may only contain text). It is, however, possible for DropdownInputWidget (since we limit its functionality to what is possible with similar HTML, like for all InputWidgets).
I'll work on this soon, but I'll need code review for it to actually get merged, perhaps from you @Jdlrobson? :)
Change 393352 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[oojs/ui@master] DropdownInputWidget: Generate a hidden <select> in JS
Change 393352 merged by jenkins-bot:
[oojs/ui@master] DropdownInputWidget: Generate a hidden <select> in JS
With that patch merged, there is now a hidden <select> in the DOM of DropdownInputWidget, and if you were to show it and hide the "pretty" DropdownWidget, it would function entirely correctly.
We still need to make it appear. I'm not sure how we want to detect "mobile" here, though. Should we just use OO.ui.isMobile() (that checks for wgMFMode)? Or something different? I think @Volker_E said he's thinking about this, so you and @Jdlrobson please coordinate :)
(I'm not actively working on this right now, so I'm unclaiming this task. Ping me if you need me to implement stuff, but the remaining part should be easy, once we decide how to do it.)
for that
what's that?
We still need to make it appear. I'm not sure how we want to detect "mobile" here, though. Should we just use OO.ui.isMobile() (that checks for wgMFMode)? Or something different? I think @Volker_E said he's thinking about this, so you and @Jdlrobson please coordinate :)
I would propose feature detecting for touch device support via browser.supportsTouchEvents or !browser.isWideScreen to detect mobile. I think the former would make more sense though.
So from a conversation of today with @Jdlrobson, the widget handle itself could be untouched and just showing the native select's menu seems sufficiently resolving this for MobileFrontend requirements.
IMHO, the only possibility to handle dropdowns on Mobile is to use Overlay system, when user clicks a dropdown - we should show a fullscreen overlay with scrollable list of options. but that's most probably lots of work and totally out of the scope.
Change 511094 merged by jenkins-bot:
[oojs/ui@master] DropdownInputWidget: Use native select when isMobile is true
@pmiazga The path we've taken now is to provide native selects when the isMobile flag is set true (MinervaNeue sets it and it could be unset dynamically at a certain media query to enable custom dropdown on desktop again).
You need to use a OOUI DropdownInputWidget to benefit from this solution. The advantage is, that the native handling by the OS/browser is known to users and should be optimized for the specific platform and that you're still able to interact with the dropdown dynamically per JS in the OOUI way.
Normal DropdownWidget's are not providing the select (in OOUI terms input).
(To clarify, it's not about the skin, it's about the mobile/desktop mode – our isMobile() is equivalent to wgMFMode. It's defined here:
https://github.com/wikimedia/mediawiki/blob/master/resources/src/ooui-local.js#L11)
@Volker_E thanks. I was actually just investigating how mobile handles <select multiple> (won't work on desktop): https://codepen.io/alexhollender/full/ZNBvLP. Good handling, though no support for styling or sub-headings for options.
Change 513020 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[mediawiki/core@master] Update OOUI to v0.32.0