DataViews: Pass styles to the column.

[StevenDufresne]

WIP/Experiment

What?

This PR is experimental (and naive), allowing consumers to control CSS styles for <td> and <th>.

Why?

<DataView> styles are not modifiable without using CSS overrides that make use of internal component classnames. This is not future-friendly.

What would you want to change them for?

As an example, as a consumer, maybe my mobile container padding is 10px. I should be able to set my DataViews' padding to match.

How?

It utilizes the view.layout property, which already exists to provide styles to <th> and <th>.

Considerations

Magic variables

I've introduced some magic properties to represent the ability to style internal columns like bulk actions.

These are:

• __default__ Applies as base to all columns.
• __primary__ Applies to the Primary column.
• __actions__ Applies to the Actions column.

I don't contend this is the best approach; however, the current code loops through the column looking for style.[column_id]. This makes it work with minimal changes and decent backward compatibility.

Theming

The default layout could be retrieved from a global theming context.

Problems

This works for the table. How do we get consistent padding for DefaultUI... 🤔

Testing Instructions

Testing Instructions for Keyboard

Screenshots or screencast

Before	After

[StevenDufresne]

Just for testing.

[github-actions]

Flaky tests detected in e4cd6b3.
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/18929070381
📝 Reported issues:

• [Flaky Test] should refresh the page when stylesheet loading fails #71722 in /test/e2e/specs/interactivity/router-styles.spec.ts

[p-jackson]

Rather than arbitrary CSS for each column, could we do something more limited with the existing density prop? I think all it currently does is set vertical spacing, but maybe we could use it to tighten up other margins too. I just wonder, since there's a number of components that accept density now, and so perhaps that's the more "accepted" way to make the component tighten up its internals.

I do think the ability to set the outermost margin around whole dataview is different though, allowing parents to set arbitrary inline and block padding pixel values for the padding that goes all the way round the edge seems like a good thing.

[StevenDufresne]

Rather than arbitrary CSS for each column, could we do something more limited with the existing density prop? I think all it currently does is set vertical spacing, but maybe we could use it to tighten up other margins too. I just wonder, since there's a number of components that accept density now, and so perhaps that's the more "accepted" way to make the component tighten up its internals.

For the mobile case, for example, density feels like it could work, but in practice, relying on density for a smaller view creates exactly what you expect: a dense view. In important cases, dense views are not mobile-friendly. Click areas get small, and things start to feel rather tight.

It leaves us with a bit of a dilemma: does density have responsiveness built in, or is responsiveness a second system?

I think we'll move towards a system for responsiveness and a system for density, both likely inherited through context. Context provided via props, or context provided via shared React context.

This PR is early, and it's aggressive. I want to shake out our best guesses with something that works today, so we can see potential dead ends sooner.

[github-actions]

Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

• Required label: Any label starting with [Type].
• Labels found: .

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

[youknowriad]

Is there any perf penalty of this regenerating an object on each render? Maybe not

[StevenDufresne]

Not in what it currently does, but it could if style logic becomes more complex.

[youknowriad]

Approach looks good to me, I'm not sure about the naming itself but I don't have better suggestions.

[jameskoster]

This seems closely related to #72336.

[StevenDufresne]

I opened a CSS first alternative to this #72912. I'm curious what y'all think about that?