Page MenuHomePhabricator

[Regression pre-wmf.21] The padding for table cell menu items got narrower, making it looked crammed, due to OOUI 0.21.0 release
Closed, ResolvedPublic1 Story Points

Description

I noticed that the padding for each menu items for table cell got narrowed down. IMHO, it does not really look good.

Event Timeline

Ryasmeen created this task.Apr 12 2017, 8:29 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 12 2017, 8:29 PM
Jdforrester-WMF triaged this task as High priority.Apr 12 2017, 9:47 PM
Jdforrester-WMF set the point value for this task to 1.
Jdforrester-WMF moved this task from To Triage to TR0: Interrupt on the VisualEditor board.

The .ve-ui-tableLineContextItem-actionButton .oo-ui-buttonElement-button selector in ve.ui.TableLineContentItem.css sets padding: 0.5em; but that's getting over-ridden by something in OOUI; resetting it with !important doesn't work, but manually setting in the browser console does…

Jdforrester-WMF renamed this task from The padding for table cell menu items got narrower, making it looked crammed to [Regression pre-wmf.21] The padding for table cell menu items got narrower, making it looked crammed, due to OOUI 0.21.0 release.Apr 12 2017, 9:48 PM
Jdforrester-WMF added a subscriber: Esanders.

Change 348402 had a related patch set uploaded (by Esanders):
[VisualEditor/VisualEditor@master] Fix styling of table context in MW theme

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

It really doesn't help that MW and Apex now use completely different internal positioning techniques.

The misconception in how we are making our own lives harder than necessary is IMHO, that we maintain different logic in two themes, where Apex should be just a design (colors, gradients, icons differently) showcase without a lot of or any architectural differences at all.
It's a costly maintenance burden. I don't see the advantage of having the icons positioned in two ways in widgets or to have something like a SelectFileWidget have it's button bigger and left-aligned. When we're assuming that our primary theme is well-balanced from a UX perspective and thoroughly cross-browser & user research tested, why would we take a different approach in a widget in the second maintained theme?
The UX behaviour patterns should be at large the same (min-sizes of buttons, their position in the widget, icon position etc.). Things like a checkmark as option T87835 can stay in. Constructive buttons or differences of the ComboboxInputWidgets (a button appearance should indicate the boundary to the input) have to go.
Every developer can see that we give them all freedom, we don't have to celebrate it our own. Not unwillingly breaking stuff and ensuring cross-browser compatibility and mobile support of the library is already hard enough.

I'm fine to help here if we're clearly stating that MediaWiki theme is the one primary theme and leads the way when it comes to internal changes (only with good arguments) and Apex will follow those with probably some disruptive changes to the users of Monobook skin.

Change 348402 merged by jenkins-bot:
[VisualEditor/VisualEditor@master] Fix styling of table context in MW theme

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

Change 348497 had a related patch set uploaded (by Jforrester):
[mediawiki/extensions/VisualEditor@master] Update VE core submodule to master (fc46ed86f)

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

Change 348497 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] Update VE core submodule to master (fc46ed86f)

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

Jdforrester-WMF closed this task as Resolved.Apr 17 2017, 9:37 PM
Jdforrester-WMF assigned this task to Esanders.
Jdforrester-WMF removed a project: Patch-For-Review.
Restricted Application added a project: User-Ryasmeen. · View Herald TranscriptApr 17 2017, 9:37 PM