Change 185591 had a related patch set uploaded (by Bartosz Dziewoński):
[WIP] SpecialMovepage: Convert form to use OOUI controls

https://gerrit.wikimedia.org/r/185591

Patch-For-Review

So I tried to do this and here's how it currently looks:

Before	After

And in context of the whole special page:

Before	After

Not bad, but I don't quite like it. I think there's a bit too much whitespace here, inside and outside the fields. There's nothing to bring the form together like the blue frame did, too. The form fields design needs a bit of a revision.

(Note that the dropdown field is not fully styleable with the current approach, we'll be able to fix it after we implement T74716.)

(The patch above depends on unmerged OOUI patches https://gerrit.wikimedia.org/r/#/c/185376/ and https://gerrit.wikimedia.org/r/#/c/185576/.)

@violetto, your thoughts on how to reconcile the design with the existing special page?

I have added some more technical blockers to this. Accessibility issues (for keyboard users, for screen readers, for older browsers) must be resolved before we start pushing OOUI as a replacement for existing important interfaces.

Looks like the dropdown is still unstyled…

Yes, and the form still looks unpleasant per T86865#983556. The work is progressing, as you can see from the dependent tasks being created and closed, but I am the only person working on this (in spite of my requests for design input; I guess I'm just doing it the way it feels right to me, then), and I have other responsibilities too.

@matmarex the UI standard group decided a while back that we'd try to first style existing form by swapping out the new controls in situ. Certainly this could cause some forms to look longer, wider, or just very different than they do now, but this was the first goal. Then and only then would we start reevaluating the layout of the forms, either simple switches like the ordering of buttons at the bottom (move primary button to the rightmost position) or much more drastic refactoring of the layout as needed.

@Prtksxna can elaborate if need be, he was the one that did much of the audit, and even started thinking about the next step of refactoring some forms/special pages.

Let's stay true to that decision and have this task only be a straight swap of the old controls for OOJS versions. So in that case the feedback it sounds like you need from Design is "stay true to the layout, control ordering, and general structure of the current form while updating the technology of how controls are drawn"

@matmarex Can you update the screenshot, now that T91153 has been resolved? Then @Jaredzimmerman-WMF and @Prtksxna can sign off on whether this is sufficiently "true to the layout, control ordering, and general structure of the current form while updating the technology of how controls are drawn". (From the previous screenshot, once the border is drawn (that was T91153) it seems like the only significant change will be increased whitespace, but maybe I'm missing something.)

In T86865#1113334, @Jaredzimmerman-WMF wrote:

@matmarex the UI standard group decided a while back that we'd try to first style existing form by swapping out the new controls in situ. Certainly this could cause some forms to look longer, wider, or just very different than they do now, but this was the first goal. Then and only then would we start reevaluating the layout of the forms, either simple switches like the ordering of buttons at the bottom (move primary button to the rightmost position) or much more drastic refactoring of the layout as needed.

Interesting. I knew nothing about this. Out of curiosity, which group was that, since I was under the impression that I am a member of at least one frontend standards group? :)

Let's stay true to that decision and have this task only be a straight swap of the old controls for OOJS versions. So in that case the feedback it sounds like you need from Design is "stay true to the layout, control ordering, and general structure of the current form while updating the technology of how controls are drawn"

I'm not sure if this approach will work in this case, I feel that it'll result in enlarging some parts of the form disproportionately. I can try and supply screenshots, though.

I would still like to get T91152 resolved before we continue introducing OOUI widgets into MediaWiki pages. Such size inconsistencies can be very jarring.

In T86865#1158993, @matmarex wrote:

In T86865#1113334, @Jaredzimmerman-WMF wrote:

@matmarex the UI standard group decided a while back that we'd try to first style existing form by swapping out the new controls in situ. Certainly this could cause some forms to look longer, wider, or just very different than they do now, but this was the first goal. Then and only then would we start reevaluating the layout of the forms, either simple switches like the ordering of buttons at the bottom (move primary button to the rightmost position) or much more drastic refactoring of the layout as needed.

Interesting. I knew nothing about this. Out of curiosity, which group was that, since I was under the impression that I am a member of at least one frontend standards group? :)

Jared may be referring to some iteration of UX standardization, in which developers pursued applying the mw-ui- styles throughout core (not really "swapping out the controls"). The idea goes back years. Since https://gerrit.wikimedia.org/r/#/c/150635/ was merged 6 months ago, you get the new MediaWiki appearance in most core forms if you set $wgUseMediaWikiUIEverywhere = true. For grins here's Special:MovePage on my local wiki with this setting:

What is the status of T72424: Set $wgUseMediaWikiUIEverywhere = true? If we're abandoning it to instead convert everything to OOjs UI, let's say so.

Status update:

The form:
In context:
In action:
In MonoBook (using Apex theme):

I think this is passable.

Looks good to me.

Change 185591 merged by jenkins-bot:
SpecialMovepage: Convert form to use OOUI controls

https://gerrit.wikimedia.org/r/185591

• T113492: PHP and JS DropdownInputWidgets have different dimensions (FOUC for the namespace selector dropdown on Special:MovePage)
• T113493: Button on Special:MovePage should be constructive

If there is a bug with this change do I add it here or open a new task? Hopefully someone who is subscribed to this gets it to the right place.

Anyway, the problem I have is that when you try and move a page to a _target that already has a history (essentially you want to perform a delete and move) when the new page loads telling you "The destination page "X" already exists. Do you want to delete it to make way for the move? (Check the edit history.)" you lose whatever you've previously written in the "reason" field. This didn't use to happen.

Also, as more of a general comment from someone who does a lot of moves, does the thing have to be so darn BIG? It seems unnecessary to have to scroll to actually click the "move" button.

I've been told that https://en.wikipedia.org/wiki/Template:RMassist no longer is prepopulating the "reason" field; though I haven't looked at it myself, this seems to confirm "you lose whatever you've previously written in the "reason" field" above. Please back off this change until you fix this. Thanks.

Confirmed the issue here https://en.wikipedia.org/w/index.php?title=Wikipedia:Requested_moves/Technical_requests&oldid=682613393

Note the source code:
&wpReason={{Urlencode:Requested at [[WP:RM]] as uncontroversial ([[Special:Permalink/{{REVISIONID}}|permalink]])}}

but click on "move" and it's not there in the "reason" field.

This is documented here and here:
https://www.mediawiki.org/wiki/Manual:Creating_pages_with_preloaded_text
https://www.mediawiki.org/wiki/Manual:Parameters_to_index.php#Edit_and_submit

I trust that the full functionality as documented there is being maintained?

I'm interested in this bug for the same reasons as Wbm1058 and Jenks24. My guess is that the problem will not be that hard to fix.

I posted a bug about this at T113718 before seeing this.

See T113718: wpReason ignored when performing page moves for an update.

Yes, apologies, I unintentionally broke that feature. Please watch the linked task for updates, I'll try to get the fix (which indeed is very simple) deployed as soon as possible.

In T86865#1672126, @Jenks24 wrote:

Also, as more of a general comment from someone who does a lot of moves, does the thing have to be so darn BIG? It seems unnecessary to have to scroll to actually click the "move" button.

This is a fair point, I filed T113953 where I proposed some ideas.

The mobile page has gotten pretty hard to navigate after this change. Would it be possible to make it responsive?

There seems to be a hardcoded width:50em on the .movepage-wrapper class which seems to be causing the problem.

It's not really a part of this task, but… https://gerrit.wikimedia.org/r/c/mediawiki/core/+/627329