canonical
<small> can be larger than surrounding text
Vanilla sets the font size of <small> in rem, that is, relative to the font size of the <html> element:
@media screen
… .p-heading-icon__title, small, .p-text--small, … {
font-size: .875rem;
…
}
Unfortunately, this means that if the surrounding text is already smaller than 0.875rem, <small> ends up bigger than the text around it.
For example, on a CVE page, links to “Launchpad, Ubuntu, Debian” use <small> because they’re less important than than the package name above — but Vanilla styles them bigger than the package name.
~~Vanilla does not try to size the <big> element at all, so it’s also internally inconsistent.~~
What should happen: <small> should always be smaller than the surrounding text.
Well spotted, thanks @matthewpaulthomas.
<Big> is not part of the html5 spec AFAIK, but I think we should make small and x-small use font-sizes that are relative (ems), but also make sure they are on the modular scale.
I should point out that "accountservice" in the screenshot above uses a font-size not used anywhere else in vanilla (.8rem) so maybe that should be fixed on the CVE site?
Oh, I was showing my age there: I remembered <big> from HTML 3.2 and 4.0, and forgot it had been dropped since.
“accountsservice” is 0.8rem because the rest of the “Status” table is, because CVE listings tables are, because that was one thing we did (after discussion with you) to reduce text wrapping in the listing table cells. There are a couple of things we could fix here:
-
We can change the 0.8rem to 0.875rem to fit in the Vanilla scale (I’ve just proposed this as ubuntu.com#8777). That wouldn’t really fix this problem, though —
<small>would no longer be bigger than surrounding text, but it still wouldn’t be any smaller. -
The weakest link in that chain is “…because CVE listings tables are…” — the two tables have quite different data, so the status table could just use the normal font size (now reported as ubuntu.com#8778). That would avoid the problem on the CVE page, but it would still be lurking in Vanilla. I’ve previously encountered it in ubuntu.com#8091, so I’m sure people will be tripped up by it again.
Anything smaller can use
p-text--x-small.
So if your use case is “I want this text to be smaller than the surrounding text, and I don’t need to align with other blocks”, the solution is:
- calculate the size of the surrounding text
- if it’s bigger than 0.875rem, use
<small> - if it’s between 0.76562rem and 0.875rem, use
class="p-text--x-small"if you don’t mind the extra line spacing, or if you do, roll your own style - if it’s 0.76562rem or smaller, roll your own style.
My view on this doesn’t matter any more, 😉 but that seems a bit complex. In comparison, if this bug was fixed the answer would be “1. use <small>”, and you wouldn’t need to know anything about Vanilla to achieve it.
Your opinion always matters @matthewpaulthomas :)
@bartaz can't we just set the sizing in ems, and add x-small while we-re at it?
<small> 0.875em - from the type scale equal to (14/16)
<x-small> 0.765625em from the type scale equal to (14/16) * (14/16)
@bartaz can't we just set the sizing in ems, and add x-small while we-re at it?
We can set it in ems, and I agree it would make things simpler, but I believe it was you @lyubomir-popov who opted for fine control over font size and spacing to make sure everything lines up correctly with the baseline grid.
Once we set <small> to use ems, will we even need the p-text--x-small at all?
It may be the first place where we use ems for relative sizing of the fonts, we will need to review what consequences it has on related patterns and utils.
@bartaz Those font-sizes are on the scale so I see no problem with ems. It will take whatever the parent element's size is and move it down the scale by one (small) or two (x-small) notches. Even if you nest small inside x-small infinitely...
The reason we have the classes is so we can apply them on block-level elements, so I think those are still very usefull.