On Sat, Nov 29, 2025 at 09:44:35AM -0800, Per Bothner wrote: > > > The downside is truncation for really short windows with long text, but I > > > think that is tolerable in this context. > > It's only tolerable if the section names are short enough to fit in the > > width > > of the screen, otherwise the reader of the manual is impaired. > > I think it is poor manual design for section names (as opposed to titles) be > too long. > And if overlong section names get truncated I don't think it's a big problem > for manual usability or readability. People don't really "read" the > navigation links > at the top/bottom of the page that closely anyway. If you're using a really > narrow window > you probably expect some degradation anyway.
It's not for us to tell users that their section names are too long. texi2any should still produce serviceable output even with long section names. Imagine the case of somebody reading a manual on a small mobile phone screen, with enlarged text (due to poor eyesight). They may rather have a larger screen, but be stuck with using a phone depending on their circumstances. > > They can't read the name of the referenced section without scrolling. > > Horizontal scrolling won't help if the name is truncated. Of course if the > links take up too > many lines you will need more vertical scrolling than one would like. > > > Moreover, the width of the rendered page is increased. > > Usually not - the width of the rendered page is restricted by the containing > window (or containing block, if that has a fixed width). If you look at the second screenshot I sent, you can see there was extra whitespace at the bottom right which could be seen by scrolling the page horizontally. (This is in Chromium 141.) Usually, the full width of the page would be visible by default and there would be no horizontal scroll bars. On a phone or other touch screen, somebody scrolling with their fingers might wobble the page from side to side as well as up and down, giving a worse experience (I haven't tested this.) > > We exchange a minor improvement > > in most cases for a much rarer, more severe problem. See attached > > screenshots. > > What is the problem? I think the screenshot is fine, given the over-long > section > name and the under-narrow window. > > A refinement would be to add a 'title' attribute to the span element with the > full text (or maybe the chapter/section title if available). That becomes > visible when the mouse hovers over the element. (Of course that doesn't help > on > a phone or using touchpad.) > > Common Lisp-style pretty-printing solves the problem, by using logical blocks > and > "linear" optional newlines. I have an implementation in DomTerm using > JavaScript. > It is a bit complicated, but it could be bundled with info.js. Basically you > run a > line-breaking algorithm whenever window size, scale, or styles change. Obviously, we don't want to be dependent on JavaScript to get good results, even if we can get a better experience with info.js. > It is useful for other things. For example code example can dynamically use > fewer or more lines depending on window width. See > https://domterm.org/saved/dt-prettynested.html > for examples of on-the-fly pretty-printing. This a "dynamic log" of > a terminal session - try adjusting the width of the window. > > > Adding a <span> around the the links with an appropriate class makes sense > > (Patrice used "nav-button"), but I don't think we should set the "nowrap" > > style by default. It should be up to users of texi2any to add that style > > if they want to. > I would use a css class, but set the default style for that class to > nowrap.Users can override it. It is just my feeling, but I suspect nowrap is > a more > generally-useful default. > > > That's assuming we can't find a better use of CSS that avoids this problem. > It might be possible with flexbox or some newer css feature, neither of > whichI know well enough. > -- > --Per Bothner > [email protected] http://per.bothner.com/ >
