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

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

[Mauro Carvalho Chehab]

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; }
+
 /* Shrink the headers a bit */
 div.body h1 { font-size: 180%; }
 div.body h2 { font-size: 150%; }
-- 
2.55.0

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

[Jonathan Corbet]

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?

Thanks,

jon

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

[Mauro Carvalho Chehab]

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.

If you don't want to let it become too big(*), then perhaps it could
be something like:

	div.body {  max-width: 80%; }

(*) personally, I don't see any issues on it. My monitor's ratio is
    32/9. Quite the opposite, with such ultra-wide screen, I don't like
    sites that have fixed max-width limits, as they end limiting my
    personal taste for no good reason.

Thanks,
Mauro

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

[Jonathan Corbet]

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 you don't want to let it become too big(*), then perhaps it could
> be something like:
>
> 	div.body {  max-width: 80%; }

I like that even less...I tend to use relatively narrow browser windows
so that I can fit more of them on the screen...it shouldn't waste that
space unnecessarily.

> (*) personally, I don't see any issues on it. My monitor's ratio is
>     32/9. Quite the opposite, with such ultra-wide screen, I don't like
>     sites that have fixed max-width limits, as they end limiting my
>     personal taste for no good reason.

Well, I won't fight about it (too much :).  I definitely agree that the
800px value makes little sense.

jon

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

[Mauro Carvalho Chehab]

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).

> 
> > If you don't want to let it become too big(*), then perhaps it could
> > be something like:
> >
> > 	div.body {  max-width: 80%; }  
> 
> I like that even less...I tend to use relatively narrow browser windows
> so that I can fit more of them on the screen...it shouldn't waste that
> space unnecessarily.

Agreed.

> > (*) personally, I don't see any issues on it. My monitor's ratio is
> >     32/9. Quite the opposite, with such ultra-wide screen, I don't like
> >     sites that have fixed max-width limits, as they end limiting my
> >     personal taste for no good reason.  
> 
> Well, I won't fight about it (too much :).  I definitely agree that the
> 800px value makes little sense.
> 
> jon



Thanks,
Mauro

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

[Mauro Carvalho Chehab]

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%; }