Bad wrapping in some tables

Bad wrapping in some tables

[Daniel Lundberg Pedersen]

I've noticed some bad wrapping happening in tables, seemingly only in the Media
docs, but that's also where I look the most, after v7.1.

See:

https://www.kernel.org/doc/html/v7.1/userspace-api/media/v4l/vidioc-create-bufs.html#c.V4L.v4l2_create_buffers

Compared to:

https://www.kernel.org/doc/html/v7.0/userspace-api/media/v4l/vidioc-create-bufs.html#c.V4L.v4l2_create_buffers

Other tables have also changed, but they don't end up this bad, e.g:

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

I've bisected it to be f2679ac773899f5fdea0b68d5077eef5f88dfd42 that has caused
the change, and I did try some quick changes to see if I could fix it for the
tables, but I didn't get any positive results.


Regards Daniel

Re: Bad wrapping in some tables

[Manuel Ebner]

On Tue, 2026-07-07 at 18:39 +0200, Daniel Lundberg Pedersen wrote:
> I've noticed some bad wrapping happening in tables, seemingly only in the Media
> docs, but that's also where I look the most, after v7.1.
> 
> See:
> 
> https://www.kernel.org/doc/html/v7.1/userspace-api/media/v4l/vidioc-create-bufs.html#c.V4L.v4l2_create_buffers
> 
> Compared to:
> 
> https://www.kernel.org/doc/html/v7.0/userspace-api/media/v4l/vidioc-create-bufs.html#c.V4L.v4l2_create_buffers
> 
> Other tables have also changed, but they don't end up this bad, e.g:
> 
> https://www.kernel.org/doc/html/v7.1/process/debugging/kgdb.html#run-time-parameter-kgdbreboot
> 
> I've bisected it to be f2679ac773899f5fdea0b68d5077eef5f88dfd42 that has caused the
> change

Well done.

Please use git commit description style:  commit f2679ac77389 ("docs: allow inline
literals in paragraphs to wrap to prevent overflow")

I added the people involved in this patch to cc.

Thanks
 Manuel

> and I did try some quick changes to see if I could fix it for the
> tables, but I didn't get any positive results.
> 
> 
> Regards Daniel

Re: Bad wrapping in some tables

[Jonathan Corbet]

Daniel Lundberg Pedersen <dlp@qtec.com> writes:

> I've noticed some bad wrapping happening in tables, seemingly only in
> the Media docs, but that's also where I look the most, after v7.1.
>
> See:
>
> https://www.kernel.org/doc/html/v7.1/userspace-api/media/v4l/vidioc-create-bufs.html#c.V4L.v4l2_create_buffers
>
> Compared to:
>
> https://www.kernel.org/doc/html/v7.0/userspace-api/media/v4l/vidioc-create-bufs.html#c.V4L.v4l2_create_buffers
>
> Other tables have also changed, but they don't end up this bad, e.g:
>
> https://www.kernel.org/doc/html/v7.1/process/debugging/kgdb.html#run-time-parameter-kgdbreboot
>
> I've bisected it to be f2679ac773899f5fdea0b68d5077eef5f88dfd42 that
> has caused the change, and I did try some quick changes to see if I
> could fix it for the tables, but I didn't get any positive results.

For future reference, it really does help to copy the maintainer and the
author of the patch.

The patch in question tweaked our CSS thusly:

> +code.docutils.literal span.pre {
> +    white-space: normal;
> +    overflow-wrap: anywhere;
> +}

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.

I've just made the attached revert - thanks for the report!

jon

From 1afefde902c5267d1197da8a3b039354ed771d37 Mon Sep 17 00:00:00 2001
From: Jonathan Corbet <corbet@lwn.net>
Date: Tue, 7 Jul 2026 11:34:47 -0600
Subject: [PATCH] Revert "docs: allow inline literals in paragraphs to wrap to
 prevent overflow"

This reverts commit f2679ac773899f5fdea0b68d5077eef5f88dfd42.

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

Reported-by: Daniel Lundberg Pedersen <dlp@qtec.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
---
 Documentation/sphinx-static/custom.css | 9 ---------
 1 file changed, 9 deletions(-)

diff --git a/Documentation/sphinx-static/custom.css b/Documentation/sphinx-static/custom.css
index 5aa0a1ed9864..2e019c8f8a56 100644
--- a/Documentation/sphinx-static/custom.css
+++ b/Documentation/sphinx-static/custom.css
@@ -156,15 +156,6 @@ div.language-selection ul li:hover {
     background: #dddddd;
 }
 
-/*
- * Let long inline literals in paragraph text wrap as needed to prevent
- * overflow.
- */
-code.docutils.literal span.pre {
-    white-space: normal;
-    overflow-wrap: anywhere;
-}
-
 /* Let rendered reference links in tables wrap when needed. */
 div.body table.docutils a.reference {
     overflow-wrap: anywhere;
-- 
2.54.0

Re: Bad wrapping in some tables

[Rito Rhymes]

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

Re: Bad wrapping in some tables

[Hans Verkuil]

On 10/07/2026 08:55, Rito Rhymes wrote:
> 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
> 

FYI: the Media subsystem userspace API is full of tables, e.g.:

https://docs.kernel.org/userspace-api/media/v4l/vidioc-enuminput.html
https://docs.kernel.org/userspace-api/media/cec/cec-ioc-receive.html

There are many, many more of those.

Currently it is basically unreadable due to the breaking up of the literals.

Hopefully this can be fixed. I only noticed this issue yesterday, so it was
good to see your email so I know why it changed.

We're well aware that the tables in the media subsystem do not work well on
small screens. The only workable solution would be to move away from tables
and format it differently. And that's not going to happen as that would be a
massive job.

Regards,

	Hans

Re: Bad wrapping in some tables

[Mauro Carvalho Chehab]

On Fri, 10 Jul 2026 10:11:20 +0200
Hans Verkuil <hverkuil+cisco@kernel.org> wrote:

> On 10/07/2026 08:55, Rito Rhymes wrote:
> > 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
> >   
> 
> FYI: the Media subsystem userspace API is full of tables, e.g.:
> 
> https://docs.kernel.org/userspace-api/media/v4l/vidioc-enuminput.html
> https://docs.kernel.org/userspace-api/media/cec/cec-ioc-receive.html
> 
> There are many, many more of those.
> 
> Currently it is basically unreadable due to the breaking up of the literals.

Breaking up literals is more important on PDF output, if one wants to print
the documentation.

> Hopefully this can be fixed. I only noticed this issue yesterday, so it was
> good to see your email so I know why it changed.
> 
> We're well aware that the tables in the media subsystem do not work well on
> small screens. The only workable solution would be to move away from tables
> and format it differently. And that's not going to happen as that would be a
> massive job.

IMO what should be changed is the maximum column limit at the html CSS profile.

Right now it sets max-width to 800px, which comes from basic.css:

	div.body {
	    min-width: inherit;
	    max-width: 800px;
	}

This is quite small on my monitor (it is a wide monitor with 5120px).

I would override this to none, to let it auto-adjust it to the actual
monitor limits.

Thanks,
Mauro

Re: Bad wrapping in some tables

[Rito Rhymes]

> Breaking up literals is more important on PDF output, if one wants to
> print the documentation.

Could you clarify what you mean by PDF output here? Are you referring to
printing the HTML page through the browser, or to the PDF generated by
the Sphinx build process?

Are there any known problems or constraints we should account for
printing? I assume you may mean that long unbroken literals can make
tables wider than the printable page and hide outer columns, that and
horizontal scroll overflow in general may be clipped when printing,
making wrapping preferable for that output.

That makes sense for print, but it is not necessarily the preferable
behavior for navigating the normal HTML page, where contained horizontal
scroll overflow can preserve the page and table structure. I do not
think the print constraint should override the primary HTML
presentation.

I would like to account for both. If this concerns browser printing, we
may be able to apply the necessary wrapping selectively through
`@media print`.

Rito

Re: Bad wrapping in some tables

[Rito Rhymes]

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

Re: Bad wrapping in some tables

[Daniel Lundberg Pedersen]

Hi

On 10/07/2026 08:55, Rito Rhymes wrote:
> 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.

Sorry about that, I'll remember that for next time.

[...]
> 
> 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.

I don't mind testing some stuff if you want me to, but as Hans mentions 
the media docs is full of tables which have these issues, from a quick
check, almost all sub-pages of the Function Reference are affected:

https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/user-func.html

> 
> Rito


Regards Daniel

Re: Bad wrapping in some tables

[Mauro Carvalho Chehab]

On Fri, 10 Jul 2026 14:38:06 +0200
Daniel Lundberg Pedersen <dlp@qtec.com> wrote:

> Hi
> 
> On 10/07/2026 08:55, Rito Rhymes wrote:
> > 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.  
> 
> Sorry about that, I'll remember that for next time.
> 
> [...]
> > 
> > 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.  
> 
> I don't mind testing some stuff if you want me to, but as Hans mentions 
> the media docs is full of tables which have these issues, from a quick
> check, almost all sub-pages of the Function Reference are affected:
> 
> https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/user-func.html

On media, I guess the more complex tables with long widths are the pixfmt 
ones like those:

	https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/pixfmt-rgb.html
	https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/pixfmt-packed-yuv.html

It is a good place to check for issues like that.

Please see the patch I submitted:

	https://lore.kernel.org/linux-doc/1950557405f1150acb1de50de1801f2413223b87.1783673996.git.mchehab+huawei@kernel.org/

It moves width support at the html output from previous
millennium SVGA-resolutions era to modern age.

-- 
Thanks,
Mauro

Re: Bad wrapping in some tables

[Jonathan Corbet]

"Rito Rhymes" <rito@ritovision.com> writes:

> Reason 2: the real culprit here is this:
>
> Table mobile responsiveness in general in the Linux kernel
> documentation is systemically pathological.

I honestly have to question how important that is to us.  How many
people are really trying to make use of the kernel documentation on
small-screen devices?  This is the kind of information you need when you
have editor and terminal windows open.

Making small screens work better is fine on its own, but I don't think
it should be done at the cost of proper rendering on the sort of devices
that developers actually use.  There are limits to which we want to
develop and maintain our own custom theme for a use case that, I
believe, is pretty rare.

Thanks,

jon

Re: Bad wrapping in some tables

[Rito Rhymes]

> > Reason 2: the real culprit here is this:
> >
> > Table mobile responsiveness in general in the Linux kernel
> > documentation is systemically pathological.
>
> I honestly have to question how important that is to us. How many
> people are really trying to make use of the kernel documentation on
> small-screen devices? This is the kind of information you need when
> you have editor and terminal windows open.

To clarify, when I say mobile responsive, I'm using that as a term of
art for narrow viewports within the tablet / mobile window size range,
I'm not specifically or exclusively referring to mobile devices, and I'm
operating knowing that desktop is the primary medium here. The fixes
should all be improving desktop experience at these narrow sizes; mobile
devices also being improved but not as the primary focus.

> I tend to use relatively narrow browser windows so that I can fit more
> of them on the screen

^ (Your response in the thread for Mauro's body width change)

You are one of the beneficiaries, among many others with similar
habits on desktop that make use of narrow windows.

I'm testing a few things out to see what's a reasonably simple path
forward.