Design better typographic scale for the portal
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	• JGirault
	Mar 16 2017, 9:50 PM

Description

As revealed by {T160474#3108335}, the Wikipedia.org page contains a very diverse list of font sizes:

(1rem = 16px)

font-size: 0;
font-size: 0.6rem; (9.6px)
font-size: 0.65rem; (10.4px)
font-size: 0.684rem; (10.944px)
font-size: 0.69rem; (11.04px)
font-size: 0.7rem; (11.2px)
font-size: 0.72rem; (11.52px)
font-size: 0.75rem; (12px)
font-size: 0.76rem; (12.16px)
font-size: 0.8rem; (12.8px)
font-size: 0.8125rem; (13px)
font-size: 0.875rem; (14x)
font-size: 0.975rem; (15.6px)
font-size: 1rem; (16px)
font-size: 1.875rem; (30px)
font-size: 2rem; (32px)

font-size: 70%;
font-size: 75%;
font-size: 85%;
font-size: 110%;
font-size: 125%;

font-size: inherit;
font-size: larger;

Note
The task sounds like it will bring major, disruptive changes to the users. Aside the most detail-oriented section of our users, it should not.
It will slightly change the overall look of the portal, but it should be minor, and for the better: we are not changing the page layout, just making the font sizes more consistent, for better readability. No text looking big is gonna look small, and no text looking small is gonna look big after these changes.

Suggested process

Merge cleaning patch T160474: Convert inconsistent font sizes, margins, paddings units... to rem unit to rely only on rem typographic unit.
Define the rem base. rem is a unit relative to the font size of the root element (<html>).
Define a typographic scale in collaboration with Design / Wikimedia-Design / Wikimedia Design Style Guide that would work for the portal and other wikimedia projects. See https://design.wikimedia.org/style-guide/visual-style_typography.html#use-of-styles
Virtually apply changes to the portal and share visual changes with the community.
Deploy updated version of portal to production.

Outcome (desktop)

font-size definitions

3.2rem at h1
3rem at .central-textlogo
1.6rem for headlines
1.5rem for Wikipedia tagline (slogan) – exception that would need to increase logo size itself
1.4rem for toned-down important elements like language numbers
1.3rem for small and other smallest elements like license texts
75% for sup, sub resulting in as low as 10.5px. But those aren't used on Portals right now.

Details

	Subject	Repo	Branch	Lines +/-
	Follow Design Style Guide typographic scale limits and fix several glitches	wikimedia/portals	master	+23 -24

Customize query in gerrit

Related Objects

Mentioned In: T255724: Standardize typographic scale for the portal
T254653: Change the header of apps presentation block on Wikipedia portal
T207104: Reconsider `em` values in CSS with current state browsers
T160474: Convert inconsistent font sizes, margins, paddings units... to rem unit
Mentioned Here: M101: WikimediaUI
T160474: Convert inconsistent font sizes, margins, paddings units... to rem unit

Event Timeline

• JGirault created this task.Mar 16 2017, 9:50 PM

Restricted Application added a project: Discovery-ARCHIVED. · View Herald TranscriptMar 16 2017, 9:50 PM

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

• JGirault mentioned this in T160474: Convert inconsistent font sizes, margins, paddings units... to rem unit.Mar 16 2017, 9:55 PM

• JGirault added a project: Design.Mar 16 2017, 10:18 PM

• JGirault updated the task description. (Show Details)

Define the rem base. rem is a unit relative to the font size of the root element (<html>).

@Volker_E suggested to use 1rem = 10px. This gives a base-10 instead of a base 16 and is much easier and faster for developers to work with.
For example, margin-bottom: 14px; can be effortlessly converted to margin-bottom: 1.4rem;. A base-16 wastes developer time in calculation: margin-bottom: 0.875rem;,

Volker_E awarded a token.Mar 16 2017, 11:24 PM

Why focus on pixel output values when using rems? Personally, when using ems & rems I tend to set measurements like 0.75rem, 0.25rem etc, because those are much easier to calculate relative to 1rem.

Typographic scales, like musical scale, are based on ratios between numbers, not absolute values, so if something like 0.75rem ends up being 12.66666px, that doesn't bother me, as long as the ratio between the values is correct. With this perspective, I prefer 1rem set to the body text size (typically 16px), and calculating the other rem values based on a ratio to that size (pixels be damned!)

This is my go-to page for trying different typographic scales: http://www.modularscale.com/?16&px&1.25&web&text I like the 1:1.125 ratio myself, but I think it would be cool to set up a system of CSS variables that will lets us try different type scales.

Just to reiterate my thoughts on the 1rem=10px idea.

The benefit of this would be to easily translate rems into pixels, but then how is this different than setting 1rem=1px and then using values like font-size=16rem? To me the only difference is the decimal. The point I'm trying to make is that if we're converting rems to pixels, than that's no different than just using pixels.

In M101 for example, measurements are set as 2em, 1.5em, 0.5em etc. These units are meant to maintain proportion regardless of the elements font-size. I think rems should be treated the same way, in that they should represent a proportion of the root font size, regardless of what pixel value it's set to ( and as the topic of this task suggests, they should represent a proportion of the root font size based on a scale).

In T160704#3133504, @Jdrewniak wrote:

Just to reiterate my thoughts on the 1rem=10px idea.

The benefit of this would be to easily translate rems into pixels, but then how is this different than setting 1rem=1px and then using values like font-size=16rem? To me the only difference is the decimal.

True that 😄

The point I'm trying to make is that if we're converting rems to pixels, than that's no different than just using pixels.

They're not the same, as rems are relative to the root element font size.
In terms of accessibility, this is really powerful. It allows the spaces between blocks, text elements..., to be relative to that browser font size. Take two text elements, separated by 16px. The 16px value should not be a hardcoded value. What happens when one increases the browser's top font size, to a larger size? The text gets bigger but the space separating the two text elements remains 16px, breaking readability. In a perfect rem world, the text elements and the space (margin, padding, positioning) between elements are all relative to the root element font size, thus the webpage can adapt correctly to any font size.

In fact, most of the time the trick is to use both rems and pixels, to allow both fixed content and adaptive content (related to reader's preferred font size).

In M101 for example, measurements are set as 2em, 1.5em, 0.5em etc. These units are meant to maintain proportion regardless of the elements font-size. I think rems should be treated the same way, in that they should represent a proportion of the root font size, regardless of what pixel value it's set to ( and as the topic of this task suggests, they should represent a proportion of the root font size based on a scale).

Yes, it is true that it's more intuitive to have some sort of scale:

padding: 0.5rem;
padding: 1rem;
padding: 1.5rem;

Rather than less-rounded values that feel a bit more arbitrary:

padding: 0.8rem;
padding: 1.6rem;
padding: 2.4rem;

Moving to the backlog, we won't be able to take on this work any time soon.

Jdrewniak moved this task from Untriaged to Design on the Wikimedia-Portals board.May 8 2018, 8:48 AM

Jdrewniak mentioned this in T207104: Reconsider `em` values in CSS with current state browsers.Oct 16 2018, 12:53 PM

Iniquity subscribed.May 11 2020, 10:23 PM

Volker_E updated the task description. (Show Details)Jun 5 2020, 10:10 PM

The typographic scale is in the meantime set at https://design.wikimedia.org/style-guide/visual-style_typography.html#use-of-styles.
We basically feature for 16 sp base interfaces two smaller font sizes: 14 sp and 13 sp.

The task description state of the code has been changed for the better, there are only a few different sizes left.

Yes, I also want to write that we need to set, at least, the minimum font-size to 13 pixels.

Change 602782 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[wikimedia/portals@master] Follow Design Style Guide typographic scale limits and fix several glitches

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

gerritbot added a project: Patch-For-Review.Jun 6 2020, 12:12 AM

Volker_E added a project: UI-Standardization.Jun 6 2020, 12:15 AM

The tagline remains at 15px, which is not a value represented in the DSG scale currently, the logo would need to be made bigger slightly and the tagline upped to 16px, but that's out of scope for this patch.

@Volker_E: Special thanks for adding bottom margin to body ;)

Current	Proposal

I'm not quite sure, but here's what happens when the font changes.
I used:

16px for description and mobile block
Heading 3 (20px) style for mobile header
16px for project name in project block
13px for tagline
Heading 3 (20px) style for names of top10
13px for articles amount
Button 16px

Iniquity mentioned this in T254653: Change the header of apps presentation block on Wikipedia portal.Jun 8 2020, 1:04 PM

@Iniquity Thanks for the proposal, this is unrealistic to be covered/addressed here though. We wanted to reduce the different font sizes in code here and merge them into a quickly understandable number of different treatments.
If you like so, please file another task with your proposal, clearly outlining what issues you try to resolve with it.

@Volker_E Ok, I'll do it later, thanks :)

Volker_E closed this task as Resolved.Jun 8 2020, 4:42 PM

Volker_E claimed this task.

Volker_E removed a project: Patch-For-Review.

Volker_E updated the task description. (Show Details)

Change 602782 merged by jenkins-bot:
[wikimedia/portals@master] Follow Design Style Guide typographic scale limits and fix several glitches