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

Site Editor: <style> elements in groups complicates CSS targeting #30500

Closed
andersnoren opened this issue Apr 5, 2021 · 5 comments · Fixed by #32083
Closed

Site Editor: <style> elements in groups complicates CSS targeting #30500

andersnoren opened this issue Apr 5, 2021 · 5 comments · Fixed by #32083
Assignees
Labels
CSS Styling Related to editor and front end styles, CSS-specific issues. [Status] In Progress Tracking issues with work in progress

Comments

@andersnoren
Copy link

andersnoren commented Apr 5, 2021

This one was tricky to search for, so apologies in advance if this has already been discussed somewhere. If it has, feel free to link to it and close this issue.

The Site Editor outputs inline <style></style> elements with layout styles after group blocks, like this:

image

(This section has two nested group blocks: an outer wide group with a background, and an inner group with "Inherit default layout" checked to center it within the outer group and match its width to the content width.)

I frequently remove the bottom margin of the last descendant of certain blocks, like the group block, to keep the inner spacing even. However, with the <style> element appended to the bottom of the element, I can't target the last descendant using .wp-block-group > *:last-child. The result is that the outer div has more spacing in the bottom than in the top, as you can see in the image (the extra space beneath the button). I could target .wp-block-group > div:last-of-type, but that would hit the last div in the group even if that div is followed by other, non-<style> elements.

Edit, side note: The style element is included in the Block Editor as well, but prepended instead of appended, so in the editor, > *:last-child works but > *:first-child doesn't.

What is your proposed solution?

The only solution I can think of is to move the <style> elements out of the groups and collect them somewhere else, but I'm assuming they have been put where they are with good reason, so this is mostly a heads-up that it will complicate certain CSS targeting.

Edit: See comment below for a suggestion on a different solution.

@annezazu annezazu added [Feature] Full Site Editing CSS Styling Related to editor and front end styles, CSS-specific issues. labels Apr 5, 2021
@andersnoren
Copy link
Author

I've thought a bit more about this, and it would be possible to work around the <style> element if it was added to the beginning of the .wp-container-[xxx] wrapper instead of to the end, with the added benefit that it would match the behavior in the block editor (where it is added to the beginning of the wrapper already).

If the <style> element was prepended, like in the block editor, you could target the first non-<style> descendant like this:

[class*="wp-container-"] > *:first-child,
[class*="wp-container-"] > style:first-child + * {}

...which sure isn't pretty, but works.

image

@aristath
Copy link
Member

aristath commented Apr 6, 2021

If I understand correctly the issue is that .block-group > *:last-child doesn't work as expected?
Would .block-group > *:not(style):last-child work? 🤔

@andersnoren
Copy link
Author

If I understand correctly the issue is that .block-group > *:last-child doesn't work as expected?

Yeah. Groups, and any container block (group, cover, column etc.) that ends with a group with Inherit default layout checked in the layout settings. The <style> is added directly after the group with that setting checked. (I think group is the only block that has that setting.)

*:not(style):last-child will hit the last child if the last child isn't a <style>, but if the last child is a <style>, it won't hit anything.

@ellatrix
Copy link
Member

I completely agree. I'll look for a solution.

@ellatrix
Copy link
Member

Solution in #32083.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CSS Styling Related to editor and front end styles, CSS-specific issues. [Status] In Progress Tracking issues with work in progress
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants