Hi Konstantin (and Git mailing list, for transparency),

the website of GitGitGadget was made responsive recently (https://github.com/gitgitgadget/gitgitgadget.github.io/pull/26) meaning that it will look good not only on a desktop, but also on a cell phone.

The same contributor (Rito, Cc:ed) told me that he would be interested to help kernel.org's site become responsive, too. He even has a live demo at https://kernel.ritovision.com/. Interested?

Ciao, Johannes

On Fri, Mar 13, 2026 at 07:52:13AM +0100, Johannes Schindelin wrote:

First time I hear of it. I can take a look!

Thanks Konstantin, I appreciate it.

I'll send the patch series in a separate thread shortly for review.

Rito

On Fri, Mar 13, 2026 at 09:14:38AM -0400, Rito Rhymes wrote:

Oh, I just found a bunch of your messages in my spam folder. Sorry! Google really dislikes messages without a DKIM signature. You should look into fixing that. :)

Yikes! I'll have to take a look at that.

I just sent the first patch series.

I also have a follow-up patch ready that adds a clean mobile nav header to complete the UI, if the first series merges.

Konstantin Ryabitsev <konstantin@linuxfoundation.org> writes:

FWIW, we also have gitweb patches from the same author graduated to the 'master' branch preparing for the next release as of a week or so ago.

Thanks, Rito.

Actually...

now that I've had time to think about it (and get some rest), I think it's best to keep the patch series review and discussion all in this thread, publicly and transparently.

I initially defaulted to sending it separately to Konstantin directly because this is Git's archive, and I wanted to respect convention by keeping the thread appropriately scoped. At first, this seemed more like just a routing touchpoint.

But seeing as there is no public mailing list for kernel.org's repo specifically, and this is basically already a sidecar thread about the site theme patch, we might as well consolidate the process here for simplicity and transparency. Plus, I imagine the site matters to most people in Git, and the mailing list is archived on lore.kernel.org anyway...

This will allow anyone to review the code and comment on it.

I'm sending the patch series again directly in this thread, and I think we should keep communication contained here (unless someone has a better idea).

Currently, pages on mobile devices render against a desktop-width viewport, which makes the content appear tiny and forces users into a pan-zoom dance of pinch-zooming and horizontal panning to read content rather than simple vertical scrolling. The first patch establishes the correct baseline by setting the viewport width to the device width. Once the site is allowed to render at actual mobile widths, however, numerous latent layout issues emerge. The remaining patches address those issues with targeted responsive adjustments.

It is not a transformative redesign and is not intended to affect the desktop layout.

Rito Rhymes (6):
  add viewport meta tag for proper mobile rendering
  prevent wrapped headings from overlapping with text above it
  add 848px mobile banner adjustments to prevent overflow
  add responsive extras and footer layout adjustments to contain
    overflow
  contain horizontal overflow in core content and homepage releases
    layout
  improve mobile rendering of docutils tables

 korgi/static/css/main.css | 154 +++++++++++++++++++++++++++++++++++++-
 korgi/templates/base.html |   1 +
 2 files changed, 153 insertions(+), 2 deletions(-)

The site UI is broken on mobile because pages currently render at desktop width on phones, which makes the content appear tiny and forces users into a pan-zoom dance of pinch-zooming and horizontal panning to read content. Adding a viewport meta tag to set the viewport width to the device width enables normal vertical scrolling on small screens and establishes the baseline layout for follow-up mobile fixes.

Signed-off-by: Rito Rhymes <rito@ritovision.com>
---
 korgi/templates/base.html | 1 +
 1 file changed, 1 insertion(+)

The Oswald heading font has tall ascenders/descenders, and at the prior line-height wrapped heading lines can visually overlap adjacent text above, reducing legibility. This is most noticeable on mobile, especially in the desktop banner where the title wraps and overlaps with itself.

Apply this as a global heading rule as a consistent policy for anywhere heading wrap can occur. Some desktop views may not show the issue yet due to available width, but the underlying font behavior is the same and can surface as content or layout changes.

Adjust banner heading and nav spacing to offset the line-height change, preserving the original desktop banner visual layout.

Signed-off-by: Rito Rhymes <rito@ritovision.com>
---
 korgi/static/css/main.css | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

At widths below 848px, the desktop banner structure is too wide and creates page-wide horizontal scroll overflow, breaking the layout.

Introduce a mobile breakpoint at 848px (equivalent to 53em at a 16px base font size), matching the site's existing fixed-width layout scale.

Adjust banner sizing and spacing at this breakpoint while preserving the existing desktop layout for viewport widths above it.

This patch is intentionally banner-only. The overall mobile layout will still not render correctly until corresponding main-content and footer overflow fixes are applied in follow-up commits.

Signed-off-by: Rito Rhymes <rito@ritovision.com>
---
 korgi/static/css/main.css | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

Below 848px, fixed-width extras and footer blocks overflow the page and create page-wide horizontal scrolling that breaks layout.

Make extras and footer sections responsive by switching extras to wrapping layout, stacking blogroll/social blocks to full width, and relaxing fixed heights/widths. Update donors to wrap logos and hide manual <br> breaks so the sponsor area reflows naturally on small screens.

Add 550px and 400px refinements to progressively reduce blogroll/social column counts (3 -> 2 -> 1), preventing overlap and preserving readability as viewport width shrinks.

This patch is intentionally limited to extras/footer behavior; content and homepage table overflow handling are addressed separately.

Signed-off-by: Rito Rhymes <rito@ritovision.com>
---
 korgi/static/css/main.css | 84 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 84 insertions(+)

On narrow viewports, fixed-width content containers, homepage release sections, and long preformatted strings can force page-wide horizontal overflow.

Realign #protocols and #latest for narrow screens so they do not overflow and can wrap down as needed to fit.

Make #releases scroll within its own container, and keep release-date cells readable on mobile with nowrap and horizontal padding.

Allow preformatted blocks to scroll horizontally within their own region instead of expanding page width and creating page-wide horizontal scrolling.

Signed-off-by: Rito Rhymes <rito@ritovision.com>
---
 korgi/static/css/main.css | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

On narrow viewports, docutils tables become hard to read: the releases table compresses too tightly, and the signatures fingerprint values wrap and lose scanability.

Both /releases.html and /signature.html use table.docutils, and their cells contain data values (versions, dates, fingerprints) rather than sentence prose. Keep mobile behavior consistent with desktop by treating these as single-line values and preserving readability.

Make docutils tables horizontally scrollable within their container so cells can keep single-line values without forcing column collapse or value wrapdown on narrow viewports.

Adjust border drawing for the scrollable table state by resetting default cell borders and reapplying explicit grid edges to avoid uneven/doubled outer borders.

Signed-off-by: Rito Rhymes <rito@ritovision.com>
---
 korgi/static/css/main.css | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

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

I would not object discussion here, and I personally do not mind having to see, and possibly ignore, more patches on this list, but to those who come here to work with and work on Git, I am reasonably sure that it will look offtopic to discuss how the k.org website appears and behaves, and/or how a better version of it would appear and behave.

I'll leave Konstantin with the final say. I hope there are better places, even though I do not now where they are as I do not do websites. I've seen folks with accounts at k.org discuss things on mailing lists that is more limited for kernel.org users.

I see where you're coming from, Junio. I don't want to distract people, and I guess there's also the matter of review fit, where not many people here are inclined to contribute to websites, so there may be more suitable venues for this elsewhere.

Konstantin, whatever venue you decide is cool with me.

Rito

On Sat, Mar 14, 2026 at 02:54:01PM -0400, Rito Rhymes wrote:

I've added CONTRIBUTING.md to the website, which describes how to submit contributions to the website. Apologies that it didn't exist before -- this is literally the second time in the past 15 years that someone's contributed any code to it. :)

Please review, rebase on the latest master, and submit to the right list.

Thank you!

Best wishes,

Okay cool. Will do.

Thank you!

Rito