Linux Documentation
 help / color / mirror / Atom feed
From: "Rito Rhymes" <rito@ritovision.com>
To: "Jonathan Corbet" <corbet@lwn.net>,
	"Daniel Lundberg Pedersen" <dlp@qtec.com>,
	<linux-doc@vger.kernel.org>, <linux-media@vger.kernel.org>,
	"Rito Rhymes" <rito@ritovision.com>
Subject: Re: Bad wrapping in some tables
Date: Fri, 10 Jul 2026 02:55:54 -0400	[thread overview]
Message-ID: <DJUP0UXLLHJ0.3P121A982R9TP@ritovision.com> (raw)
In-Reply-To: <87pl0yr9ah.fsf@trenco.lwn.net>

I just got caught up to speed, reviewing the links, the regression, the
prior state and other relevant context.

Daniel, thanks for pointing out the regression. As Jon said, it's
always good to inform the author of the patch, and I'd have been happy
to discuss and test out solutions with you.

> That overflow-wrap line is the problem. The patch was trying to
> improve overflow from some literal blocks, but it does seem that the
> cure is worse than the disease.

> This change causes truly unreadable breaking of literal strings in a
> number of settings.

Can anyone provide any examples of issues happening outside of tables?

If not, that suggests the fix is working fine except inside tables,
which means a targeted fix for tables is possible.

The intention of the fix is that inline literals in regular text bodies
that have a generally defined (max) width will respect that width and
not exceed it and cause overflow. It's serving that purpose and is a
sensible default behavior because it is often used like text in text
bodies and surrounded by other text, thus we make it also behave like
text.

I don't believe a reversion is the right answer, for two reasons.

Reason 1:

Reverting the fix restores the issues outside the tables it previously
fixed, and fixes some of the tables, but makes others just as
unreadable.

In the second example Daniel provided, there is a two column table
spanning the full width of the page on mobile viewport sizes without
overflowing. The left column is inline literals only, the right column
is regular text.

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

The left column of inline literals wraps down into vertical text and is
unreadable, because the column has no minimum width and expects the
contents to set the width, but it wraps immediately. That's a problem.
The right column text is readable, though it does some wrapping for a
few words.

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

The issue is as bad or worse. The left column is fully readable and
spans literals as far as needed, but it's crushing the right column and
forcing that into vertical text (maybe 2-3 characters wide), making
that column unreadable.

What's worse, unreadable vertical text as inline literals or as regular
text? Regular text is worse because it's meant to be descriptive, but
having either one is unacceptable.

Reason 2: the real culprit here is this:

Table mobile responsiveness in general in the Linux kernel
documentation is systemically pathological.

Many if not most of the tables on smaller screens overflow page width
and break the page margins. And this page is another example of
pathological table behavior where the table doesn't overflow and
break the page margins, it respects the page margin width, but
instead makes the content inside unreadable as vertical text, either
from the string literal wrapping or from the text wrapping. Neither
my current fix nor the reverted state resolves that issue.

The best solution:
Make targeted changes to the tables to make them fundamentally behave
better on smaller screen sizes.

I began this effort with:
[PATCH v3] docs: wrap generated tables to contain small-screen overflow

Jon hadn't followed up after testing out the fix with CSS and my
explaining why the wrapper was the better approach, because it prevented
regressions. That fix is a start, but more would need to be done.

If Daniel is willing to help test out table fixes and provide examples
of regressions, and if Jon has the bandwidth to review my patch
submissions to improve the tables, I am willing to tackle this systemic
issue, which will result in this issue being resolved as well.

Rito

  reply	other threads:[~2026-07-10  6:56 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-07 16:39 Bad wrapping in some tables Daniel Lundberg Pedersen
2026-07-07 17:14 ` Manuel Ebner
2026-07-07 17:36 ` Jonathan Corbet
2026-07-10  6:55   ` Rito Rhymes [this message]
2026-07-10  8:11     ` Hans Verkuil
2026-07-10  8:42       ` Mauro Carvalho Chehab
2026-07-10 12:38     ` Daniel Lundberg Pedersen
2026-07-10 13:17       ` Mauro Carvalho Chehab
2026-07-10 15:34     ` Jonathan Corbet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DJUP0UXLLHJ0.3P121A982R9TP@ritovision.com \
    --to=rito@ritovision.com \
    --cc=corbet@lwn.net \
    --cc=dlp@qtec.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox