Implement HTMLSelectAndOtherField and HTMLSelectOrOtherField in OOUIHTMLForm.
Description
Description
Details
Details
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T49145 Formally deprecate jQuery UI after we've stopped using jQuery UI in extensions and core | |||
| Open | None | T100270 Replace use of jQuery UI and MW UI with OOUI across all Wikimedia-deployed extensions and core | |||
| Open | None | T100161 Convert all of MediaWiki core to OOUI PHP (tracking) | |||
| Open | None | T101480 Remove 'wgUseMediaWikiUIEverywhere' and code forks, always using the off/false path | |||
| Duplicate | None | T101476 [EPIC] Make mobile look and work as desired without wgUseMediaWikiUIEverywhere | |||
| Open | None | T101471 Convert core forms that use MW UI with wgUseMediaWikiUIEverywhere false to OOUI FormSpecialPage or explicit OOUI PHP | |||
| Open | None | T107037 Convert all MW core special pages to OOUI | |||
| Resolved | Jdforrester-WMF | T107036 Convert Special:Block and Special:Unblock to OOUI | |||
| Open | None | T145310 Pressing the block button should open up a pop-up modal in MediaWikiChat | |||
| Resolved | • Prtksxna | T106999 Implement HTMLSelectAndOtherField and HTMLSelectOrOtherField in OOUIHTMLForm |
Event Timeline
Comment Actions
Does anyone know the current status of this ticket, and how difficult this would be to implement? I'd be interesting in learning more about such a task :-)
Comment Actions
Should we remove HTMLSelectOrOtherField from this task?
Isn't HTMLSelectAndOtherField just two fields?
Comment Actions
Yeah, HTMLSelectOrOtherField has low usage and two alternatives, so we could probably get away with skipping it. But I think most of the code will be reused from HTMLSelectAndOtherField.
I think both of these are basically just a dropdown plus a textfield? It shouldn't be difficult to implement. We should just have a OOUI\Widget subclass that would display the two fields side-by-side, similar to e.g. MediaWiki\Widget\ComplexTitleInputWidget / mw.widgets.ComplexTitleInputWidget. This is needed because HTMLFormField uses OOUI\FieldLayout, which expects a single widget (HTMLFormField::getInputOOUI() is technically allowed to return HTML strings, which will be dynamically wrapped in a Widget, but that's hacky and I'm not sure if we actually use it anywhere.)
Comment Actions
Change 344121 had a related patch set uploaded (by Prtksxna):
[mediawiki/core@master] mw.widgets: Add SelectWithInputWidget
Comment Actions
Change 344121 merged by jenkins-bot:
[mediawiki/core@master] mw.widgets: Add SelectWithInputWidget and its PHP implementation
Comment Actions
No. We implemented the mw.widgets.SelectWithInputWidget, but the two HTMLFormField subclasses haven't been updated yet to use it.
Comment Actions
Change 357198 had a related patch set uploaded (by Prtksxna; owner: Prtksxna):
[mediawiki/core@master] HTMLSelectAndOtherField/HTMLSelectOrOtherField: Add OOUI implementation
Comment Actions
Change 357198 merged by jenkins-bot:
[mediawiki/core@master] HTMLSelectAndOtherField/HTMLSelectOrOtherField: Add OOUI implementation