do not cut off bottom portion of text

[dajrivera]

Summary

The bottom portion of texts get cut off on Edge, Chrome, & Firefox; this issue does not appear in Safari. Using CSS property line-height: normal seems to fix the issue and does not affect Safari's rendering of the page.

before:

after:

Related issue, if any:

N/A

What kind of change does this PR introduce?

Other: minor UI fix

For any code change,

• Related documentation has been updated, if needed
• Related tests have been added or updated, if needed

Does this PR introduce a breaking change?

No

Tested in the following browsers:

• Chrome
• Firefox
• Safari
• Edge

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
docsify-preview	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jul 18, 2025 7:02pm

[sy-records]

Thanks for your contribution.

But I think this is by design, and you can modify it through the theme properties.

      :root {
        --heading-line-height: normal;
      }

[paulhibbitts]

I'd tend to include this fix, as by default I would expect line-height to be automatic by default in all Browsers and not require additional changes.

[dajrivera]

@sy-records ah, thanks; I did not check for an existing variable. I set the global variable and it did indeed fix the problem but as @paulhibbitts commented, I would expect the text to look correct by default in all browsers. I've moved the change to be the default --heading-line-height variable value so it can still be overridden by themes.

[paulhibbitts]

Thanks @dajrivera , now that I think about it I may also have run across this issue earlier when trying different fonts out with v5 and noticing I needed to then further adjust line-height to avoid slight cut-off one some particular ones.

[paulhibbitts]

LGTM

[sy-records]

I think there might be a problem.

[dajrivera]

@sy-records looks like the h2 bottom-margin is calculated and was the reason for the prior "Unit required" comment; using value normal here broke that calculation. I've updated the bottom-margin calculation using the line height unit instead. At this point the bottom margin was too large so I included a local line-height-multiplier to reduce the margin size as a workaround. Let me know if you can think of a better alternative or a more appropriate method to implement this.

Looks good to me in Edge. I can test Chrome, Firefox, and Safari tomorrow.

[paulhibbitts]

Good catch @sy-records , my apologies for not viewing additional pages in the PR preview... I will be more careful in the future.

From my perspective I hope that the resulting spacing unit adjustments match the spacing as originally specified by John Hildenbiddle as much as possible.