Metrica Typus -- Capsizing + Trim + REMsizing in CSS only ... for Tailwind

[andriytyurnikov]

Meet beta version of Metrica Typus - size your capital letters in REMs, including fractional values, trim, TailwindCSS ecosystem. Injection of CSS custom properties (generated from font metrics) and calc() is used to keep solution in CSS space.

If interested - check it out - feedback is needed.

[michaeltaranto]

Hey @andriytyurnikov thanks for sharing. Be interested to see where the solutions differ. The issue with relative font size from memory has been that the trims depend on knowing the font size and line height.

We did prototype moving the implementation into css vars but the calcs were quite heavy. Definitely interested to compare notes here.

[andriytyurnikov]

@michaeltaranto sure thing - nothing new, just reshuffling computations:
Solution is pretty much direct port of Capsize, with few notable implementation details:

Most questionable part is that I am using shortest branch of your formula, by having lineGap = 0;
I've asked separate question in Q&A section, and I really could use some guidance about why it may be needed.

1. Unitless computations up to the last step. Units are only applied on final step.

2. You are absolutely right - in order to perform trimming line-height should also be set in same units, and "injected" into css variables.

3. CSS calculations are heavy indeed - brute force CSS solution does not work in Chrome due to exhausting ability of calc. (But Safari can handle even brute force CSS calculations )
   3.1) Browsers getting better
   3.2) Partial workaround was to reduce CSS calculations, by performing some computations in JS, and injecting results into CSS variables, and then finalising computations in CSS.
   Namely:

  _contentArea(metrics)/metrics.unitsPerEm // may be memoized
 metrics.capHeight/metrics.unitsPerEm // may be memoized
 _absoluteDescentScale(metrics) + (_lineGapScale(metrics) / 2) // part of baseline trim that can be memoized
_ascentScale(metrics) -_capHeightScale(metrics) + (_lineGapScale(metrics) / 2 ) // part of cap-height trim that can be memoized

With this parts being memoized at build-time, we are left with 6-7 arithmetic operations for each part of the trim. 12 arithmetic opertions total for both sides of the trim.

3.3) Tailwind plugin architecture allows exactly that - constructing CSS classes (postcss) on the fly from their names - performing computations, and generating CSS with valiables in it.

So yes - browser is pushed close to it's limits. And only part of computations are performed at build time.

What helps to visualize this approach is writing down required computation results into single formula - in this way it is easier to see which parts of the formula may be memoized at build time.

Once again - I really could use expanded comment on role of lineGap, as so far seems unnecessary