Closed sturobson closed 2 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:
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.
With #625 and #631 now merged, I think this can be closed. Hence…
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
orbody
tag depending on what Sass partial you are looking at. Often it starts at13px
and then gets overridden by62.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 theirfont-size
values inem
s orrem
s where1rem
is relative to10px
rather than16px
. With utilising Sass variables and Design Tokens - the need for a developer to work out therem
value of18px
when the<html>
font size is set as100%
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 wherefont-size
is used where2.4rem
was used for24px
where, with a base font size of100%
therem
value would be1.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 apx
fallbackAs 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 offont-size
rulesets. One with thepx
value followed by the same rule with arem
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.