This selector seems to be a bit too specific and does not cover top-level links:

To test this use-case, you can locally add a new entry to the sidebar configuration:, e.g.:

sidebar: [
  {
    label: "ThisIsAVeryLongLabelToTestTheSidebarIssues",
    link: "test",
  },
  // Existing sidebar configuration
];

Ohhh good catch! I've added this use case in the commit so that we can test it.
So I've dropped this rule and added instead the following which is less specific:

.top-level > li {
  overflow-wrap: anywhere;
}

I think an alternative solution could be to not do that and use overflow-wrap: anywhere; instead of overflow-wrap: break-word; in the <Badge/> component. This would mean that we would not have to do that every time we use a badge in a similar context.

Any thoughts?

Neat, it works pretty well! So obviously, this is way better in terms of usage since there's nothing to do while using the component.

I was a bit worried about overflow-wrap: anywhere browser support for Safari which is only from 15.4.

But the team confirmed that other features used in Astro and/or Starlight are only working from Safari 15.4.
I ran some tests with BrowserStack with Safari 15.3 just to see how's the fallback in our specific use case, but it's impossible to say what's happening:

I don't have access to any Safari 15.4, but from 16, everything's rendered as what you can see in your browser right now deployed by Netlify. Double-checked with various versions of Chrome and Firefox and seems to be good to go with this solution 🚀

Tried some flex-shriking on the caret without success.

What issues did you encounter? Disabling shrinking using flex-shrink: 0; on the caret icon and using overflow-wrap: anywhere; on the title seems to do the trick for me but I may be missing something.

Tried it in combination with overflow-wrap: break-word and not anywhere. It works way better now, thanks for the trick.

So I've dropped this rule and used overflow-wrap: anywhere here + used flex-shrink :0 on the caret.
More globally I've made this same exact change everywhere (overflow-wrap: break-word -> overflow-wrap: anywhere)

If I am not missing something, I guess like in the <SidebarSublist/> component, this could be avoided by using overflow-wrap: anywhere; instead of overflow-wrap: break-word; for the link.

Any thoughts?

Based on the previous comments and fixes, this has been removed.

This one is a bit trickier indeed.

The current approach will break the existing wrapping behavior on small width screens:

Before	After

It also looks like this would not work when you are on a page where both the previous and next links are fairly long:

Not sure yet what would be the best approach here, might need to think about it a bit more 🤔

Good catch, I didn't test at the right breakpoints for mobile. So I've tried something with a @media rule to handle the 2 types of rendering: 1 row, 2 rows:

a {
  /* ... */
  width: 100%;
  flex-basis: calc(100% - 0.5rem);
  /* ... */
}

@media (min-width: 29.6em) {
  a {
    width: 50%;
      flex-basis: calc(50% - 1rem);
    }
}

Note that 29.6em might be a lil' bit magical here. I've found this value by comparing the rendering between this branch and the main branch. The switch between 1 row to 2 rows was between 473px and 474px which led me to that 29.6em. Obviously, can be changed to something like 30em or other values.

Being still a bit tricky to test, I hope that I've covered most of the use cases 😅

Currently inside Starlight we only use (min-width: 50rem) and (min-width: 72rem). Would love to keep us to that consistency if possible.

This is definitely one of the trickier ones. I also think it’s one of the less crucial ones, so we could also decide to split out fixing this one into a follow-up PR if figuring it out will otherwise block this PR.

I definitely can understand that we prefer to stick with only (min-width: 50rem) and (min-width: 72rem). I've made some tests with container queries that could help but they are not available before Safari 16.
So I dropped this whole modification and I'll try to tackle it in a separate PR: #814

Currently inside Starlight we only use (min-width: 50rem) and (min-width: 72rem). Would love to keep us to that consistency if possible.

This is definitely one of the trickier ones. I also think it’s one of the less crucial ones, so we could also decide to split out fixing this one into a follow-up PR if figuring it out will otherwise block this PR.

Should this really only apply to the top-level list, or any li?

The components being black boxes, it's safe to apply the rule directly to li as defensive CSS. I've changed it to:

diff --git a/packages/starlight/components/SidebarSublist.astro b/packages/starlight/components/SidebarSublist.astro
index c4c5882..63308f6 100644
--- a/packages/starlight/components/SidebarSublist.astro
+++ b/packages/starlight/components/SidebarSublist.astro
@@ -53,6 +53,10 @@ interface Props {
                padding: 0;
        }
 
+       li {
+               overflow-wrap: anywhere;
+       }
+
        ul ul li {
                margin-inline-start: var(--sl-sidebar-item-padding-inline);
                border-inline-start: 1px solid var(--sl-color-hairline-light);
@@ -65,10 +69,6 @@ interface Props {
                color: var(--sl-color-white);
        }
 
-       .top-level > li {
-               overflow-wrap: anywhere;
-       }
-
        .top-level > li + li {
                margin-top: 0.75rem;
        }