Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change the priority of the block supports styles #37593

Closed
wants to merge 1 commit into from
Closed

Conversation

scruffian
Copy link
Contributor

Description

When we output CSS for block supports (for example link color), the parent block CSS is output after the child block. This is the opposite of what is expected, since with CSS inheritance the child block should take priority, as happens in the editor.

The solution that I've gone with here converts the block to a string, and then counts how many innerBlocks are inside it. We use this count to increase the priority at which the CSS is added to the footer. Therefore the more innerBlocks a block has, the earlier the CSS is added. This should ensure that the CSS for the inner blocks is always added later.

I tried to find a Gutenberg function that would tell me how many innerBlocks a block has, but I couldn't find one. The idea to convert the block to a string and the count the instances of innerBlocks feels like a bad code smell, but it is also much more efficient and simple than iterating arrays.

Other solutions I considered and rejected:

  1. Reverse the order that blocks are rendered - so we render parents before children
  2. Store all the CSS in a global variable, and prepend new CSS to is, so the order is reversed, and then append it to the body once all blocks are rendered.
  3. Use a global variable to count the number of CSS rules we are adding and decrease the priority of each.

I think the solution I have here is better than any of these, but there might still be a better one!

How has this been tested?

See #37582 for comprehensive instructions

Screenshots

See #37582

Types of changes

Bug fix (non-breaking change which fixes an issue)

Checklist:

  • My code is tested.
  • My code follows the WordPress code style.
  • My code follows the accessibility standards.

@scruffian scruffian added the Global Styles Anything related to the broader Global Styles efforts, including Styles Engine and theme.json label Dec 22, 2021
@scruffian scruffian self-assigned this Dec 22, 2021
@oandregal
Copy link
Member

The core issue here is that the styles aren't enqueued/rendered in the order they appear in the DOM. Can we fix that instead?

1 - Reverse the order that blocks are rendered - so we render parents before children
2 - Store all the CSS in a global variable, and prepend new CSS to is, so the order is reversed, and then append it to the body once all blocks are rendered.

I'd like to get an understanding of these two approaches before going down the route of this PR. Though I'd consider 2 a hack if we can't make sure blocks are rendered from top to bottom (and inner blocks rendered after their parents).

@scruffian
Copy link
Contributor Author

Closing in favour of #37728

@scruffian scruffian closed this Jan 5, 2022
@scruffian scruffian deleted the fix/37582 branch January 5, 2022 22:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Global Styles Anything related to the broader Global Styles efforts, including Styles Engine and theme.json
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants