Convert several MW core special pages to OOUI as a demonstration that it's possible now.
Part of "front-end standardisation" Q2 priority project.
Description
Description
Details
Details
- Reference
- bz72715
Event Timeline
Comment Actions
Change 208285 had a related patch set uploaded (by Bartosz Dziewoński):
[WIP] Switch some HTMLForms in special pages to OOUI
Comment Actions
Here are some screenshots of the "first iteration", brought to you by @MarkTraceur's work on T85291. These pages were previously using the "VForm" style and switching them over to the new "OOUI" style, once implemented, is a matter of changing a single value.
Special: ChangeEmail
| VForm | OOUI |
|---|---|
Special: ResetPassword
| VForm | OOUI |
|---|---|
Issues:
- The help icon looks slightly blurry, this will be fixed after T97631.
- The checkbox is smaller, this is a design decision being discussed on T86003.
Special: PageLanguage
| VForm | OOUI |
|---|---|
Issues:
Comment Actions
Also, once the value is changed, we can take out some of the weird special-casing in forms that use OOUI or mwui in part - BetaFeatures comes to mind immediately (so Special:Preferences in general), but OAuth and many other core forms will benefit.
Comment Actions
Change 208285 had a related patch set uploaded (by Jforrester):
[WIP] Switch some HTMLForms in special pages to OOUI
Comment Actions
Change 208285 had a related patch set uploaded (by Mattflaschen):
[WIP] Switch some HTMLForms in special pages to OOUI
Comment Actions
This is excellent!
Are you going to Cc a designer to review? E.g. the label was intended to sit closer to the field underneath, which is still the case on login form.
These pages were previously using the "VForm" style and switching them over to the new "OOUI" style
vform stood for "vertically-stacked form", everything was intended to be the same width. It was a $displayFormat different from the existing div, table, and raw which also used mediawiki.ui styles. I think clients should be able to request buttons styled as OOUI without getting the vform layout e.g. OOUI buttons in 'table' display format.
When you specify 'vform' as displayFormat, the form width needs to be constrained. (Picking a width for vform was challenging, it ended up being determined by the width of the restyled FancyCaptcha on the login form.).
Comment Actions
Are you going to Cc a designer to review? E.g. the label was intended to sit closer to the field underneath, which is still the case on login form.
I don't know who would review these, or if there's anyone willing to at all? If anyone has any feedback to offer, we'll be happy to hear it. Just note that this is the same interface as used in VisualEditor's dialogs and any changes should fit both use cases.
There is about twice as much spacing between the label and widget in OOUI-styled forms than in the old ones, but the widgets are also about twice as big. I agree that the OOUI style might be a bit too whitespacey, though.
vform stood for "vertically-stacked form", everything was intended to be the same width. It was a $displayFormat different from the existing div, table, and raw which also used mediawiki.ui styles. I think clients should be able to request buttons styled as OOUI without getting the vform layout e.g. OOUI buttons in 'table' display format.
It should be possible to use OOUI widgets for existing forms, let's just be cautious about this to avoid breaking interfaces. OOUI integrates seamlessly with HTML, so you can just replace, say, Html::input( $name, $value, 'submit' ) with new OOUI\ButtonInputWidget( array( 'name' => $name, 'value' => $value, 'type' => 'submit' ) ). We could do the same in HTMLFormField subclasses, possibly controlled by some config, if anyone desires. I'm not sure how useful this would be in general, though.
The various display formats of HTMLForm are terribly confused, eh. I think a better naming would be 'horizontal' instead of 'table' and 'vertical' instead of 'div', since that's basically what these two result with. 'vform' would then be 'vertical-mediawikiui' and 'ooui' would be 'vertical-oui'. But this is probably not worth doing.
While we're using a vertical layout in OOUI HTMLForm, and while this is the generally recommended layout for OOUI forms, we do sort of kind of support a more horizontal one too – you can it by setting align: 'left' rather than align: 'top' for individual FieldLayouts. It doesn't exactly behave like 'table' HTMLForm, though, especially for individual checkboxes/toggles. It looks like this:
When you specify 'vform' as displayFormat, the form width needs to be constrained. (Picking a width for vform was challenging, it ended up being determined by the width of the restyled FancyCaptcha on the login form.).
OOUI form widgets' widths are generally limited to 50em (~600px, depending on the skin) for sanity (to avoid input fields stretching across the whole width of 4k display, for example), but this isn't a hard limit.
Comment Actions
I think this task, as written ("Convert some MW core special pages to OOUI"), is sufficiently resolved. We have converted some special pages, and then some more (although most of the relevant commits weren't linked to this bug).
Quick tally:
- Special:ChangeContentModel (fa31bf1675af7255431aeffd9757066e0ce572e2)
- Special:ChangeEmail (b51076a84446d157bed511246450e70d26e0f945)
- Special:LinkSearch (5bd98dacfaaf08e9645fdb215a6e18e9d7f80c04)
- Special:PageLanguage (b51076a84446d157bed511246450e70d26e0f945)
- Special:PasswordReset (b51076a84446d157bed511246450e70d26e0f945)
- Special:ResetTokens (2550de9552230585e33b45f37cada0f13e396953)
Several more are in progress or waiting for reviews.