Adjust trigger padding

[jimjam-slam]

Makes a small adjustment to padding for narrative blocks so that the padding is more reliable and gives the text more room to breathe by default

[jimjam-slam]

What do you think, @andrewpbray?

Before:

After:

[andrewpbray]

TODO meaning consider revisiting if you want to tweak?

[jimjam-slam]

Note to self: don't get distracted halfway through writing a TODO 😂

I think I originally modified this property, realised this was inside the mobile layout, intended to decide whether this property was needed at all and then got distracted 😬 I think 0.75rem is a good bit of padding for all layouts though tbh, so I'm tempted to remove this altogether!

[jimjam-slam]

With padding: 5px on mobile:

With 0.75em (what I've set other layouts to):

0.3rem (vertical) and 0.5rem (horizontal) is a snugger but maybe balance that I think might better work for very small screens:

You could take a bit off the vertical for wider widths too! Maybe 0.7 0.75em?

[andrewpbray]

While we're looking at that index closeread...

I used a very similar approach to line highlighting as the one used by revealjs. Essentially all non-highlighted lines in a block of lines with highlighting get hit with a .cr-hl-within class that changes opacity.

.cr-section .sticky-col .sticky-col-stack .cr-active.cr-hl-within .sourceCode span[id^=cb] {
  opacity: 0.3;
  transition: opacity linear 0.3s;
}

In a setting like this, where the whole cr-section div has a blue background color, some of that bleeds through since its opaque. Do you know of an easy way to fix this? Essentially I want a white mask on the code block, not really an opacity, or an opacity that sees past the blue background to the white beneath it...

[jimjam-slam]

While we're looking at that index closeread...

I used a very similar approach to line highlighting as the one used by revealjs. Essentially all non-highlighted lines in a block of lines with highlighting get hit with a .cr-hl-within class that changes opacity.

.cr-section .sticky-col .sticky-col-stack .cr-active.cr-hl-within .sourceCode span[id^=cb] {
  opacity: 0.3;
  transition: opacity linear 0.3s;
}

In a setting like this, where the whole cr-section div has a blue background color, some of that bleeds through since its opaque. Do you know of an easy way to fix this? Essentially I want a white mask on the code block, not really an opacity, or an opacity that sees past the blue background to the white beneath it...

I think the blue is bleeding through because the .sourceCode background for the code block has a background-color with 65% opacity. When you set it to full opacity, the problem disappears:

Does that come from us, or from Quarto? That comes from Quarto (see the code blocks on this documentation page). We might just need to override it for this page...

[andrewpbray]

Oh that's very interesting! Yes, a good thing to override manually for now but I wouldn't be surprised if other users run into this. If we see it crop up again, we can consider a more systematic fix.

Fundamentally, Quarto html styling probably (and sensibly) wasn't designed imagining that these elements were going to be put into a stack.

[andrewpbray]

Hmm, I wonder if I'm missing something. When I go to pull, (and after i render to css), I get this look:

That looks a little tighter on the left than yours, no?

(this will be a big perk to the having the preview site!)

[andrewpbray]

Hmm, I'm noticing some strange behavior on a narrow screen on the index at closeread.dev:

mobile-index-sm.mov

This was on Chrome on my laptop but this is the same thing I see on my (tiny) phone running Safari. When I check the ones in the Gallery, they don't seem to have this issue.

How does it work on your end? Maybe this is just an issue with .overlay-center... except on mobile don't we just switch to .overlay-center? so that wouldn't explain why the Gallery ones don't have this behavior on mobile.

[jimjam-slam]

There are two things happening here, I think:

1. Overflow (horizontal scroll bar) starts happening because the code block sticky has a minimum width, then
2. The narrowest screen is just hitting the 575px width boundary for mobile sizing (which is overlay-center).

[jimjam-slam]

I've pushed some changes to improve overlay narrative positioning: instead of trying to use percentage margins, which are fiddly, it relies on justify-self to align the narrative column within the grid cell.

We could potentially still set a margin-left or margin-right to push the respective left and right overlay narrative content out from the edge. Or that could be a user YAML option 🙂

I've also set a max-width on the narrative content that is designed to line up seamlessly with the mobile breakpoint. That could also be a YAML option potentially!

To see the effect of it without the overflow getting in the way, add font-size: 70% to the div.code-with-filenameinside#cr-doc`:

To fix the code overflow on this page, I've:

• added .scale-to-fill to the code block, allowing it to rescale as needed using transform: scale(), and
• moved the font-size: 1.4em from the entire .cr-section to just the .narrative-col; .sticky-col is set to font-size: 0.6em.
  • Blocks that have .scale-to-fill still have layout space reserved for their "natural" width and height; the overflow happens when the window shrinks beyond those natural dimensions (even if .scale-to-fill has shrunk it visually). So generally we want to make those "natural" dimensions as small as possible by setting a low font size and having transform blow it back up. The trade-off we've observed is that Safari sometimes doesn't re-rasterise the text properly, making it blurry — but that doesn't seem to be happening in this case!
  • We should probably make sticky-natural-font-size a YAML option, since overflow issues will likely come up for users. We could also set a moderately default and try to get the best trade-off in terms of mobile support versus potentially pixelisation, but the natural width also depends on line length, so there's no one answer. For this code block, 0.6em is small enough to prevent overflow on widths down to 350px, which I think is pretty conservative in terms of device support.

[jimjam-slam]

You can briefly catch the re-rasterisation in Safari when changing highlights (not worried about it here since it's kicking in at the end of the transition, but you can at least see the un-re-rasterised state):

Screen.Recording.2024-10-20.at.21.16.15.mov

[andrewpbray]

Did you add these changes to #107 instead of this branch? I still get the overflow issue when I try it locally on this branch.

[jimjam-slam]

Did you add these changes to #107 instead of this branch? I still get the overflow issue when I try it locally on this branch.

Oh jeez, I did 🤦🏻‍♂️ Lemme cherry pick them over to here!

[jimjam-slam]

Should be good to test now, @andrewpbray!

(I tried to fix the conflict with the .css.map file when merging, but it looks like it's still in conflict with dev. I'd be tempted to accept one or the other and then just run sass again after the merge)

[andrewpbray]

Looks good!