Enforce theme font sizes

[fbarl]

Although our weave.js theme includes some font sizes, they are not used that much across our code - I assume the two main reasons are:

a. There are only 3 sizes to choose from which still doesn't cover a lot of cases
b. Their usage is not enforced (or at least hinted by a warning)

fontSizes: {
  normal: '0.875em',
  large: '2em',
  xl: '2.827em',
}

I suggest the following:

1. Aggregate all the font sizes used across our app into theme.fontSizes
2. Force style linters to accept only variables passed to font-size property (like it's done for z-index)
3. Use only theme font sizes everywhere
4. (not part of this issue) Start dropping some obsolete/ugly font sizes gradually while slowly converging to our unified design system, like we are currently doing with colors

cc @bia @miklosp @jpellizzari

[fbarl]

Some usage distribution across our UI code (not taking into account relative % units and sizes implicitly used by Text component; also assuming em === rem which seems to be the case with most of our code):

 3 - 10px
 3 - 11px
11 - 0.7em
 1 - 11.7px
12 - 12px
15 - 0.8em
17 - 13px
 3 - 0.85em
53 - 14px/0.875em
12 - 0.9em
 3 - 15px
35 - 16px/1em
11 - 18px
 2 - 1.2em
 9 - 20px/1.25em
 1 - 1.3em
 2 - 21px
 3 - 22px
20 - 24px/1.5em
 1 - 28px/1.75em
 1 - 30px
 6 - 32px/2em 
 1 - 34px
 3 - 36px/2.25em
 1 - 3em
 1 - 4em
 1 - 200px 
 1 - 320px

I will try to merge the units that are really close to one another and try to get rid of big single-use-case ones context permitting. Ideally that should put it down to not more than 10-15 different sizes and the design team can pick it up after that (step 4 above) :)

[fbarl]

I think grouping them like this could work:

tiny - 11px

 3 - 10px
 3 - 11px
11 - 0.7em

small - 12.5px

 1 - 11.7px
12 - 12px
15 - 0.8em
17 - 13px

normal : 14px

 3 - 0.85em
53 - 14px/0.875em
12 - 0.9em
 3 - 15px

large : 16px

35 - 16px/1em

huge : 19px

11 - 18px
 2 - 1.2em
 9 - 20px/1.25em
 1 - 1.3em
 2 - 21px

enormous : 24px

 3 - 22px
20 - 24px/1.5em
 1 - 28px/1.75em
 1 - 30px

gigantic : 34px

 6 - 32px/2em 
 1 - 34px
 3 - 36px/2.25em

???

 1 - 3em
 1 - 4em
 1 - 200px 
 1 - 320px

I went a bit crazy with the naming there - I think I could use a native speaker's help (@jpellizzari, @bia) for fine-grading between different words for big. Could always go with l, xl, xxl, etc... but I thought more colorful/memorable variable names are always a good idea :)

[jpellizzari]

I think we should go with a scale like this to cut down on the available options: 10, 12, 14, 18, 24, 36. I think that gives us enough variation to get a nice hierarchy if we need it, without allowing for too much customization. The actual values aren't as important as limiting it to 6 or less.

Names (respectively): tiny, small, normal, large, extra-large, heading. I was thinking this would communicate some intent.

Ii also propose we build this into the <Text /> component to make it very simple to follow the font-sizes.

[bia]

The type scale that we discussed on the Design Trello might still be a useful reference.

[rndstr]

We should also use either rem or px IMHO. em is too much of a headache if people inadvertently nest font-sizes.

[miklosp]

That's what I would like to work with. 16px is our base size.

[miklosp]

@fbarl the grouping I would recommend is:
tiny, small > tiny
normal > small
large > normal
huge, enormous > large
gigantic > extra large
huge is used very sparingly (big numbers on instance homepage and dashboards)

[fbarl]

@jpellizzari @bia @miklosp @miklosp Thanks for all the feedback! I think I managed to consolidate most of your comments:

• Taking the unit to be px
• Taking the normal font size to be 16px
• After playing with the type scale @bia linked, we decided to drop it for now
• I took @jpellizzari's naming suggestions at first but then I felt heading is a semantic name, which doesn't really apply to our use cases that well
• I stayed a bit on the conservative side and didn't wanna merge 20px and 24px so I kept 7 font sizes in the end:

[miklosp]

I say 20 and 24 are too close together to be meaningful. Be brave and merge them. 😉

[fbarl]

I say 20 and 24 are too close together to be meaningful. Be brave and merge them.

Alright, I'll be brave.

[bowenli]

@miklosp @bia We should be using a progression instead of picking and choosing. The 16->22 jump is too large. Sometimes you need a localized header. The Elements of Typographic Style is the de facto standard. 6 7 8 9 10 11 12 14 16 18 21 24 36 48 60 72

[jpellizzari]

6 7 8 9 10 11 12 14 16 18 21 24 36 48 60 72

Too many choices. That is basically a continuous list of integers. I am cool with adding one more level between 16 and 22, but we need to constrain the choices for consistency.

[miklosp]

Let's keep the current 6 variants. @bowenli can you please supply an example where you need something between 16 and 22?

[bowenli]

[bowenli]

Regardless, we should still be using a ratio scaling factor. http://spencermortensen.com/articles/typographic-scale/

[bia]

@bowenli I'm curious to know if some of the sizing examples that you pointed out could be resolved by using the same font size as the subtext, but semi-bold.