The release ZIP for this PR is accessible via:

https://wcblocks.wpcomstaging.com/wp-content/uploads/woocommerce-gutenberg-products-block-7000.zip

Size Change: +26 B (0%)

Total Size: 871 kB

_{compressed-size-action}

I’m wondering if we can use inherit for text so we don’t need to use the inline style?

@dinhtungdu I think setting it to inherit would give it a dark text in most cases, which would not be readable against the default background overlay.

That seems to be the reason the inline style was implemented here to begin with - to ensure the white text over the overlay, as some theme styles (i.e., Storefront) were potentially interfering.

Those defaults are taking precedence over the styles from the Site Editor - if we removed the defaults (either in the settings or on the block in the admin) the site Editor styles would be applied.

There’s a bit of a tradeoff here - we either ensure that the active theme doesn’t override the default block styles or we have closer to the behavior we’d expect in the Site Editor.

I would maybe lean towards reverting/removing the inline style and leaving it up to the theme to make sure it’s not overriding the blocks. In the case of Storefront, this only occurs in the editor but renders properly on the frontend.

We could also add a style in the editor stylesheet for these blocks to slightly increase specificity there (.editor-styles-wrapper .wp-block-woocommerce-featured-product, for example). But that can only go so far until you end up with selectors that are more specific than the Site Editor and in the same position we’re in with the inline styles.

In either case, I would expect the settings on the block to override the settings coming from the Site Editor or any defaults, which is what happens.

cc @sunyatasattva

We’re removing duotone entirely. Is that expected?

@dinhtungdu yes, that was the idea. I do think some additional discussion is needed here before concluding/merging, however.

I noted this on the corresponding issue but I should have reflected more clearly here as well.

Just want to note that the Global style for the Featured Category block works with trunk if Gutenberg is activated, so I have to test without Gutenberg.

Great point! If I’m understanding properly, however, I’m seeing the opposite. I get the following:

• The Global Styles do not work at all for the Featured Items blocks (in the Editor or the frontend) on trunk with the latest version of the Gutenberg feature plugin activated.
• On this branch, with the latest version of Gutenberg active, the Global Styles are working in the admin but not rendering to the frontend. This is also the same behavior on our other blocks, as reported here (see screenshots below).

Mini Cart:

Editor	Frontend

Filter Blocks:

Editor	Frontend

So that all being said, I still lean towards removing duotone entirely.

These are the only blocks currently using the feature and, since duotone is experimental and not present in WC Core, removing it won’t have an impact on anything that’s been released and it will resolve the issue with the WC Blocks feature plugin.

This brings us back to the original Issue reported by @gigitux. With the latest version of Gutenberg active, the problem still seems to be present. We may want to reopen this.

As noted in my findings here, it does not seem to be related to the block class name. Adjusting the target classname via __experimentalSelector does not appear to solve the issue.

I’d love to hear your thoughts on the above!

Cc @Aljullu

Tested trunk one more time and I found very strange behavior:

• Without Gutenberg, the global style doesn't work in the Site Editor but works on the front end.
• With Gutenberg, the global style works in the Site Editor but doesn't work on the front end.

Also, it's not very clear to me why __experimentalDuotone cause the issue, can you show me the logic/lines of code that causes the issue?

Also, it's not very clear to me why __experimentalDuotone cause the issue

@danielwrobert, as you already mentioned in #6988 (comment), __experimentalDuotone change the HTML structure for the block in the editor. So I think the best take here is to remove the duotone support, but we should create an issue to explore why it affect the block markup structure and how to make it work with our block. The wc-block-featured-category class should always be in the same div with wp-block-woocommerce-featured-category IMO, both in the editor and on the front end.

Thanks, @dinhtungdu!

As discussed on our chat, the next steps from here are to investigate / report on the following things:

1. Why isn't __experimentalDuotone working, as expected? We'll likely need to open an issue on the Gutenberg repo.
2. Why aren’t styles being applied to our blocks on latest Gutenberg? We may want to reopen the original issue reported here. This also seems to be an issue on the GB side - for example, the issue is present with Jetpack blocks as well. See Slack thread for additional context/details (p1661951466771189-slack-C02SGH7JBGS).
3. Normalize the way we apply class names to blocks, if possible / necessary.
4. Address the color issues on Featured block that were mentioned above - i.e., should we be solve problems in Themes that should be handled in Themes?

Also see comments on #6988 for additional testing details.