Page MenuHomePhabricator
Create Task
Maniphest T216070

Unify ButtonWidget padding usage and reduce CSS hacks
Closed, ResolvedPublic
Actions

Assigned To
Volker_E
Authored By
Volker_E
Feb 13 2019, 8:39 PM
Tags
Referenced Files
F28212994: image.png
Feb 14 2019, 12:30 AM
F28212978: image.png
Feb 14 2019, 12:30 AM
F28211567: image.png
Feb 13 2019, 9:15 PM
F28211350: Screenshot 2019-02-13 at 12.40.18.png
Feb 13 2019, 8:45 PM
F28211351: Screenshot 2019-02-13 at 12.42.46.png
Feb 13 2019, 8:45 PM
F28211282: image.png
Feb 13 2019, 8:39 PM
F28211278: image.png
Feb 13 2019, 8:39 PM
Subscribers
Aklapper
Esanders
gerritbot
Jdforrester-WMF
Ryasmeen
Volker_E

Description

The original work on improving and unifying button appearance and CSS was accompanied with a certain combination of workarounds to make up for a Firefox/macOS rendering quirks:
When font family is set to generic sans-serif, Firefox (at least for the last 20+ versions, with current version being v65) seems to use “Helvetica Neue” for it.
But it applies a different line-box when applying sans-serif than all other major browser on macOS (Chrome, Safari) ending up in a lower than expected base line:

image.png (94×948 px, 17 KB)
and emphasized
image.png (94×948 px, 17 KB)

Reduced code example:
https://codepen.io/Volker_E/pen/JxBqLQ

Reported upstream:
https://bugzilla.mozilla.org/show_bug.cgi?id=1527735

This has led me to implement different top/bottom paddings with an uneven line-height, but it was a bad choice for further cross-browser consistent rendering and also for code size.
We need to unify paddings and line-height to more sane values.

Details

SubjectRepoBranchLines +/-
WikimediaUI theme: Unify `padding-top` and `padding-bottom` valuesoojs/uimaster+2 -2
Update OOUI to v0.30.3mediawiki/coremaster+174 -111
WikimediaUI theme: Use consistent base size for TagMultiselectWidget's inputoojs/uimaster+2 -0
WikimediaUI theme: Provide single-line TextInputWidgets with a distinct heightoojs/uimaster+3 -0
WikimediaUI theme: Remove variables with duplicated valuesoojs/uimaster+18 -20
Customize query in gerrit

Related Objects

Event Timeline

Volker_E created this task.Feb 13 2019, 8:39 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 13 2019, 8:39 PM
Jdforrester-WMF added a comment.Feb 13 2019, 8:45 PM

Tested on FF (standard settings) and Chrome (PT Sans as my sans-serif font):

Firefox
Screenshot 2019-02-13 at 12.40.18.png (90×947 px, 17 KB)
Chrome
Screenshot 2019-02-13 at 12.42.46.png (81×951 px, 17 KB)
Volker_E updated the task description. (Show Details)Feb 13 2019, 9:03 PM
Volker_E added a project: UI-Standardization-Kanban.
Restricted Application added a project: UI-Standardization. · View Herald TranscriptFeb 13 2019, 9:04 PM
Volker_E added a comment.Feb 13 2019, 9:15 PM

Current OOUI treatment with different top and bottom paddings does result in asymmetrical layout on Windows/Firefox for example:

image.png (90×366 px, 19 KB)

gerritbot subscribed.Feb 13 2019, 11:51 PM

Change 490502 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[oojs/ui@master] WikimediaUI theme: Unify padding-top and padding-bottom values

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

gerritbot added a project: Patch-For-Review.Feb 13 2019, 11:51 PM
gerritbot added a comment.Feb 14 2019, 12:25 AM

Change 490506 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[oojs/ui@master] WikimediaUI theme: Remove variables with duplicated values

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

Volker_E added a subscriber: Esanders.Feb 14 2019, 12:27 AM

@Esanders Would be great to have a comparison/review on Linux as well…

Volker_E added a comment.Feb 14 2019, 12:30 AM

Firefox 65/Win 7 (emulated):

BeforeAfter
image.png (88×906 px, 35 KB)
image.png (92×906 px, 49 KB)
Volker_E triaged this task as High priority.Feb 14 2019, 12:31 AM
Volker_E moved this task from Backlog to Reviewing on the OOUI board.
Volker_E mentioned this in T213334: Road to OOUI v1.0.0.
matmarex unsubscribed.Feb 14 2019, 1:23 PM
gerritbot added a comment.Feb 19 2019, 11:34 PM

Change 491652 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[oojs/ui@master] WikimediaUI theme: Provide single-line TextInputWidgets with a distinct height

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

gerritbot added a comment.Feb 20 2019, 3:59 AM

Change 491681 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[oojs/ui@master] WikimediaUI theme: Use consistent base size for TagMultiselectWidget's input

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

Volker_E added a subscriber: Ryasmeen.Feb 20 2019, 6:57 PM

@Ryasmeen QA steps from my POV:
All kinds of

are affected (and should just see a change by 1 pixel of vertical text alignment in the widgets in all browsers aside of Firefox/macOS, which interprets it wrongly and shows a misalignment, that's known).
But nothing more than that.

Please consider comparing those widgets on a few special pages, like RecentChanges

gerritbot added a comment.Feb 20 2019, 7:04 PM

Change 490502 merged by jenkins-bot:
[oojs/ui@master] WikimediaUI theme: Unify padding-top and padding-bottom values

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

gerritbot added a comment.Feb 20 2019, 7:07 PM

Change 490506 merged by jenkins-bot:
[oojs/ui@master] WikimediaUI theme: Remove variables with duplicated values

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

gerritbot added a comment.Feb 20 2019, 7:07 PM

Change 491652 merged by jenkins-bot:
[oojs/ui@master] WikimediaUI theme: Provide single-line TextInputWidgets with a distinct height

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

gerritbot added a comment.Feb 20 2019, 7:52 PM

Change 491681 merged by jenkins-bot:
[oojs/ui@master] WikimediaUI theme: Use consistent base size for TagMultiselectWidget's input

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

Volker_E moved this task from Reviewing to OOUI-0.30.2 on the OOUI board.Feb 20 2019, 9:40 PM
Volker_E edited projects, added OOUI (OOUI-0.30.2); removed OOUI.
Volker_E moved this task from OOUI-0.30.2 to OOUI-0.30.3 on the OOUI board.Feb 21 2019, 3:47 AM
Volker_E edited projects, added OOUI (OOUI-0.30.3); removed OOUI (OOUI-0.30.2).
Volker_E removed a project: Patch-For-Review.Feb 21 2019, 4:17 AM
gerritbot added a comment.Feb 21 2019, 11:08 AM

Change 491943 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/core@master] Update OOUI to v0.30.3

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

gerritbot added a project: Patch-For-Review.Feb 21 2019, 11:08 AM
gerritbot added a comment.Feb 21 2019, 3:58 PM

Change 491943 merged by jenkins-bot:
[mediawiki/core@master] Update OOUI to v0.30.3

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

Volker_E added a comment.Feb 21 2019, 9:26 PM

Related as in following-up at T209455: mediawiki.ui's .mw-ui-input and .mw-ui-button feature different height

Volker_E closed this task as Resolved.Feb 26 2019, 2:12 AM

Mozilla feedback from upstream task:

If I view this example on macOS, I see a discrepancy like in the screenshot.

However, the reason for this is that by default, sans-serif maps to Helvetica (not Helvetica Neue) on macOS; at least, that's what is set in the default prefs.[1] As such, there's no expectation that a button formatted with Helvetica Neue will exactly match one using sans-serif.

If I modify the example to specify Helvetica for the right-hand button, it matches the left-hand one; or if I modify the font prefs to use Helvetica Neue for sans-serif, they also match.

So there's a cross-browser inconsistency that we seemingly have to live with. Went with the default that works for Firefox/Win, Firefox/Ubuntu but has this glitch on Firefox/macOS.
Resolved from our side.

Restricted Application added a project: User-Ryasmeen. · View Herald TranscriptFeb 26 2019, 2:12 AM
Volker_E raised the priority of this task from High to Needs Triage.Feb 26 2019, 2:15 AM
Volker_E removed a project: Patch-For-Review.
Volker_E moved this task from Backlog to Done on the UI-Standardization-Kanban board.
Ryasmeen added a comment.Feb 27 2019, 1:01 AM
In T216070#4969476, @Volker_E wrote:

@Ryasmeen QA steps from my POV:
All kinds of

are affected (and should just see a change by 1 pixel of vertical text alignment in the widgets in all browsers aside of Firefox/macOS, which interprets it wrongly and shows a misalignment, that's known).
But nothing more than that.

Please consider comparing those widgets on a few special pages, like RecentChanges

@Volker_E: Checked these on Special: Preferences and Special: RecentChanges page using Safari. Nothing seems out of place so far.

Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL