Fix overflowing text content in footer link

[prajwalkulkarni]

💫 Changelog

⭐ Fixes issue: #6460
⭐ Added text-overflow: ellipsis to show ellipsis on lengthy strings, with the addition of title attribute on the span element that shows the complete string on a tooltip on hovering the truncated string.
⭐ block property is now removed from the span element as spans are inherently inline and I feel making them behave as a block level element is semantically wrong. Instead, now we render the elements in a column-oriented flex container.
⭐ The parent container of the link string and the "Next/Previous" string is now housed by a div instead of a span

Existing UI

Updated UI

[github-actions]

Size changes

📦 Next.js Bundle Analysis for react-dev

This analysis was generated by the Next.js Bundle Analysis action. 🤖

Three Pages Changed Size

The following pages changed size from the code in this PR compared to its base branch:

Page	Size (compressed)	First Load
/404	77.39 KB (-4 B)	181.28 KB
/500	77.38 KB (-4 B)	181.27 KB
/[[...markdownPath]]	78.98 KB (-4 B)	182.87 KB

Details

Only the gzipped size is provided here based on an expert tip.

First Load is the size of the global bundle plus the bundle for the individual page. If a user were to show up to your website and land on a given page, the first load size represents the amount of javascript that user would need to download. If next/link is used, subsequent page loads would only need to download that page's bundle (the number in the "Size" column), since the global bundle has already been downloaded.

Any third party scripts you have added directly to your app using the <script> tag are not accounted for in this analysis

Next to the size is how much the size has increased or decreased compared with the base branch of this PR. If this percentage has increased by 10% or more, there will be a red status indicator applied, indicating that special attention should be given to this.

[prajwalkulkarni]

@Huxpro could you kindly review this fix and let me know if there are any further changes to be made?

cc @gaearon @sophiebits

[rickhanlonii]

Instead of hiding the overflow, what if we update the NextLink classes above, with this:

- md:w-80
+ md:w-fit md:min-w-80

This will expand the hoverable area to fit the content, with a minimum width of 80, so you can read the full API name, but shorter names will still be 80w:

Screen.Recording.2024-01-09.at.12.24.22.PM.mov

Note: this will require either adding { minWidth: { 80: '20rem' } } to the tailwind config, or upgrading to the latest tailwind version because min-w-x was added in 3.4: https://tailwindcss.com/blog/tailwindcss-v3-4#extended-min-width-max-width-and-min-height-scales

[rickhanlonii]

I would probably update the tailwind config in this PR and do the tailwind upgrade in a separate PR.

In tailwind.config.js replace:

maxWidth: {
  xs: '21rem',
},

With:

maxWidth: {
  // add this because it should be there anyway
  ...defaultTheme.maxWidth, 
  xs: '21rem',
},
minWidth: {
  ...defaultTheme.minWidth,
  80: '20rem',
},

[prajwalkulkarni]

Hey @rickhanlonii thank you for reviewing my PR. I agree with your suggestions, but I feel there's a small caveat. If we set the width to w-fit on the NextLink directly, there'd be no upper limit, meaning extra long strings would overlap the adjacent PREVIOUS card.

I could think of 2 ways to solve this:
METHOD 1 - Remove explicit width
Instead we could remove the explicit width on the NextLink and add only md:w-fit to the child div (since there's no width defined on the parent wrapper element, each hoverable card would occupy the full space, i.e, 50% of the total space available) regardless of the size of the content rendered within.

However, longer strings are rendered on multiple lines, so we retain the overflow-hidden.

METHOD 2 - Set max width along with min width
We add min-w-80 and w-fit and along with it we also set the max-width (max-w-md), and retain the overflow property to handle the string that is longer than what the max width can accommodate.

recording.mp4

Currently, I have implemented the second approach. But I'd love to know your thoughts on this and if I should change anything further.

[rickhanlonii]

Good point. I'm not concerned about it for APIs, but for translations this could be a problem.

Can method 2 wrap at max width instead of truncating?

[prajwalkulkarni]

Yes, I think that's a good idea. I tried adding a long string to the footer link with wrap instead of truncating it, and, we're able to show the complete string without loss of information(non-truncating). It is also in line with how long strings are rendered on the sidebar.

I've implemented break-words to break-normal for wrapping the string. Below is a snapshot of a long string with no spaces in it.

Since I'm using a class sorter extension on my VSCode, a few class names in DocsFooter.tsx have been re-arranged. I hope that's not an issue. But let me know if I have to revert it.

[rickhanlonii]

Looks great, thanks a ton for working on this!