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: jameskoster <[email protected]>
Co-authored-by: ntsekouras <[email protected]>
Co-authored-by: youknowriad <[email protected]>

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

Nice work here :) This had regressed a few times in the past already (hover styles mostly)

Size Change: +87 B (0%)

Total Size: 2.42 MB

_{compressed-size-action}

There is a trade-off with this approach; if a DataViews instance is placed in a container with no background color (or a transparent one) the inheritance will fail. Perhaps we should add a note to the documentation about this?

Can't we at least apply a white background color to .dataviews-wrapper as the default? We're experiencing this issue with Storybook, so I thought the behavior was an unintended bug until I found this PR.

https://wordpress.github.io/gutenberg/?path=/docs/dataviews-dataviews--docs

Can't we at least apply a white background color to .dataviews-wrapper as the default?

If we do that then it won't be possible for DataViews to inherit the background from the container it's placed in (which was the whole purpose of this PR 😅).

Agree we should fix Storybook though, maybe the story just needs an update to wrap the DataViews instance in a container with a backround?

If we do that then it won't be possible for DataViews to inherit the background from the container it's placed in

I see, so it's possible that the background will be applied to a parent container of the dataview-wrapper.

maybe the story just needs an update to wrap the DataViews instance in a container with a backround?

Yes, I think that's fine.

Agree we should fix Storybook though, maybe the story just needs an update to wrap the DataViews instance in a container with a backround?

Isn't there a way to fallback to white though or something? I think DataViews should just work regardless of where you put it basically (ideally).

Isn't there a way to fallback to white though or something?

As far as I know it's not possible to do this with css. Maybe there's another way?

Apparently our only solution for an automatic behavior is JS

getComputedStyle(parent).backgroundColor;

and store this maybe in a local CSS variable to use across the board in dataviews.

Alternatively, we could use a CSS variable and ask folks to provide it.

Alternatively, we could use a CSS variable and ask folks to provide it.

To me this seems like a simple and clear solution. It might look something like this:

.dataviews-footer {
	background-color: var(--wp-dataviews-background, #fff);
}

I did think about a CSS variable. It works, but wouldn't it require all container components (e.g. Card) to define --wp-dataviews-background? Otherwise we're back at square one (white background instead of inheriting)?

Cross-awareness of components doesn't feel great to me.

This is starting to feel a bit related to the conversation in #72336.

I suppose we could go in the opposite direction and say that DataViews always has a white background (the whole thing, not just the sticky elements).

With one eye on:

• The admin theme and token work (@wordpress/theme)
• Admin pages where DataViews might appear inline (e.g. settings)
• Other layout tweaks we have in mind (Site Editor: Utilise tabs for submenus on DataViews 'pages' rather than drilldown #73251)

That would produce something like this, which honestly seems okay to me: