Maniphest T220671

Replace `em` based sizing in favor of `px` based where applicable
Closed, ResolvedPublic
Actions

Assigned To

None

Authored By

	Volker_E
	Apr 11 2019, 2:33 AM

Description

Mainly originated in two(?) specific needs, OOUI has been using em based sizing in its code base:

Establishing relative sizes to the parent elements, resulting in simpler sizing balance in more complex widgets
Enabling zooming capabilities on old browsers like IE 6
1. Enabling text zooming only full-interface capabilities, which got more and more hidden in most modern browsers

Problem statement

Ability has never been implemented well.

Take as example ContentTranslation on Vector dialogs: We need to set font-size: 0.875em rules on elements that are outside of .mw-body-content to ensure correct scaling root.

Functionality is not needed in the original scope any more as those browsers are beyond end-of-life support, effective January 12, 2016. Every other major browser nowadays supports full-page-zooming for several years now.

What remains needed from current state of technology, is the ability for users to set their font size in browser preferences. Using px for font-size removes this ability! (see below)

Additionally, we ran into several issues with em based sizing:

Design templates have to be translated to ems, which is ignored under time pressure (see examples below)
em values not being taken care of very carefully (values like 0.5 or 1em connected with root font size) resulting in sub-pixel values, that result in cross-browser rendering issues T130691
Code hard to write when being careful about ems (@start-framed-indicator-only: 15 / @ooui-font-size-browser / @ooui-font-size-base; LESS var definition)
Maintaining and changing code is hard, currently looking up the right number is more painful than necessary in WikimediaUI theme.
Harder to debug code, especially when comparing to design templates (one has to take extra step from styles to computed tab in dev tools with margin-top: 1.14285714em;)

Example of current issues in code:

OOUI WikimediaUI theme (covered by patch)
MW core DateInputWidget: https://github.com/wikimedia/mediawiki/blob/master/resources/src/mediawiki.widgets/mw.widgets.DateInputWidget.styles.less#L21 (hard to write, hard to debug, depending where you're starting)
Echo: https://github.com/wikimedia/mediawiki-extensions-Echo/blob/master/modules/styles/mw.echo.ui.NotificationBadgeWidget.less#L17 (hard to write, hard to maintain, hard to debug)

If we go further and apply that approach to other, non-OOUI based products, for example:

We already have a mix of px based where em was supposed to be used, for example:

Proposal

Therefore we should limit the usage of em to the properties where it enables font size users' settings for accessibility reasons:

readability by font-size– connected line-height only with relative, unit-less values
icon sizing as icons are an important information carrier in the user interface and could also result in covered textual information if not sized in ems alongside text. Sizing here includes width/height, padding to the surrounding text.
width/height and max-width/max-height property values as they would result in cutting off user sized text when set larger than default size

And usage of px for all the rest.
Result is a perfectly laid-out result at default font size and an always full readable without text clippings at larger font size.

Remove em based sizing in favor of px on all box sizing properties, like width, margin, padding, border, box-shadow
Evaluate if font-size is needed either by feature branch and cross-browser testing
- Evaluate font-size override in user-agent settings differences

Decisive point for font-size in ems:
User's choice of other starting size for default font would not impact browser rendering when set to px. A popular accessibility feature and a no-go for user customization. font-sizes should remain in a relative value unit.
Nonetheless box-sizing properties could be used in px when ensuring that for example height/max-height are not set to an absolute value.
Try for yourself to set the standard font higher than the default 16px and browse your favorite websites (see dev notes below).

Wins through pixels (for box-sizing properties max-width, max-height, margin, padding, border, …)

Simpler hand-off between designers/developers
Easier to write code (no more @start-framed-indicator-only: 15 / @ooui-font-size-browser / @ooui-font-size-base; LESS var definition)
Easier to maintain code
Easier to debug code (no more margin-top: 1.14285714em;

Losses through pixels

The library would not be fully theme/root font-size independent from the very beginning on. This seems like a negligible issue as OOUI with would still work at user preference font size between 13px and 18px, which seem to be default sizes for big majority of websites. It's also not expectable that someone outside Wikimedia universe would use WikimediaUI theme out of box and if they alter, they have access to come up with own sizing similar to WikimediaUI theme's common.less.

13px	18px

Comparison with other big web entities

All tested in IE 8&9

Google search homepage
- widths/margins/paddings/borders in px
- font-size px
- line-height em (ex: 0.8em) or rel (ex: 1.2)

Medium
- widths/margins/paddings/borders in px
- fonts px
- line-heights relative (ex: 1.22)
- Doesn't support IE<11 any more

Facebook
- widths/margins/paddings/borders in px
- font-size px or relative (ex: medium)
- line-height px
- IE 8 is not supported anymore

eBay Germany
- widths/margins/paddings/borders in px
- font-size % or relative or px (ex: medium)
- line-height px
- IE 8 only basic support any more

NYTimes
- widths/margins/paddings/borders in px
- font-size rem, but not for older browsers
- line-height rem
- IE 8 is not supported any more

Dev notes

Use

Firefox: Preferences > Language and Appearance > Fonts and Colors > Size > Pump up tp 44
Chrome: Preferences > Appearance > Font size > Very large

and browse the web and compare with OOUI demos
From qualitative user feedback in accessibility circles, increasing the default font size is one of the most used user settings.

Further resources

Details

	Subject	Repo	Branch	Lines +/-
	WikimediaUI theme: Use `px` instead of `em`s	oojs/ui	master	+96 -83
	Update OOUI to v0.35.0	mediawiki/core	master	+311 -293

Customize query in gerrit

Related Objects

Mentioned In: T244823: MediaWiki core, WikimediaUI themed skins and extensions: Use Codex design tokens to replace `em` based sizing in favor of `px` based
T235850: UI elements misaligned and misplaced
rWBTB688675406fe1: IndeterminateProgressBar: fine tune shadow
T239653: Use px units instead of ems in LESS for most values
T229568: Apply consistent small font-sizes in MobileFrontend/MinervaNeue
T226795: Align core legacy error/warning/success messages/message box visual appearance close to Style Guide
Mentioned Here: T130691: Sub-pixel rendering layout issues with `em` or `%` relative units (tracking)

Event Timeline

Volker_E created this task.Apr 11 2019, 2:33 AM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 11 2019, 2:34 AM

From IRC conversation with @Krinkle earlier today

17:07 <Volker_E> compared Google and Facebook, very mixed approaches, mostly based on px now for nearly everything
17:38 <Krinkle> Yeah, CSS "px" nowadays has a fairly consistent ratio to physical size. And worst case scenario (e.g. someone running 800x600 on a 4K monitor for some reason), it will at least match their expectation relative to everything else.
17:38 <Krinkle> But, that only applies to the top-level.
17:38 <Krinkle> I realise now the question of em is more about code management. relative size management.
[…]
17:40 <Krinkle> My gut would tell me that inheritance is almost always a bad idea. And em would fit with that. Magic indirection, almost never intentional. That feeling of "it will all magically adjust" - I have never seen it happen in a way that was intentional.
17:40 <Krinkle> once upon a time there were browsers that adjusted text-based zoom separately but afaik that's not a thing anymore.
17:41 <Krinkle> So yeah, maybe absolute pixels in code would make things easier to reason about and standardise, especially when the context is uncertain.
17:42 <Krinkle> If I embed an OOUI button somewhere, you probably don't want it to vary by a random <div> that happens to set font-size for some reason. And in the rare case you do, there's probably a "small button" class or some such.

I think being able to resize everything by just increasing the font-size is valuable and convenient. Example use cases:

Bigger buttons

Mostly for call-to-action kind of buttons. Example: https://commons.wikimedia.org/wiki/Special:UploadWizard

The "Select media files to share" is made larger than normal by adding font-size: large; to it.

Bigger icons

Mostly in headings etc. Example: https://en.wikipedia.org/wiki/Special:CreateAccount

(Currently not using OOUI icons, but it probably should.)

Volker_E updated the task description. (Show Details)Apr 26 2019, 10:01 PM

@matmarex Those possibilities would largely remain, just in a different way.

In your example of Special:Uploads, font-size would remain relative, so even with only defining font-size: larger and not taking care about padding in a separate selector, the difference would be

With only `em`s	With `padding` in `px`

Not perfect, but acceptable. For this specific issue I'd even recommend providing a “larger” button option out-of-box in the lib.

For icons we could still apply sizing in ems and document where ems are of a necessity/or advantage. To go even further, I haven't seen one good example where the flexibility is used in a convincing way, but several times I've been in conversations with cursing peers on this specific topic, as it's additional complexity which sees very little acceptance or duplication when we look into what most of other Foundation products do.

I'm convinced that changing most of the mentioned values over will bring a relief from a historically-induced dead weight.

Volker_E updated the task description. (Show Details)Apr 26 2019, 10:41 PM

In a related story, the flexibility of the library in base font-size mostly remains.

MinervaNeue at `16px` before	after

It would be a minimal reduction from 35.69 px to 34px height.

Let's keep in mind, ability to increase button font-size and therefore appearance of the button also remains.
That should even work with nested widgets.

Pginer-WMF subscribed.Jun 4 2019, 5:50 PM

Volker_E triaged this task as High priority.Jun 6 2019, 8:14 PM

Volker_E updated the task description. (Show Details)

Exemplified on OOUI with new px based values in Chrome with 26px font-size in settings:

Change 514970 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[oojs/ui@master] [DNM] WikimediaUI theme: Use px instead of ems

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

gerritbot added a project: Patch-For-Review.Jun 6 2019, 10:49 PM

Volker_E renamed this task from Replace `em` based sizing in favor of `px` based to Replace `em` based sizing in favor of `px` based where applicable.Jun 12 2019, 3:07 AM

Volker_E moved this task from Backlog to Reviewing on the OOUI board.

Volker_E updated the task description. (Show Details)Jun 13 2019, 2:01 AM

Volker_E updated the task description. (Show Details)Jun 13 2019, 9:02 PM

Note, the one very visible difference with the patch is the vertical slight alignment issues in buttons when user chooses a bigger font-size. We could use a line-height equal to the minimum height, but that would once and for all negatively impact the multi-line ability of buttons largely. So I think it's more acceptable to have a button label slightly misaligned from a rather large default font size like 22 on.

In T220671#5257758, @Volker_E wrote:

Note, the one very visible difference with the patch is the vertical slight alignment issues in buttons when user chooses a bigger font-size. We could use a line-height equal to the minimum height, but that would once and for all negatively impact the multi-line ability of buttons largely. So I think it's more acceptable to have a button label slightly misaligned from a rather large default font size like 22 on.

Aligning stuff in CSS is another classic issue. One approach that can be considered is to use flexbox which is intended to simplify the problem and browser support seems quite good. Especially if we are considering cases where very old browsers will get a slightly missaligned UI instead of a completely broken one.

Another benefit of the 'em' approach has been that it nudges users towards a grid, where the smallest unit is 14px, for example without looking up any less constants I know that padding for framed content should be 1em. If we switch to px, no doubt we will see much more inconsistency in margins and paddings.

In T220671#5292590, @Esanders wrote:

Another benefit of the 'em' approach has been that it nudges users towards a grid, where the smallest unit is 14px,

The problem with our current environment in this “logic” is that we've got a 14px “grid” (actually 7px) as on Vector and a 16px grid (8px) on MinervaNeue. A sometimes painful confusion for both, designers and implementors.
When you're designing on mobile and desktop, like just recently on the GrowthExperiments you suddenly have to switch your calculation base in all templates.

That's only a problem if you have to mix your ems with px. If you do everything in ems then everything will just scale for you. Yes the designs will scale slightly between the platforms, but not to a level that causes serious problems.

In my experience, the more problematic aspect of ems is that they are dependent on their container. So reusing a UI element in two different areas or making any changes that affects their container leads to unexpected inconsistencies that are hard to catch.

In T220671#5295333, @Pginer-WMF wrote:

In my experience, the more problematic aspect of ems is that they are dependent on their container. So reusing a UI element in two different areas or making any changes that affects their container leads to unexpected inconsistencies that are hard to catch.

It can cause issues but it's also a feature, per T220671#5113227

In T220671#5292614, @Esanders wrote:

That's only a problem if you have to mix your ems with px. If you do everything in ems then everything will just scale for you. Yes the designs will scale slightly between the platforms, but not to a level that causes serious problems.

And that's exactly among the main reasons that brought us here, as we can't always use 0.5em multipliers due to other issues laid out in T130691.
Hence em sizing often ends up in sub-decimal numbers that are harder to understand, harder to get right and very uncommon in the Web out there making it another hurdle to get into our environment for newcomers.
Nor do devs use ems consistently due to limitations like inheritance or time-budgeting. From current Wikimedia deployed codebase, there's a lean towards px.
See VisualEditor for example:

Therefore reducing complexity and limiting them to the absolute necessary minimum appears as preferable solution.

Volker_E updated the task description. (Show Details)Jul 10 2019, 5:50 PM

Further examples where our current mix fails:

T220671 em to px - Translate page - Note This utility is currently restricted to extended confirmed editors on the English Wikipedia - 2019-07-11.png (1×1 px, 149 KB)

T220671 em to px - MinveraNeue issue_Talk_Compiler - Wikipedia 2019-07-11.png (1×1 px, 83 KB)

T220671 em to px - Make your donation now - Wikimedia Foundation 2019-07-11 09-40-21.png (1×2 px, 498 KB)

Volker_E mentioned this in T226795: Align core legacy error/warning/success messages/message box visual appearance close to Style Guide.Jul 13 2019, 8:31 PM

Volker_E added a project: MediaWiki-General.Jul 15 2019, 10:41 AM

Volker_E updated the task description. (Show Details)Jul 15 2019, 10:46 AM

To the concern of vertical alignment of buttons at higher font sizes:
The default size (16px) stays default

at 20px default size or 125%

Chrome	Firefox

at 24px default user choice or 150%

Again, this is only a minor side-issue from my point of view, as we're not negatively impacting the functionality. In contrast to other websites out there we're enabling the text zoomability on our products.

Volker_E updated the task description. (Show Details)Jul 29 2019, 11:55 AM

Volker_E added a subscriber: • Prtksxna.

Volker_E added a project: Accessibility.Jul 29 2019, 12:00 PM

Volker_E updated the task description. (Show Details)

Volker_E updated the task description. (Show Details)Jul 29 2019, 12:10 PM

Volker_E updated the task description. (Show Details)

Volker_E updated the task description. (Show Details)Jul 29 2019, 12:23 PM

Volker_E updated the task description. (Show Details)Jul 29 2019, 1:33 PM

Volker_E mentioned this in T229568: Apply consistent small font-sizes in MobileFrontend/MinervaNeue.Aug 1 2019, 10:59 AM

Volker_E updated the task description. (Show Details)Aug 2 2019, 1:32 PM

Volker_E updated the task description. (Show Details)Sep 11 2019, 8:04 PM

Volker_E added a project: Front-end-Standards-Group.

Change 514970 merged by jenkins-bot:
[oojs/ui@master] WikimediaUI theme: Use px instead of ems

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

Volker_E moved this task from Reviewing to OOUI-0.35.1 on the OOUI board.Sep 16 2019, 4:19 PM

Volker_E edited projects, added OOUI (OOUI-0.35.1); removed OOUI.

As stated in task description, this change shouldn't have any visual impacts, as any former em based derived interface is still relying on unchanged parent's font-size (skin, extension, library, etc.) or root elements font-size (skin).

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

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

Volker_E moved this task from Inbox to Accepted on the Front-end-Standards-Group board.Oct 9 2019, 8:28 PM

Change 541905 abandoned by VolkerE:
Update OOUI to v0.35.0

Reason:
for v0.35.1, which is on its way

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

Trizek-WMF added a project: User-notice.Oct 22 2019, 4:41 PM

Restricted Application added a subscriber: Masumrezarock100. · View Herald TranscriptOct 22 2019, 4:41 PM

Johan moved this task from To Triage to In current Tech/News draft on the User-notice board.Oct 24 2019, 10:53 AM

Johan moved this task from In current Tech/News draft to Already announced/Archive on the User-notice board.Oct 30 2019, 12:29 PM

AnneT mentioned this in T239653: Use px units instead of ems in LESS for most values.Dec 2 2019, 7:45 PM

• Pablo-WMDE mentioned this in rWBTB688675406fe1: IndeterminateProgressBar: fine tune shadow.Dec 4 2019, 2:05 PM

Volker_E mentioned this in T235850: UI elements misaligned and misplaced.Dec 11 2019, 5:02 PM

Volker_E closed this task as Resolved.Feb 11 2020, 3:41 AM

Volker_E mentioned this in T244823: MediaWiki core, WikimediaUI themed skins and extensions: Use Codex design tokens to replace `em` based sizing in favor of `px` based.

Volker_E removed a project: Patch-For-Review.

Restricted Application added a project: User-Ryasmeen. · View Herald TranscriptFeb 11 2020, 3:41 AM

Michael subscribed.Feb 11 2020, 2:16 PM

Volker_E updated the task description. (Show Details)Jul 21 2020, 3:53 AM

Ladsgroup edited projects, added User-notice-archive; removed User-notice.Aug 13 2022, 1:53 PM

	F29739855: T220671 em to px - Make your donation now - Wikimedia Foundation 2019-07-11 09-40-21.png
	Jul 11 2019, 4:43 PM

	F29841706: image.png
	Jul 22 2019, 4:49 PM

	F29841685: image.png
	Jul 22 2019, 4:49 PM

	F29841670: image.png
	Jul 22 2019, 4:49 PM

	F29841702: image.png
	Jul 22 2019, 4:49 PM

Replace `em` based sizing in favor of `px` based where applicableClosed, ResolvedPublicActions

Description

Problem statement

Proposal

Wins through pixels (for box-sizing properties max-width, max-height, margin, padding, border, …)

Losses through pixels

Comparison with other big web entities

Dev notes

Further resources

Details

Related Objects

Event Timeline

Bigger buttons

Bigger icons

Replace `em` based sizing in favor of `px` based where applicable
Closed, ResolvedPublic
Actions