|Open||None||T49145 Formally deprecate jQuery UI after we've stopped using jQuery UI in extensions and core (replacing it with OOUI).|
|Open||None||T100270 Replace use of jQuery UI and MW UI with OOUI across all Wikimedia-deployed extensions and core|
|Open||Goal||None||T122014 Convert all extensions/skins to OOUI|
|Open||None||T208687 Convert SecurePoll to use OOUI|
|Resolved||wikitrent||T273044 Convert SecurePoll VotePage to use OOUI|
|Resolved||DLynch||T276763 Convert RadioRangeBallot to use OOUI|
I'll go ahead and do the more aggressive switch to getInputOOUI in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/SecurePoll/+/669715/ since I think you'd want to do it here anyways.
EDIT: actually, it's a lot more work, and I think it's workable without it. So... maybe not?
HTMLForm has a "flatlist" modifier which lines up check/radio inputs inline. This modifier doesn't seem to be ported into OOUI. I think this came up during some earlier ports to OOUI but it wasn't as obvious. If I have too many options or questions in a radio range ballot, it ends up looking fairly unwieldy:
And here's what it used to be:
- Did I understand the limitation correctly? I didn't see any modifier in the docs/skimming the code
- Even if the radio buttons are inline, I don't think there's any way to get that table look using a FieldLayout. Can someone confirm?
Given this, what do we want to do about it, assuming it's a non-zero cost to do something? SecurePoll CSS? Add inlining upstream?
Had another look at this and chatted with @DLynch and I don't think ButtonSelectWidget is the correct way to go because the markup uses buttons. This 1. removes the semantic relationship between the inputs (radio inputs are all tied together by their name attribute) and 2. makes it difficult to support no-js/use standard form submits since buttons don't normally pass along data like that*
- We do pass along some data with the submit button, but I don't think this is necessarily supported out of the box
I have a few other possible proposals, ranked from easiest to hardest (with a somewhat linear correlation of Less Wrong to More Right)
- Do nothing - literally nothing. We just leave it as is. The OOUI stuff is being deprioritized as the quarter's ending so we could just not get to whatever's left, including this task.
- Use CSS to style the radio buttons inline - I think this works, as long as there isn't any ltr/rtl stuff to consider
- Use OOUI to re-create the table structure - I think this is doable because you get to define the name for each radio input so it would be a bunch of radio inputs with the same name and one option each
- Make CheckMatrixWidget’s compatible with RadioInputWidget - theoretically doable, based on the same assumption that makes 3 doable
- Make a MatrixWidget that only provides the scaffolding for the matrix and allows you to pass whatever objects into it, including check inputs and radio inputs
Moving this to Needs Design because it depends on what sort of final layout we're okay with, assuming we're moving forward. 3-5 would get us closer to the original layout but 2 is faster if we're okay with duplicating the labels like that. We don't necessarily even have to do any of this yet, hence 1.
My primary concern is that the basic layout of the voting interface remains the same, and it doesn't take up more vertical space than it needs to (especially as the number of candidates can easily be over 10). So, I'd be against (1).
Would (2) look something like this?
If so, this is workable, as its the same vertical space. But not ideal because of the repetition.
If 3-5 would essentially be the same as the current layout I would prefer that. This is one of the few user facing interfaces of the feature and I think it'd be good to keep it the same.