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.

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

Co-authored-by: enejb <enej@git.wordpress.org>
Co-authored-by: jameskoster <jameskoster@git.wordpress.org>
Co-authored-by: aduth <aduth@git.wordpress.org>
Co-authored-by: fcoveram <fcoveram@git.wordpress.org>
Co-authored-by: jasmussen <joen@git.wordpress.org>
Co-authored-by: mirka <0mirka00@git.wordpress.org>

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

I'm pausing a bit on the added hover state. From the papertrail I see the motivation for adding it, and the circle is not an offensive visual. It just seems designwise like a one-off: do we have a vernacular for hover states that this can tap into? At present some have a gray hover style, some only colorize the text blue, some have a light blue style, and there's no language I can find that suggests a radius much less a circle. Should we have hover states on inputs? ToggleControls? Radios?

I don't know it's a blocker, I just also don't know that we need to have that hover state from the get-go, it seems fine to only increase the clickable area, and not do anything else.

The main thing I want to avoid is that we end up with still more bespoke hover styles, and then a future task to clean it all up if we find out a new design for it.

But if you all feel strongly about this circle, no blockers from my end. Nice work, and thanks for the ping.

Styled hover states for inputs are really helpful indicators of interactivity and make the UI feel more responsive. So my preference would be to add this feature with a hover style if possible, and iterate to refine if necessary.

A potential alternative to the fully-rounded target would be to use a shadow so the target inherits the radius from the checkbox:

For me the question is less about whether to have a hover style, or even what it looks like, it's rather that we have some idea of what do our hover styles look like in general, so we don't add even more treatments into the mix.

I think it's kind of unavoidable that the checkbox will have a fairly unique treatment though because it's the only component that has a larger click target than the visible element. The only existing style I could think to mimic is the handle in range control. Maybe this would work:

Those all look okay enough to me, the point remains though, the color, shape, transition, opacity, all of those are values that would be good to systematize so that we have a catalog of materials to tap into. E.g. my point around radio and toggle feel valid here too: why just this one, and not all of them? And I'm still unconvinced we need the hover style at all: the win here is the bigger click target, and that is indicated by the hand cursor. Similarly you can click the label next to the checkbox, that doesn't have a hover style despite toggling it. And finally, what does this look like in DataViews, where the entire row has a hover style, does it conflict with it or do they blend in?

All of those are solvable problems, and although it may read as a strong opinion, I assure you it's not. While I may have a preference going in one direction, if we feel confident that the code is clean and easy to update if we do go back and systematize hover states at a later time, then we can move forward.

I agree with Joen that we don’t need to style the hover. Improving the target area to meet the minimum size is a win, but the current behavior seems to meet the requirements.

It also worries me how this works in DataViews. In the current heuristic, the row’s gray background suggests which content will be selected, but in this approach, it feels odd to set the pointer over the checkbox label without modifying it.

and that is indicated by the hand cursor

It's not clear we'll use the hand cursor forever. I've seen it mentioned elsewhere that this cursor should be reserved only for hyperlinks. With very few exceptions interactive components should inherently indicate hover state.

I am happy to disagree and commit though. We can add the hover styling later/separately.

I also have concerns with adding a visual hover style like this. Checkboxes tend to be used in many different contexts, for example floated on top of an arbitrary image, or placed within a pill-like border with its label. The more prominent the hover style, the more difficulties we're going to have reconciling with the different contexts.

What gives me even more pause is the stated motivation (#73146) for the increasing of the click target:

checkbox are sometimes hard to click on desktop since if you miss just by a little bit you loose your selection and have to start all over again.

A few extra pixels of click target buffer is not going to save me from the frustration of having to start over because of a misclick. Could we maybe look at this root problem as well? Why does clicking a DataViews row make the checkboxes behave like a single selection mechanism all of a sudden? Either a row click doesn't affect the checkbox state, or it acts identically as a direct checkbox click. No?

I think the WCAG 2.5.8 Target Size (Minimum) guideline was another motivation for this change. But on closer inspection I wonder if DataViews is covered by the spacing exception:

Undersized targets (those less than 24 by 24 CSS pixels) are positioned so that if a 24 CSS pixel diameter circle is centered on the bounding box of each, the circles do not intersect another target or the circle for another undersized target;

I suppose it depends on whether row-clicks in table layout, or the thumbnail-clicks in grid layout count as 'another target'. My feeling is that they do, and consequently we should aim for a 24px click target (regardless of hover styles). But I recognise my interpretation could be wrong 😅 WDYT?

whether row-clicks in table layout, or the thumbnail-clicks in grid layout count as 'another target'.

I think it definitely does count as another target, because it behaves differently. And what I don't understand is why it has to behave differently. Why would a row click behave like a single select, when checkbox clicks behave like a multiple select? Not only is that unpredictable, that's exactly what's making a tiny misclick be so potentially destructive.

It isn't even consistent with DataViewsPicker, where a tile click and a checkbox click do the same thing. Am I missing some context?

For the purpose of this PR, I think increasing the target size sounds the safer path. But I'm curious about the rationale for the behavior in DataViews and DataViewsPicker. I don't know the context of how it began.

Increasing the click target works in favor of this specific quirky DataViews interaction only because clicking outside of the target is the destructive mistake. What if the quirky behavior happened to be reversed: clicking inside of the checkbox is the single selection behavior, and thus destructive. Then increasing the checkbox click target would make this DataViews interaction worse 😅

That's why I don't think increasing the click target universally is a logical fix for these consumer-level UI quirks. It may slightly improve things in some cases, but will slightly worsen things in the opposite cases.

Oh I see it now. Sorry for not understanding the problem.

Now after interacting with the component in a sample site, I agree there are two pain points:

1. The same element behaves differently: Clicking a row selects the row, but clicking a checkbox selects the row and also allows selection of more rows.
2. The behavior is inconsistent in Grid: Clicking on the grid item area doesn't select the item.

With that in mind, I’m drawn to select the row only from the checkbox.

I might be missing some context, but having a single affordance simplifies the heuristic and aligns better with the primary action set in both the entry title and actions. The current use of DataViews in admin mainly serves as a stage to trigger entry-related actions rather than making changes in multiple entries. This interaction change doesn’t eliminate the bulk feature, but it reduces its relevance based on how the component is used today.

What do you think of this?

With that in mind, I’m drawn to select the row only from the checkbox.

I agree, and this is something @youknowriad has brought up several times recently. The current row-click behavior is just too ambiguous.

DataViewsPicker has a multi-select prop which is a bit confusing because it means we're using checkboxes in a radio context when multi-select is false. I'm not sure why it was built this way 😅

In any case, even if we remove row-click behavior in table layout, we still have an issue in Grid layout where the 16px checkboxes are too small due to the intersection with the thumbnail. Maybe we should open a dedicated issue about that? Increasing isolated checkbox click-target size is only one solution, a simpler approach could be to simply wrap the checkbox in a 24px container...

DataViewsPicker has a multi-select prop which is a bit confusing because it means we're using checkboxes in a radio context when multi-select is false. I'm not sure why it was built this way 😅

Agree. But in the case, and if we agree with removing the row-clicking behavior, it would be easier to spot the single or multi-selection behavior by hiding or showing the checkbox, respectively.

…we still have an issue in Grid layout where the 16px checkboxes are too small due to the intersection with the thumbnail.

True. If the behavior relies solely on the checkbox, then increasing the target area to meet 24px should not trigger misclicks.

Thanks for all the reviews on this PR.

I removed the animation and the new span element.

I made it work with CSS only changes. The checkboxes did not change in size but they are the surface area of the checkbox is larger.

I added the gray background here to show what it looks like.

The regular PR doesn't add such background.

Mobile:

Desktop:

It also means that the area between the label and the checkbox is clickable before this was not the case.

Size Change: +90 B (0%)

Total Size: 2.57 MB

_{compressed-size-action}

I added the gray background here to show what it looks like.
The regular PR doesn't add such background.

Nice, wfm.

To recap, the increased target size is required when the checkbox overlaps another interactive element which the latest changes accomplish. But it leads to a visual quirk... In the screenshot below a click would toggle the checkbox, despite the cursor being visually positioned on the thumbnail.

This is potentially a bit misleading, and why I think some kind of hover style is quite important; it indicates interactivity prior to any clicks.

So how should we proceed here? Add a hover background as designed in #73312 (comment) ?

I don't mind that, and I think the cases where this would cause confusion are few. It feels relatively normal with other UIs, here Gmail.

It's also the case for our icon buttons.

But your point is valid! My (soft) objection to the hover style is situational, it's something we should do at a later time, in a more systematic way, not ad-hoc.

+1 to Joen's approach. I don't think those cases are too common, although Gmail in light mode does show the a hover style.

It still seems a bit strange (imo) to solve one issue by introducing another, especially as hover styles are easy to change. But I agree it's not a huge problem, so I'm happy to merge revisit if that's the preferred approach.

How do we want to proceed with this? Is the design review done?

Do we need anther code review? cc @mirka and @aduth

If Jay chimes in with a strong opinion, I will defer to him as the decider.

If not, let's move forward without the hover background for now, and come back to hover backgrounds at a later time.

I do still think we're trying to fix a problem at the wrong layer.

For example, let's take this standard list of checkbox items. If we extend the click target of each checkbox 8px in each direction, those click targets will actually be overlapping each other. That doesn't make sense.

If we increase the click target like this, we'll also need to increase the clearance between each checkbox to at least 20px, maybe more. Is it really worth this density trade-off, given that this doesn't even really "fix" the original problem with the DataViews?

Indeed, MUI is showing a very large clearance between checkbox items, and a zone of ambiguity in the middle 😄

Thanks for the feedback @mirka !

I do agree with you. I wish the table view behaved more constantly with the other dataviews. For example the way that the grid view works or even when you add specific click areas to the table view you end up in inconsitancies.

I think, only clicking the checkbox should "select" the particular row. Clicking the row should trigger a different behaviour.
In other words it should work also more like the current (wp-admin) tables that exists in the classic post list view.

I also think to make the checkbox more click in the previous version of the table (in wp-admin) is that the whole checkbox cell is a click area.

See this video.

Would it make sense to go and implement this to be work like this in the new Table Dataview?
Can we make this behaviour the default or will we need to make it opt in?

I've heard it mentioned in various channels that the row-click behavior in DataViews table layout is too ambiguous, so I think we should try removing that 👍

But the issue remains in grid layout. If we prefer to fix this at the DataViews layer I think that's fine. I suppose we'd just need to wrap the checkbox in a 24x24px container to satisfy the a11y guidelines.