Implement HTMLSelectAndOtherField and HTMLSelectOrOtherField in OOUIHTMLForm.
Description
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) | |||
Resolved | matmarex | 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 | |||
Invalid | 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
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 :-)
Should we remove HTMLSelectOrOtherField from this task?
Isn't HTMLSelectAndOtherField just two fields?
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.)
Change 344121 had a related patch set uploaded (by Prtksxna):
[mediawiki/core@master] mw.widgets: Add SelectWithInputWidget
Change 344121 merged by jenkins-bot:
[mediawiki/core@master] mw.widgets: Add SelectWithInputWidget and its PHP implementation
No. We implemented the mw.widgets.SelectWithInputWidget, but the two HTMLFormField subclasses haven't been updated yet to use it.
Change 357198 had a related patch set uploaded (by Prtksxna; owner: Prtksxna):
[mediawiki/core@master] HTMLSelectAndOtherField/HTMLSelectOrOtherField: Add OOUI implementation
Change 357198 merged by jenkins-bot:
[mediawiki/core@master] HTMLSelectAndOtherField/HTMLSelectOrOtherField: Add OOUI implementation