Re: Bad wrapping in some tables

["Rito Rhymes" <rito@ritovision.com>]

I now have a working solution that addresses both the general table
responsiveness issues throughout the docs site and the specific table
problems with unreadable vertical text / inline literals / narrow
content wrapping as first discussed in this thread.

> The only workable solution would be to move away from tables
> and format it differently.

The tables remain the same formatted tables as before, unremarkable,
they just work properly now at different viewport sizes and remain
readable throughout regardless of their contents.

No JavaScript. No new dependencies. No formatting overhaul.

The solution is a set of targeted changes plus a small build-time layer
that injects per-column CSS to assign balanced widths in a way that
generalized selectors can't normally target based on table contents.

It's ready for others to test out. The patch series is:

[PATCH 0/2] docs: make tables responsive with content-aware column
widths

I also have a demo site of Linux Kernel docs at:

linux-tables.ritovision.com

Please test the previously affected pages and anywhere else and let me
know whether any issues remain.

** One visible change is the wider layout. Mauro's queued change raises
the body's max-width from 800px to 120em, allowing content to use
substantially more of the available desktop width. This series builds
on that change, which Jon approved:

  [PATCH] docs: custom.css: don't limit randering to old 800px monitors

The wider layout is useful for tables, but a more selective max-width
can still be applied to prose or other content if desired.


About the solution:

1. Foundational contained horizontal overflow
2. Content-aware targeted CSS

For integration, this series is intended to replace the two pending
docs-next changes: it retains inline-literal overflow-wrap: anywhere
instead of carrying Jon's revert, and uses max-width: none instead of
Mauro's 120em limit.

1. Foundational contained horizontal overflow

For tables to behave responsively across viewport sizes, they need to
overflow locally when they are too wide rather than expanding the entire
page or compressing multiple columns until their contents become
unreadable.

This series adds contained horizontal overflow for generated tables.
Applying overflow directly to the table causes doubled borders and other
rendering defects, so the overflow is placed on an outer wrapper instead.
The table remains visually unchanged and scrolls within that wrapper when
necessary. The wrapper is added at build time through table_layout.py.

Once tables can scroll within their own container, the document body
must be wide enough to avoid forcing local scrolling while usable
viewport space remains. Mauro's change raises the body max-width from
800px to 120em, which Jon approved, giving tables substantially more
room across ordinary desktop layouts. This series builds on that change.

A table remains contained and becomes locally scrollable when its
readable width exceeds the available viewport space or, on wider
layouts, the 120em body maximum. A narrower max-width can still be
applied selectively to prose or other content without further
constraining tables.

2. Content-aware targeted CSS

The first issue identified in this thread was inline literals wrapping
into unreadable vertical text inside tables. The global
overflow-wrap: anywhere rule remains necessary because it allows long
inline literals to wrap rather than overflow their containers and break
the surrounding layout.

Tables introduce a different constraint. The same wrapping behavior can
become too aggressive inside narrow columns, causing inline literals to
collapse into vertical text. However, restoring non-wrapping behavior
for inline literals inside tables creates the opposite failure: the
literal column consumes more width and compresses neighboring text
columns until they become unreadable instead.

These opposite failures can be seen on the same table at viewport widths
of 500px or narrower.

In v7.1, the inline-literal column collapses:

https://www.kernel.org/doc/html/v7.1/process/debugging/kgdb.html#run-time-parameter-kgdbreboot

In v7.0, the neighboring text column collapses:

https://www.kernel.org/doc/html/v7.0/process/debugging/kgdb.html#run-time-parameter-kgdbreboot

With the series applied, both columns remain readable:

https://linux-tables.ritovision.com/process/debugging/kgdb.html#run-time-parameter-kgdbreboot

This creates an impasse for generalized CSS selectors. A rule that fixes
one column can create an imbalance in another because CSS selectors
cannot derive an appropriate minimum width from each column's actual
contents.

Rather than adding widths manually or using client-side JavaScript, the
existing build-time layer measures each logical column and assigns a
content-derived CSS class. Those classes establish a readable minimum
width for each column while still allowing the table layout to
distribute additional space naturally.

Wrapping remains available as a safeguard for unusually long literals,
identifiers, and URLs, preventing them from forcing unbounded column
widths. The content-derived minimums prevent that wrapping from occurring
so aggressively that either the literal column or its neighboring text
columns collapse into vertical text.

Rito