Page MenuHomePhabricator

Bring Reading Lists sub-grid in certain viewport ranges and item combos (1, 2 or 3 items) to design
Closed, ResolvedPublic2 Estimated Story Points

Description

Background / Goal

Coming from T406628, there are certain viewport configurations and item combinations where the design is not followed at the moment.

Screenshot 2025-10-14 at 12.29.14 PM.png (1×2 px, 595 KB)

Screenshot 2025-10-16 at 4.03.10 PM.png (1×3 px, 195 KB)

Viewports range causing items:
Between ~1050 and 1190px with 3 items

Items causing issues
Under three items saved.

Requirements

We've settled on the Card internals in layout and text clamping.

  • 4 Cards limit per row, even on widest desktop
  • Cards should auto-fill the space whenever possible on mobile, on tablet and desktop only when there's enough Cards (2 on tablet, 3 on desktop) available
  • Codex gap of 16px must not widen, no matter with auto-filled rows
  • Left align Cards always for best readability, no center alignment if number of cards < available space

We have

  • 20rem (equal to 320px) as minimal Card width [was 22rem (equal to 352px) in earlier iteration, but iPhone's 375px viewport needed us to reduce slightly] and
  • 28rem (equal to 448px) as max Card width, alternatively
  • 34rem (equal to 544px) as max mobile Card width
  • 1fr equal to 100% to fill up the Grid row

Sizes follow, with min / max numbers in cells, I stay in px for simplicity

Viewports: →320px <= Mobile >= 639px640px <= Tablet >= 1119px1120px <= Desktop >= 1679px1680px <= Desktop wide >= 1680px+
Items in List:
1100% / 544px352px / 544px352px / 448px352px / 448px
21-2 per row: 320px / max1fr (100%~=639px), wrapped22rem 2 per row22rem22rem

Developer notes

Best user experience with use of :has which is slightly less supported than display: grid, we need both in combination.
The support difference seems negligible though, see comment below.

QA notes

Given the selector behavior of :has featuring selectors, please ensure that you delete items from DOM and don't rely on display:none to test 1, 2, or 3 items. Instead duplicate an item/a card or delete/remove it with DOM inspector. Otherwise the rendering would mislead and not represent real rendering.

BDD

Feature: Responsive Reading Lists grid layout

  Scenario: Viewing Reading List with different item counts
    Given I open Special:ReadingLists
    When the grid displays 1, 2, or 3 saved items at various viewport sizes
    Then cards remain left-aligned
    And grid gaps remain consistent at 16px
    And the card layout auto-fills space according to the number of items and screen width

  Scenario: Viewing Reading List with many items
    Given I have 4 or more Reading List items
    When the page is resized across viewport ranges
    Then a maximum of 4 cards per row are displayed
    And card alignment and spacing remain consistent across breakpoints

Test Steps

Test Case 1: Verify responsive grid layout for 1–3 items

  1. Open Special:ReadingLists and ensure 1–3 cards are present (use DOM delete/duplicate for accuracy).
  2. Resize browser window through mobile, tablet, and desktop breakpoints.
  3. AC1: Cards remain left-aligned at all viewport widths.
  4. AC2: Cards auto-fill available width according to viewport size.

Test Case 2: Verify 4-card layout limit

  1. Ensure 4 or more cards exist in the Reading List.
  2. Resize browser window across all viewport ranges.
  3. AC4: No more than 4 cards appear per row.
  4. AC5: Alignment and spacing remain visually consistent across viewports.

QA Results - Beta|Prod

Acceptance criteria for done

  • Left align in these causes instead of widening the gap

Event Timeline

Volker_E renamed this task from Bring Reading Lists sub-grid in certain viewport ranges and item combinations to design to Bring Reading Lists sub-grid in certain viewport ranges and item combos (<3 items) to design.Oct 20 2025, 10:00 PM
Volker_E claimed this task.
Volker_E triaged this task as High priority.
Volker_E updated the task description. (Show Details)
Jdlrobson-WMF set the point value for this task to 2.Oct 21 2025, 5:23 PM
Jdlrobson-WMF moved this task from Incoming to Ready for sprint on the Reader Experience Team board.

On "modern" vs "older" browser behaviour for the solution of 1 saved page card avail for newcomers with :has(): The modern variant would use https://caniuse.com/?search=%3Ahas() with 93.32% users vs just relying on Grid default https://caniuse.com/?search=gap with 95.58%. Note these are caniuse stats and not Wikimedia stats, but they give us an estimation handle.
And we're talking about an impact for this difference on desktop only (so ~40% of our users) and only when equal to 1 or 2 pages are saved. I think that's negligible.

SToyofuku-WMF subscribed.

Katie to review patch once it's ready

Change #1199533 had a related patch set uploaded (by VolkerE; author: VolkerE):

[mediawiki/extensions/ReadingLists@master] styles: Fix low items (<4) grid layout behavior

https://gerrit.wikimedia.org/r/1199533

Volker_E renamed this task from Bring Reading Lists sub-grid in certain viewport ranges and item combos (<3 items) to design to Bring Reading Lists sub-grid in certain viewport ranges and item combos (1, 2 or 3 items) to design.Oct 29 2025, 10:45 PM
Volker_E updated the task description. (Show Details)
SToyofuku-WMF updated Other Assignee, removed: aude.

more phab stalking ignore me 😇

Reedy renamed this task from Bring Reading Lists sub-grid in certain viewport ranges and item combos (1, 2 or 3 items) to design to Bring Reading Lists sub-grid in certain viewport ranges and item combos (1, 2 or 3 items) to design.Oct 30 2025, 4:17 PM

@aude caught an issue with min-width of 22rem on our smallest supported viewport of 375px. I've amended the patch to go with 20rem for now.
For completion my response on patch:

Thanks for catching this, even though I've made this a point in the lookup table on task, this slipped in the final implementation.

I've gone ahead and reduced the minimum to 320px. Nonetheless I think there might be design call for increasing this again on wider viewports. With that we could go back and go not for a minmax on mobile, but a 1fr and card max-width to simplify.
I don't want to touch this construct on this very specific issues for getting the patch out in production though anymore, as it's an edge case in the otherwise fine rendering.

Change #1199533 merged by jenkins-bot:

[mediawiki/extensions/ReadingLists@master] styles: Fix low items (<4) grid layout behavior

https://gerrit.wikimedia.org/r/1199533

The grid is working well. The issues mentioned in this ticket are fixed.

There is a new issue I am seeing where we are seeing 5 columns instead of max 4 columns.

Screenshot 2025-11-04 at 1.38.35 PM.png (888×3 px, 573 KB)

Change #1203128 had a related patch set uploaded (by VolkerE; author: VolkerE):

[mediawiki/extensions/ReadingLists@master] styles: Fix `max-width` for 4 collection items and more

https://gerrit.wikimedia.org/r/1203128

Change #1203128 merged by jenkins-bot:

[mediawiki/extensions/ReadingLists@master] styles: Fix `max-width` for 4 collection items and more

https://gerrit.wikimedia.org/r/1203128

Test Result - Prod

Status: ❌ FAIL
Environment: beta/enwiki
OS: macOS Tahoe 26.x
Browser: Chrome Canary (latest as of test date)
Device: MS
Emulated Device: NA

Test Case 1: Verify responsive grid layout for 1–3 items

  1. Open Special:ReadingLists and ensure 1–3 cards are present (use DOM delete/duplicate for accuracy).
  2. Resize browser window through mobile, tablet, and desktop breakpoints.
  3. AC1: Cards remain left-aligned at all viewport widths.
  4. AC2: Cards auto-fill available width according to viewport size.

1040px

screenshot 8.png (825×1 px, 153 KB)

2500px

screenshot 7.png (862×2 px, 181 KB)

Test Case 2: Verify 4-card layout limit

  1. Ensure 4 or more cards exist in the Reading List.
  2. Resize browser window across all viewport ranges.
  3. AC4: No more than 4 cards appear per row.

See AC5, As mentioned in T407516#11341637, there are 5 cards across in wide viewports.

  1. AC5: Alignment and spacing remain visually consistent across viewports.

screenshot 6.png (865×3 px, 304 KB)

Edtadros updated the task description. (Show Details)

Change #1204695 had a related patch set uploaded (by VolkerE; author: VolkerE):

[mediawiki/extensions/ReadingLists@master] [POC] styles: Another fix attempt for 5 items wrapping issue

https://gerrit.wikimedia.org/r/1204695

With a bit more coding and testing, I'd suggest to delay on further customization to later on before the wider launch.
My POC patch is showing the same Vector flexibility issues on top of the items that are already hunting us in the relatively workable status now.
Problem is as soon as the pinnable menu items are put into viewport, there is an overlap of the 4 item only RL with the menus.
It just costs too much code to refine this already heavily engineered solution further, therefore it seems better to keep it simpler and without this change for now.
My proposal would be to not put further engineering complexity in this relative edge case and instead think about making our lives easier by exploring RL special page not featuring pinnable menus.
[Partly repeated from chat]

Change #1204695 abandoned by VolkerE:

[mediawiki/extensions/ReadingLists@master] [POC] styles: Another fix attempt for 5 items wrapping issue

Reason:

Not working in all UI features in Vector 2022, will possibly be picked up in future in-production rollout again

https://gerrit.wikimedia.org/r/1204695

The grid is working well. The issues mentioned in this ticket are fixed.

There is a new issue I am seeing where we are seeing 5 columns instead of max 4 columns.

Screenshot 2025-11-04 at 1.38.35 PM.png (888×3 px, 573 KB)

@Sneha - when checked on wmf.3, I observed the issue only for Vector Legacy skin, not for Vector (2022). The issue seems an edge case ( see also the comment https://phabricator.wikimedia.org/T407516#11368953).

I am adding Verified tag to this task and updating the status of this task in T409650: Verify 1.46.0-wmf.2 deployment as Passed.

@Etonkovidova thanks for noting this... we had opened a separate ticket for this T409334. However, at the time due to complexity we decided to not fix 5 column because it was only happening at a wide size. We had decided to sign this off and revisit later. So I would consider a 5 column as a non-issue for now.