Change 502620 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/core@master] History form can be collapsed

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

There is no point to make form bigger than it was, and collapsing it after that. Here is my proposal (just for preview):

#mw-history-searchform .oo-ui-fieldsetLayout-header {
  display: none;
}
#mw-history-searchform .oo-ui-fieldsetLayout-group .oo-ui-widget {
  display: flex;
  align-items: flex-end;
}
#mw-history-searchform #ooui-php-4 {
  margin: 0 0.8em;
  flex: 0 1 30em;
}
#mw-history-searchform #ooui-php-3 .oo-ui-fieldLayout-header .oo-ui-labelElement-label {
  text-transform: lowercase;
}
#mw-history-searchform #ooui-php-3 .oo-ui-fieldLayout-header .oo-ui-labelElement-label:before {
  content: "Show revision history ";
  text-transform: none;
}

@SerDIDG We need to support IE 8-10 for basic interaction, so Flexbox only is not a viable solution.
Also, if vertical space is the main issue, collapsing is making the life for n use cases better…

Change 502620 merged by jenkins-bot:
[mediawiki/core@master] History form can be collapsed

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

We've merged a patch by @Jdlrobson to collapse form by default and make it expandable. After looking through VillagePump, through the comments on T107069 and talking to more long-term contributors: The overwhelming majority of use case seems NOT to involve interacting with the form at all.

With the patch we're focussing on three sides:
a) if functionality is rarely used, it's useful to have it hidden by default,
b) if vertical space is main issue – collapsing is providing more vertical space than before OOUI transformation without
c) introducing technical/user experience debt by inlining form elements unlike other OOUIfied forms.

The change can already be tried out on Beta Cluster and we could SWAT it 24h of now, depending on feedback here from you volunteer contributors…

I do not propose to use exactly my piece of code, there plenty workarounds for IE. For example we can use float or inline-block instead of flexbox.

@Volker_E I'm not an expert and may be wrong/out of date, but aren't there either accessibility and mobile issues with collapsing? I vaguely recall DJ putting a lot of work in on that front. One issue I can see is that if you do use the form, the page applies the filters, but the box is collapsed upon reloading and there is no indication you are looking at filtered content without checking the url. Assuming people continue to infrequently use the filters it may lead to confusion.

It's obviously nice to have the real estate, but would it really be ux debt? As mentioned on the main task, there's a difference between a frequently-used form that is the main goal of the page (move, delete) and one that is mostly incidental to typical use of the page. I would think people might appreciate more use of the horizontal space in OOUI forms (where appropriate) as a general matter, but in this particular case, especially as the tag filter box is not a lookupElement, the extreme length of the box is excessive. Something similar could be done for other places where this exact combination (single date selector+tag filter) occurs, such as Special:Log (T117737) and is already being contemplated the Special:Contributions use of two date selectors+tag filter (T117736).

Change 503085 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[mediawiki/core@master] HistoryAction: Amend margin in collapsed form state

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

Change 503085 merged by jenkins-bot:
[mediawiki/core@master] HistoryAction: Amend margin in collapsed form state

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

In T220555#5100567, @Amorymeltzer wrote:

@Volker_E I'm not an expert and may be wrong/out of date, but aren't there either accessibility and mobile issues with collapsing? I vaguely recall DJ putting a lot of work in on that front.

There should not be any accessibility issues. As long as the button to expand the form is visible to screen readers and keyboard-accessible, it will be fine.

One issue I can see is that if you do use the form, the page applies the filters, but the box is collapsed upon reloading and there is no indication you are looking at filtered content without checking the url. Assuming people continue to infrequently use the filters it may lead to confusion.

I was going to complain about this as well. I think the form should be expanded if any options were changed.

I think, @Amorymeltzer's concern is not completely dismissible. The button says 'show' it has no clear indication for a screen reader what it will show, sure the next thing in the DOM is the form's legend, nonetheless a clearer connection (maybe an aria-expanded attribute on the collapsible element as first idea).
Nonetheless I think this specific task is resolved and the questions raised belong on more general tasks.