/cc @fflewddur @Joanne881107 for UX input

Totally agreed that scroll-in-scroll of tall code blocks is painful. A few options here:

1. Since we do not have other horizon scrolling needs other than the code snippet, we can use the browser horizon scrolling for the code snippet as a quick fix.
2. As an UI enhancement, we can also consider enabling pop up the code in a full screen layer as an alternative option. Example here:
   

@Joanne881107 personal preference would be #1 as a permanent solution. Simple, standard, and no accidental pop-ups from my touchpad.

I think we can and should avoid the need for visitors to do anything (either horizontal scrolling or viewing a pop up / overlay) in order to view this documentation. When the browser width is < 975px, we currently condense the details and outline, allowing the documentation to fill the full browser width. Above 975px, we immediately enable both the left and right sidebars. I suggest we add a third state, where the details sidebar continues to use the condensed horizontal view, and only switch to the 3-column layout when the center column will still be wide enough to display ~90 characters in preformatted boxes (which is what is causing the horizontal scrolling here).

The 90 character limit is arbitrary; it might be worth doing an analysis on the documentation corpus to identify a limit that matches current practices, but anything between 80-100 seems reasonable to me.

I think the above approach would also help with #44172.

@fflewddur

Not getting much value out of the 3rd column. Most of it is empty. If it's there just to aid in tracking the text, could just cap the width per-paragraph instead of the entire div.

Letting the code blocks be as wide as they need to be (instead of scroll-in-scroll, or wrapping) would be a better experience IMHO.

@BourgeoisBear I like the idea of letting the the code blocks run longer than they currently do, but we're trying to balance that with the width of non-code text, which does need a max width to support readability. So, even if there was no third column, we would still want to limit the maximum line length for regular text. If it's technically feasible to allow <pre> blocks to run longer than regular text, that's a design worth exploring. Thanks for the suggestion!

@fflewddur, I made a mock-up using the developer console:

Two columns instead of three, 2nd w/ width=auto, put max width on <p>, leave <pre> sized to content.

The serif font is from my browser style overrides. I think it reads easier than sans-serif, but that is an artifact, not a request.

We are testing out layout changes on the beta site to address this issue. See https://beta.pkg.go.dev/robpike.io/ivy.

These changes are now live.