-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Container Style Element Breaks Expected CSS Selectors #36053
Comments
I have a similar issue with styling the backend (instead of the front end), which demonstrates that Gutenberg has not much respect for + selector styling. Before continuing about this, let me say with respect for the dev team: we should probably have patience and wait until most of the core features of Gutenberg are finished, so that they can clean the HTML on back and front-end bit more, because I'm sure they know and are working with some temporary solutions. What I can't wrap my head around is this; Whenever an align (wide/full) is added to a block, Gutenberg editor wraps a totally new container around the whole block (wp-block[data-align='full'), which destroys most of the styling patterns (which worked beautifully and in sync with front-end). The most annoying is that this container exists in the back-end, but not in the front-end. Uck! What's wrong with just adding an alignwide/full class to the block itself? Theme builders can at least write proper CSS to handle this (and other custom block style patterns). What is done now makes no sense to me. What works on the front end should work the same on the backend (in terms of CSS!). Not only for the user, but also for the developers/front-enders. I've not heard, experienced, or read anywhere that using a CSS + selector to control margins based on block contents (.has-background, is-style-large, alignwide ) is bad practice. What IS bad practice, is making us use specific block class selectors in our CSS (wp-block-group, etc) to style patterns of blocks in relation to other blocks. Because we never know which blocks are implemented. What we do know is if it has background yes or no, and if it is also aligned wide or full, and what color, or what block-style. But this has now become inaccessible. |
@Humanify-nl there's a good discussion at #33142 related to problems the |
Just ran into this problem again with the |
I believe the expectation is that the global spacing, like the margin in the example, is also be handled by theme.json. |
For folks running into this, a current workaround for the adjacent alignwide blocks is to do this:
There is not an equivalent workaround for @carolinan Thanks for your response. It makes me wonder about a lot of assumptions for
Unless the plan is to eventually make all editor features that can be controlled with And I will also add that this issue and several others (#33374) around assumptions made once |
This was resolved in WordPress 5.8 +/- .1 and is no longer an issue. |
It appears that WordPress 6.3 has reintroduced this issue of adding The most common use-case (I think) is the This block markup:
…produces this editor html…
|
This also appears to be affecting the removal of block gap margin on the first block. Relevant changes: 9c5ce7e Those styles do not apply because there are |
Adding an observation I don't understand. In a fairly complex Pattern I have, I'm seeing seven |
Thanks for reopening this issue @mrwweb! I'm not too sure of the cause, but one thing I noticed that seems to be consistent with what you observed about inserting a pattern is that if I have an existing post with a bunch of Group blocks and then go to make changes to their layouts, then the 2023-08-21.15.55.49.mp4The style tags used by layout, position, and element block supports within the editor use a portal so that the tags should be inserted to the bottom of the document, but it seems that somewhere along the way something has affected the ordering once additional blocks get inserted. I imagine the expected behaviour is that the portal for outputting |
I have a potential fix ready for review over in #53859 |
Description
I've started trying to use
theme.json
which triggers new layout tools for Group blocks. Among these are an inlinedstyle
element immediately following the Group block:This breaks what has become a really helpful theming technique for CSS Selectors:
This worked with the old markup that would be this:
It no longer works because the markup is now:
Step-by-step reproduction instructions
.wp-block-group + * { background: red !important; }
Screenshots, screen recording, code snippet
No response
Environment info
WordPress 5.8.1, no Gutenberg plugin, traditional theme with theme.json file
Please confirm that you have searched existing issues in the repo.
Yes
Please confirm that you have tested with all plugins deactivated except Gutenberg.
No
The text was updated successfully, but these errors were encountered: