From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: Jonathan Corbet <corbet@lwn.net>
Cc: Linux Doc Mailing List <linux-doc@vger.kernel.org>,
linux-kernel@vger.kernel.org,
Clinton Phillips <clintdotphillips@gmail.com>,
Daniel Lundberg Pedersen <dlp@qtec.com>,
Hans Verkuil <hverkuil+cisco@kernel.org>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Petr Vorel <pvorel@suse.cz>, Randy Dunlap <rdunlap@infradead.org>,
Rito Rhymes <rito@ritovision.com>,
Shuah Khan <skhan@linuxfoundation.org>,
linux-media@vger.kernel.org
Subject: Re: [PATCH] docs: custom.css: don't limit randering to old 800px monitors
Date: Sat, 11 Jul 2026 09:48:21 +0200 [thread overview]
Message-ID: <20260711094821.5e262356@foz.lan> (raw)
In-Reply-To: <20260711001015.3cf5d166@foz.lan>
On Sat, 11 Jul 2026 00:10:15 +0200
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> On Fri, 10 Jul 2026 13:52:55 -0600
> Jonathan Corbet <corbet@lwn.net> wrote:
>
> > Mauro Carvalho Chehab <mchehab+huawei@kernel.org> writes:
> >
> > > On Fri, 10 Jul 2026 09:27:23 -0600
> > > Jonathan Corbet <corbet@lwn.net> wrote:
> > >
> > >> Mauro Carvalho Chehab <mchehab+huawei@kernel.org> writes:
> > >>
> > >> > Right now, base.css style imposes a maximum limit of 800 horizontal
> > >> > pixels to be compatible with very old SVGA monitors.
> > >> >
> > >> > Remove such artificial limit, letting the output to be adjusted to
> > >> > the browser windows size.
> > >> >
> > >> > Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> > >> > ---
> > >> > Documentation/sphinx-static/custom.css | 2 ++
> > >> > 1 file changed, 2 insertions(+)
> > >> >
> > >> > diff --git a/Documentation/sphinx-static/custom.css b/Documentation/sphinx-static/custom.css
> > >> > index 5aa0a1ed9864..1055db7dc1dd 100644
> > >> > --- a/Documentation/sphinx-static/custom.css
> > >> > +++ b/Documentation/sphinx-static/custom.css
> > >> > @@ -3,6 +3,8 @@
> > >> > * CSS tweaks for the Alabaster theme
> > >> > */
> > >> >
> > >> > +div.body { max-width: none; }
> > >> > +
> > >>
> > >> 800px is clearly a dumb limit, I have no problem changing that. Going
> > >> to arbitrary width doesn't seem good for readability, though. What do
> > >> you think about, instead, setting a limit in a resolution-independent
> > >> say, to (say) 60em?
> > >
> > > 60em also seems too small, considering the size of tables we have on
> > > media. Some tables have one column for each bit, plus one or two other
> > > columns, so the table would easily have up to 34 columns. After adding
> > > long fourcc codes there and V4L macro names, it can easily be very big,
> > > in terms of "em" measures.
> >
> > I did say "say" :) I don't feel the need to argue too much about the
> > exact value. I do believe, though, that excessively wide columns are
> > not good human factors in general.
>
> If one gets a big enough "em" to fit the largest tables and ascii artwork,
> I'm ok using "em" but one would need to double check what's the bigger
> one, which would require some time and someone would need to periodically
> review it.
>
> My feeling is that, on media, the bigger tables are the pixformat ones,
> but maybe the biggest one is somewhere else.
>
> Most (if not all) artwork fits on 80 columns, but I vaguely remember
> some that were bigger (can't remember if they were changed to fit on
> 80 cols).
>
> Probably a way to define a limit that covers artwork would be to run a script
> to get the max column size for .rst files. Not perfect because of indentation,
> on codeblocks, but it could work as a hint. Unfortunately, this won't work
> for tables using flat-table (which is used on ~235 files - most on media,
> but ~20 files elsewhere).
After sleeping on it, I think that we need something bigger than 100em,
as this is is the checkpatch.pl max columns warning limit. To align with
most pixfmt tables on media, 120em sounds a reasonable limit.
Patch enclosed.
Thanks,
Mauro
[PATCH] docs: custom.css: don't limit randering to old 800px monitors
Right now, base.css style imposes a maximum limit of 800 horizontal
pixels to be compatible with very old SVGA monitors.
This is not enough to display some tables like pixformat ones on
media. Instead, use a more realistic maximum limit.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
diff --git a/Documentation/sphinx-static/custom.css b/Documentation/sphinx-static/custom.css
index 2e019c8f8a56..be33d9ed1280 100644
--- a/Documentation/sphinx-static/custom.css
+++ b/Documentation/sphinx-static/custom.css
@@ -3,6 +3,8 @@
* CSS tweaks for the Alabaster theme
*/
+div.body { max-width: 120em; }
+
/* Shrink the headers a bit */
div.body h1 { font-size: 180%; }
div.body h2 { font-size: 150%; }
prev parent reply other threads:[~2026-07-11 7:48 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-10 9:00 [PATCH] docs: custom.css: don't limit randering to old 800px monitors Mauro Carvalho Chehab
2026-07-10 15:27 ` Jonathan Corbet
2026-07-10 19:19 ` Mauro Carvalho Chehab
2026-07-10 19:52 ` Jonathan Corbet
2026-07-10 22:10 ` Mauro Carvalho Chehab
2026-07-11 7:48 ` Mauro Carvalho Chehab [this message]
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=20260711094821.5e262356@foz.lan \
--to=mchehab+huawei@kernel.org \
--cc=clintdotphillips@gmail.com \
--cc=corbet@lwn.net \
--cc=dlp@qtec.com \
--cc=hverkuil+cisco@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=pvorel@suse.cz \
--cc=rdunlap@infradead.org \
--cc=rito@ritovision.com \
--cc=skhan@linuxfoundation.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