Fix experience between 880-1024 px widths

[morsssss]

Summary

Tweak Mintlify CSS so that we don't simply show the quite inferior mobile view when someone shrinks their desktop browser window to <1024px width. Instead, continue to show the sidebar, the search bar, and most other elements until the window really gets too small.

Rationale

Currently the experience on desktop browsers at widths <1024 px is quite inferior:

This PR improves matters:

I can't find stats right now, but I remember seeing a few years ago that a significant percentage of page views on desktop involved widths < 1024px. So I do believe this is an experience well worth fixing.

The downside, of course, is that overriding Mintlify's CSS may harm maintainability. They might change their CSS in ways that make ours substandard. Of course, our experience is so substandard now!

I tried to at least write CSS that was maintainable - that involved selectors that would seldom change whenever possible, that followed a predictable pattern, and that is carefully commented. If certain bits seem undesirable, we can also remove those bits - as once I did the most important thing, which is keeping the sidebar and tabs visible, I made further tweaks to increase our horizontal space, trying to overcome the challenge of our wide left sidebar (which, for example, OpenAI made very narrow).

[Copilot]

Pull request overview

This PR improves the desktop browsing experience for screen widths between 880px and 1024px by overriding Mintlify's default CSS to preserve the desktop layout instead of switching to the inferior mobile view. The changes introduce custom media queries that maintain the sidebar, search bar, and tabs at smaller desktop widths.

Key Changes:

• Adds a new 880px breakpoint with custom styles to preserve desktop UI elements
• Adjusts sidebar width, padding, and margins to optimize horizontal space usage
• Overrides Mintlify's responsive behavior to prevent premature mobile view activation

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The selector relies on generic class names that are likely to change. Similar to the searchbar selector above, ".hidden.px-12.h-12" is fragile and may break with Mintlify updates. Consider documenting this brittleness or using more stable alternatives if available.

Suggested change

	/* Retain tabs */
	/* Retain tabs.
	* NOTE: This selector intentionally relies on Mintlify's current utility classes
	* (.hidden.px-12.h-12) and may break if Mintlify changes its markup or class names.
	* If Mintlify provides a more stable hook (e.g., an id or data-attribute) for the
	* tabs container in the future, this rule should be updated to use that instead.
	*/

[leoncheng57]

"px-12.h-12" are also too fragile. Are there other selectors?

[morsssss]

Sadly, this is the other case where we don't have a unique, nonfragile selector. My only other idea was to see if we could work down from a more specifically selected parent, but to me that seems worse.

So, the two most fragile selectors here make the searchbar and tabs visible at this intermediate width. I believe the worst-case scenario here is that those will remain invisible, as they are now.

[leoncheng57]

"px-12.h-12" are also too fragile. Are there other selectors?

[morsssss]

@leoncheng57 I realized that the remaining fragile selectors either had id's or had direct children with an id. So I changed, for example, this:

    #navbar .hidden.px-12.h-12 {
      display: block;
    }

to this:

  @supports selector(:has()) {
    div:has(> .nav-tabs) {
      display: block;
    }
  }

  @supports not selector(:has()) {
    #navbar .hidden.px-12.h-12 {
      display: block;
    }
  }

Not perfect, because we still rely on Mintlify's HTML structure. But I think it's much nicer than it was. I kept the fallback for browsers which don't support :has().

Thanks for pushing on this. I do believe we've arrived at a superior solution!