Fix-fontsizescaling

[jimjam-slam]

At the risk of exploding our branches and PRs again, I've split the work fiddling with scaling further out from the work actually working on the grid.

This PR switches to a system where all scaling is done with CSS container width/height units, not transform calculated by JS.

The big upside of this is that there are no Safari rasterisation issues, and that it generally holds together well regardless of screen size (although if you're resizing the window a lot, Scrollama gets lost and you may need a page refresh).

The big downside is that CSS transitions on font size aren't super smooth: they step up in full points, so you can get some staggering. But I think the trade-off might be worth it if it keeps our complexity down elsewhere — managing scaling for so many content types is making Safari a real weight. What do you think, @andrewpbray?

I've set the sizing to:

.cr-poem {
  font-size: min(2.75cqw, 2.75cqh);

  &.cr-hl-within {
    font-size: 2.75cqw;
  }
}

This scalar, 2.75, could probably be adjusted based on the shape of the poem — I think generally you'll want a scale proportional to the minimum of either the line length or the number of lines.

We could try to compute that with JS and set the CSS styling.

We could also provide an attribute to the user for poems, like cr-size="5", and use that to write the styling in Lua.

[andrewpbray]

@jimjam-slam What are your thoughts on https://github.com/qmd-lab/closeread/pull/36/commits/4ff39cae7101fc65b6e49c8cb67c3a6eabe4e4b0? Does this remove the need for a shrinkToFit function in JS?

Separate question that came to mind while fiddling with css: do you recall why .sticky-col-stack has display: grid?

[jimjam-slam]

4ff39ca could help with the occasional layout spill, although I still think we can mostly tackle it through container units and setting width appropriately on images! But when a spill does happen, we want it to just be visual (the content extends beyond the edge of the window visually) and not layout-wise: if the layout gets forced to be wider, that's when we start seeing scroll bars.

sticky-col-stack has display: grid to facilitate the Z-stacking. It happens the same way Reveal does it: it's (another) nested grid layout where everything is put into the same row and column track (hence the grid-area: 1 / 1 and margin: auto on .sticky-col-stack [data-cr-id]) 😊

[jimjam-slam]

Is shrinkToFit designed to just handle getting the element as a whole into the window? If that's the case, it can probably go with this branch! We will probably CSS transform functionality for. the line highlights... although I'm hoping we can still use container units for the scaling part of that (focusing just on the width instead of both width and height) and just use CSS transform for the translation (centering the highlighted part).

[jimjam-slam]

I'm going to merge this branch into feature-poemzoom-columngrid so that I can tie that PR up (since it was supposed to be about the grid layout choices), but I'll leave a note about whether shrinkToFit is required now!