DataViews: Add shift-click range selection

[ntsekouras]

What?

Resolves: #79622

Adds Shift+Click range selection to DataViews, for both the table and grid layouts.

How?

A new hook (useSelectionProps) that layouts can opt into.

Notes

1. A layout passes its data in render order. The model is intentionally one-dimensional as it sidesteps layout-specific ambiguity, like a grid where a range could otherwise be read as a 2D rectangular block. With this opinionated choice the behavior stays predictable and consistent.
2. table layout in trunk allowed Ctrl/Cmd+Click to pass through (e.g. in links). This PR aligns both table and grid layout to handle Ctrl/Cmd+Clic and shift-click only for selection.
3. The anchor is the last item whose selection was directly toggled (a checkbox or Ctrl/Cmd+Click) and it stays put across consecutive shift-clicks, so reversing direction redefines the range from the anchor rather than starting a new one: click 3 → shift-click 5 → shift-click 1 ends up with 1-3.
4. A shift-click never deselects the item it lands on. This matches the file manager (finder) model which was discussed in this PR.
5. A selection can exist without an anchor, e.g. restored from the URL. In that case shift-click extends from the closest selected item, or just selects the clicked one when nothing is selected.

Testing

1. Open a DataViews list (e.g. Site Editor → Pages) in table or grid layout.
2. Play around with Ctrl/Cmd+Clic and shift-click interactions to see the selection updates (added/removed)

Screenshots or screencast

Screen.Recording.2026-07-14.at.4.07.32.PM.mov

Screen.Recording.2026-07-14.at.4.08.02.PM.mov

Screen.Recording.2026-07-14.at.4.08.48.PM.mov

Use of AI Tools

Opus 4.8 and Fable 5 with direction, changes and review

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Unlinked Accounts

The following contributors have not linked their GitHub and WordPress.org accounts: @verofasulo.

Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Unlinked contributors: verofasulo.

Co-authored-by: ntsekouras <ntsekouras@git.wordpress.org>
Co-authored-by: oandregal <oandregal@git.wordpress.org>
Co-authored-by: jasmussen <joen@git.wordpress.org>
Co-authored-by: fcoveram <fcoveram@git.wordpress.org>
Co-authored-by: talldan <talldanwp@git.wordpress.org>
Co-authored-by: simison <simison@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Size Change: +2.73 kB (+0.04%)

Total Size: 7.72 MB

📦 View Changed

Filename	Size	Change
build/modules/content-types/index.min.js	164 kB	+679 B (+0.42%)
build/scripts/edit-site/index.min.js	303 kB	+735 B (+0.24%)
build/scripts/editor/index.min.js	496 kB	+667 B (+0.13%)
build/scripts/media-utils/index.min.js	121 kB	+653 B (+0.54%)

_{compressed-size-action}

[github-actions]

Flaky tests detected in 5c578ba.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/29355264367
📝 Reported issues:

• [Flaky Test] inserts a mention chip that survives saving the note #80226 in /test/e2e/specs/editor/various/block-notes.spec.js

[jasmussen]

I love it. @verofasulo would you be able to take a look at this and see how it feels? I know it's something on your mind.

[fcoveram]

It works great 💖

[oandregal]

One thing I've noticed is that selection is not cleared after changing direction. Reproduce by:

1. Selecting the 5th item
2. Shift-click to select an item >5th (e.g., 10th)
3. Shift-click to select an item <5th (e.g., 2nd)

I expected the 5th item would remain the anchor and so, in the 3rd step, the selection would become 5th to 2nd (clearing the previous selection). Which is how other comparable interfaces work (spreadsheets and file-selection tools):

Screen.Recording.2026-07-13.at.13.58.32.mov

Instead, this is how this implementation works: all items are selecetd. I suppose the issue is that the anchor changes after the 2nd step and 10th becomes the new anchor:

Screen.Recording.2026-07-13.at.13.58.08.mov

[oandregal]

Another little interaction is what happens when all items become unselected. Test this flow:

1. shift-click to select one item (none selected first): one item is selected
2. shift-click to select another item: the range becomes selected
3. shift-click to select the 1st item: all become unselected

From this on, there's an anchor (the 1st item) that is not visible to the user (no selection). Hence, when the user shift-clicks again a range will be selected (as opposed to only the single item like in the 1st step above). See:

Screen.Recording.2026-07-13.at.14.08.26.mov

I'm inclined to either clear the anchor when all items become unselected or maintain the last item selected, like file-selection tools do:

Screen.Recording.2026-07-13.at.14.09.37.mov

[oandregal]

table layout in trunk allowed Ctrl/Cmd+Click to pass through (e.g. in links). This PR aligns both table and grid layout to handle Ctrl/Cmd+Clic and shift-click only for selection.

So, with these changes, the click event (when ctrl/cmd was pressed) would select the items in both table and grid, while before it only selected them in grid (the event would propagate in the table layout, triggering link navigation instead of selection).

The current behaviour makes more sense to me. After checking the relevant PRs (#70891 and #73873), I haven't found any rationale for the previous behaviour, it doesn't seem to have been intentional.

[oandregal]

A related (but not blocking) thought is what happens with the picker layouts. I've noticed that the Cmd/Ctrl-click doesn't work for multi-selection (the only way is to actually click the checkbox) and this PR doesn't add support for shift-click for them either.

This can be be a follow-up but the multi-selection mechanics (both cmd/ctrl-click and shift-click) strike me as something that the picker layouts would benefit from (given they're optimized for selection). cc @talldan

[ntsekouras]

Which is how other comparable interfaces work (spreadsheets and file-selection tools):

For me comparable interfaces are more towards online applications like Gmail or Outlook and they mostly have the same behavior as what I've implemented here. TBH I was focused mostly on Gmail and I think the behavior is identical. That means the anchor always changes to the last clicked item.

expected the 5th item would remain the anchor and so, in the 3rd step, the selection would become 5th to 2nd (clearing the previous selection).

This is same behavior for both Gmail and Outlook.

Screen.Recording.2026-07-13.at.4.34.45.PM.mov

Another little interaction is what happens when all items become unselected. Test this flow:

This is the same result for Gmail, but Outlook keeps the whole selection intact.

---

So, I think it becomes evident that there are different shift+click interaction models and we need to choose what we like more and where to align to more.

Personally I prefer this interaction model (also same with Gmail) but let's see if your comments make @WordPress/gutenberg-design rethink that - because @jasmussen and @fcoveram already liked the current interaction.

A related (but not blocking) thought is what happens with the picker layouts. I've noticed that the Cmd/Ctrl-click doesn't work for multi-selection (the only way is to actually click the checkbox) and this PR doesn't add support for shift-click for them either.

I'd leave @talldan to chime in for this, but I think some things are intentionally different in picker layouts (e.g. keyboard navigation in similar layouts etc.). Even if we wanted something like that though, it should be in follow ups.

[jasmussen]

Ultimately I will defer to you two, however in case it's helpful, here's the behavior I expect: which is the same as it is in Gmail and Drive, or Proton Mail and Proton Drive, or just the MacOS Finder: click a checkbox, hold shift, click another and select the range. Hold Command to select additional items. Is that helpful?

[oandregal]

@ntsekouras I pushed some changes to simplify the prop drilling and make it easier for layouts to use the hook. Happy to discuss/iterate on this.

@jasmussen that's working 👍 the clarifications are around:

• What happens when you change direction once you've selected a range? google & apple (and other apps) use different algorithms. I could learn to use any, but apple's is what I found more intuitive.
• What happens when all items become unselected? The issue here is dataviews: unlike google examples (gmail) or apples (file-selection), there's no indication of the item that is still behaving as anchor.

On the last issue, @ntsekouras: for me, it is not that an item is selected or unselected, I can learn to use any. Rather, the issue is that there's no indication an item would act as an anchor when it is unselected — unlike gmail's (note the focus ring):

Screen.Recording.2026-07-13.at.19.39.42.mov

this is the current implementation:

Screen.Recording.2026-07-13.at.19.37.34.mov

[talldan]

A related (but not blocking) thought is what happens with the picker layouts. I've noticed that the Cmd/Ctrl-click doesn't work for multi-selection (the only way is to actually click the checkbox) and this PR doesn't add support for shift-click for them either.

You should be able to click the entire item in the picker layouts (it works for me in the storybooks). For a multiselection picker, I don't think cmd/ctrl is really needed, it's already the default to multiselect when clicking.

Range selection (shift selection) is a missing feature, would be great to see that added.

[jasmussen]

Ah! Thanks much for the clarification.

google & apple (and other apps) use different algorithms. I could learn to use any, but apple's is what I found more intuitive.

If I understand this correctly it's more of a PC vs. Mac debate, at least as far as selecting text even on Mac it's a little inconsistent. Historically on PC, the anchor is always maintained and you either select upwards and downwards, whereas on Mac, the selection always grows; shift down, or shift up, the range is expanded. I'm personally much in preference of the PC behavior: only grow the +shift selection in one direction. But ultimately I'll defer to you.

The issue here is dataviews: unlike google examples (gmail) or apples (file-selection), there's no indication of the item that is still behaving as anchor.

That's a delicate detail, well captured.

In this case I'd also support the instinct that whether you hold shift while selecting the first item or not, doesn't matter so much. But that once you have multiple items selected while holding shift, and then shift select the first item again, that item remains selected, it just nullifies the range.

None of it super strongly felt, I'll defer to you.

[ntsekouras]

@ntsekouras I pushed some changes to simplify the prop drilling and make it easier for layouts to use the hook. Happy to discuss/iterate on this.

I'm not sure how this simplifies things much. Probably the calculating of selectableIds in the hook is better, although I originally made it like this to avoid passing extra props.

Rest of the changes add a bit more code actually, like the CompositeGrid where we add the same code in the two paths, instead of one before.

I think the old name of the hook is conveying better what the hook does and useSelectionProps is too generic. Maybe we could even rename to something like useModifierSelection, but still in favor of the initial name.

The most important issue with the commit though is that besides the duplication in GridItem, now each grid group handles selection only inside that group - the multi selection between groups is gone. I will revert these related changes.

it's more of a PC vs. Mac debate

@jasmussen for me it's not that and it seems I need to try to clarify more than my previous comment. A file manager (not just in Mac) has selection as its primary interaction, whereas in DataViews we can also can navigate away with a click on the item. Selection is handled through checkboxes and meta clicks (shift/ctrl).

That said, I think we're spending too much energy on something that is subjective (the small details about more complex shift+click interactions) and that we could also change if needed in the future. I'm willing to adjust in order to find a consensus here.

Rather, the issue is that there's no indication an item would act as an anchor when it is unselected — unlike gmail's (note the focus ring):

That's true and this actually stands for any interaction model we choose. I'm not sure how much this will complicate things, but I'll give it a go.

[github-actions]

There was a conflict while trying to cherry-pick the commit to the wp/7.1 branch. Please resolve the conflict manually and create a PR to the wp/7.1 branch.

PRs to wp/7.1 are similar to PRs to trunk, but you should base your PR on the wp/7.1 branch instead of trunk.

# Checkout the wp/7.1 branch instead of trunk.
git checkout wp/7.1

# Create a new branch for your PR.
git checkout -b my-branch

# Cherry-pick the commit.
git cherry-pick 2eca416d45bfba5920b8e70b8759bc4e570ef48c

# Check which files have conflicts.
git status

# Resolve the conflict...
# Add the resolved files to the staging area.
git status
git add .
git cherry-pick --continue

# Push the branch to the repository
git push origin my-branch

# Create a PR and set the base to the wp/7.1 branch.
# See https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-base-branch-of-a-pull-request.

[t-hamano]

See #80105 (comment)

Continuing from #80105, #80254, and #80255, I will cherry-pick this to wp/7.1.

[github-actions]

I just cherry-picked this PR to the wp/7.1 branch to get it included in the next release: 470160b

[t-hamano]

I just cherry-picked this PR to the release/23.6 branch to get it included in the next release: 67984ef