`font-size` consistency across context and toolkits

sturobson commented 3 years ago

In preparation for a reworking of springer.com from the SPA team I have been investigating, and reviewing the Sass that is used in the front-end toolkits. This works was also part of looking into creating and integrating Design Tokens into the front-end toolkits that will help the wider Elements Design System(s) and front-end teams. Whilst going through the existing codebase I’ve found a few things that I think we could do with refining, updating, and/or standardising.

The base font size is written several times

To begin with there are different font sizes on the html or body tag depending on what Sass partial you are looking at. Often it starts at 13px and then gets overridden by 62.5%.

We could look to reduce the amount of times this has been added to a compiled CSS file.

Changing the base font-size.

Using font-size: 62.5% is a technique that makes it easier for the developer to write their font-size values in ems or rems where 1rem is relative to 10px rather than 16px. With utilising Sass variables and Design Tokens - the need for a developer to work out the rem value of 18px when the <html> font size is set as 100% should be nullified.

We can also make the default font size 100% and, using Sass, we can use the !default flag so that brands can override this if they wish to. This will also mean updating where font-size is used where 2.4rem was used for 24px where, with a base font size of 100% the rem value would be 1.5rem (here’s a handy list of px to rem values when the font size on the html is 100%.). So there will be some updating required across the front-end toolkit to make these changes (again, using the !default flag could help us here.

`rem`s with a `px` fallback

As part of the SPA team I have mostly found this in the (no longer to be maintained) springer-compass repo where (mostly) a Sass function is used to create a pair of font-size rulesets. One with the px value followed by the same rule with a rem value. This is used when you need to support IE8. There are also cases where this has been hardcoded into some of the front-end toolkits.

We can remove the px fallback. As the current browser support list shows we don’t support it and, because CSS fails softly, if a user does visit with IE8 they will get the default UA font sizing so there will still be visual hierarchy.

tulipdexter commented 3 years ago

Nice one @sturobson!

The base font size is written several times

I'm not sure why we'd ever set it to 13px to be honest, even in a 'core' (non enhanced) browser 🤔 .

If I understand correctly, you're saying that in the 'core' experience, we could set font-size: 100% and then not use the whole 62.5% thing in the 'enhanced' experience, resulting in less overriding of that style?

I'm personally not adverse to the idea, I don't have a particularly strong opinion either way. My only concern is the extent of refactoring required to do this, and does it bring a particular benefit that I'm overlooking? Do you have an idea of how the variables would look? Presumably not t-shirt sizes so font-size-14, font-size-16 etc?

Side note The 62.5% thing is a little old fashioned, although we do follow it by setting 1.6em on the body so it's not quite as 1999 as it could have been and we're not leaving users with a potential 10px text to try to read.

rems with a px fallback

Agree, absolutely no need to do this. TBH I thought the font-size mixin was long dead.

As an aside, we do seem to have some inconsistent unit usage too:

https://github.com/springernature/frontend-toolkits/blob/master/context/brand-context/default/scss/10-settings/typography.scss#L20

sturobson commented 3 years ago

If I understand correctly, you're saying that in the 'core' experience, we could set font-size: 100% and then not use the whole 62.5% thing in the 'enhanced' experience, resulting in less overriding of that style?

Yes, in the first step I think it would be wise to do this using Sass so that it can be overridden by teams that cannot make changes straight away (which will be more of a problem if they're product Sass/CSS doesn't reflect what's in the Toolkits 1:1. Something like:

frontend-toolkits/context/brand-context/default/scss/10-settings/typography.scss

...
$base-font-size: 100% !default;
...

frontend-toolkits/context/brand-context/springer/scss/40-base/basic.scss

html {
  font-size: $base-font-size:;
}

Which a brands could then override to 62.5% if needed by overriding the $base-font-size in their own Sass 10-settings folder.

My only concern is the extent of refactoring required to do this, and does it bring a particular benefit that I'm overlooking?

I'm seeing the above as an interim step, so we don't need to change any existing font-size declarations for components just one or two lines of Sass added/deleted in each context.

This leads to the open space ticket about creating, and integrating Design Tokens where the developer that would be making use of the front-end toolkit would not have to worry if 1.5rem equals 15px or 24px as, for maintainability and consistency, variables would be used.

Do you have an idea of how the variables would look? Presumably not t-shirt sizes so font-size-14, font-size-16 etc?

As mentioned in the Design Tokens open space ticket - I too find t-shirt sizing sets you up to fail with it's naming convention. I've previously found a numeric system where (at the start) 400 would be the same as 1em or 1px. Abstracted enough that we're not thinking in pixels but scaleable enough that we can add new sizes if needed.

We might look to potentially adding a level of abstraction to what currently exists. Something other organisations have done (file names for example purposes only):

// context/springer/variables.scss
$font-size-800: 2rem;

which goes into

// context/springer/typography.scss
$context--font-size-h2: $font-size-800;

which goes into

// toolkits/springer/header/variables.scss
$c-heading__header-title: $context--font-size-h2;

rems with a px fallback Agree, absolutely no need to do this.

This was mainly in the springer-compass repo, but I have noticed some hardcoded rem with px fallback font sizing in the front-end toolkits repo

we do seem to have some inconsistent unit usage too:

A benefit of doing some work on standardising this and introducing tokens means we could be better at making sure the units used are consistent too. Not only for font sizing, but spacing and colours for example too.

sturobson commented 2 years ago

With #625 and #631 now merged, I think this can be closed. Hence…

springernature / frontend-toolkits