Improve cover z-index solution #66249

renatho · 2024-10-18T15:29:49Z

What?

This is an improved solution for this original PR: #66093

As part of this PR, I also thought of removing this effect that adds the has-modal-open in the editor because that wouldn't be needed for this purpose anymore. But thinking more, I kept it to keep the consistency there between the frontend and the editor.

Why?

To improve the solution and eliminate the dependencies between Cover and Navigation blocks (the class that Navigation adds being used in the Cover styles).

More context starting from this comment in the thread.

How?

It deprecates the current version of the Cover block, changing the order of the elements, and removing the z-index of them.

It continues using the has-modal-open class for backward compatibility (solution introduced in #66093), but when the code is updated it's not used anymore (after the save).

Testing Instructions

Before switching to this branch, add a Cover block to a post.
Inside the cover block, add a Navigation block.
After the previously created Cover block, add another Cover block.
Switch to this branch.
Visit the site in the frontend on small screens and also visit the editor. Open the menu, and make sure it's displayed over the whole content.
Edit something in the post, and save to update the deprecated version of the block.
Check that the frontend continues working properly.

Screenshots or screencast

Screen.Recording.2024-10-14.at.11.28.51.mp4

Since I continued seeing the same result in my tests, I reused the same video from #66093 just to illustrate the tests.

So we don't need to set z-index in all the elements, creating the stacking context for the inner blocks, for example.

renatho · 2024-10-18T15:31:43Z

packages/base-styles/_z-index.scss

 	".wp-block-cover.has-background-dim::before": 1, // Overlay area inside block cover need to be higher than the video background.
-	".block-library-cover__padding-visualizer": 2, // BoxControl visualizer needs to be +1 higher than .wp-block-cover.has-background-dim::before


I'm removing it again because the change discussed here was reverted.

renatho · 2024-10-18T15:33:17Z

packages/block-library/src/cover/save.js

@@ -88,7 +88,8 @@ export default function save( { attributes } ) {
 			'has-custom-content-position':
 				! isContentPositionCenter( contentPosition ),
 		},
-		getPositionClassName( contentPosition )
+		getPositionClassName( contentPosition ),
+		'has-no-zindex-in-inner-blocks'


I didn't like this name, but I couldn't find a better one. I though about a has-natural-elements-order or something like this, but the has-no-zindex-in-inner-blocks seems more self-explanatory about the purpose of this.

Could we avoid the introduction of the CSS class entirely using sibling CSS selectors?

This would also mean that only blocks with both an overlay and media background would need the reordered markup, reducing the number of blocks requiring a migration via the deprecation.

renatho · 2024-10-18T16:38:29Z

packages/block-library/src/cover/style.scss

-			z-index: auto;
+	&.has-no-zindex-in-inner-blocks {
+		.wp-block-cover__inner-container {
+			position: relative; // It needs a position to be on top of the other elements.


Please, look at this property with a grain of salt. I think it won't cause any issue, but if we had an element inside this block with a position absolute, it would be affected.

The next block in the tree with the position relative would be the immediate parent (.wp-block-cover). I don't believe we would have an existing think trusting in the position relative to the .wp-block-cover, but we never know! =P

After a quick glance it seems okay. Once the deprecation and styles are iterated on we can test this aspect after they've settled.

github-actions · 2024-10-18T16:41:53Z

Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

Type-related labels to choose from: [Type] Automated Testing, [Type] Breaking Change, [Type] Bug, [Type] Build Tooling, [Type] Code Quality, [Type] Copy, [Type] Developer Documentation, [Type] Enhancement, [Type] Experimental, [Type] Feature, [Type] New API, [Type] Task, [Type] Technical Prototype, [Type] Performance, [Type] Project Management, [Type] Regression, [Type] Security, [Type] WP Core Ticket, Backport from WordPress Core, Gutenberg Plugin.
Labels found: .

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

github-actions · 2024-10-18T16:41:54Z

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: renatho <[email protected]>

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

renatho · 2024-10-18T16:42:35Z

I'm already opening it for review, but it still has some test issues.

I tried to update the fixtures through npm run fixtures:regenerate, but I received some errors. If someone could explain me what is happening and how I could fix, it would be very helpful to save some time. =)

aaronrobertshaw

Thank you for following up on #66093 @renatho 👍

I've taken this for a test drive. It's coming together well but I did run into a few issues.

✅ Cover z-index behaviour works as expected post migration
✅ Deprecated blocks appear to migrate in the editor
✅ Deprecated blocks still render appropriately on the frontend
❌ After saving the post and reloading, the deprecated blocks don't appear to have been migrated i.e. they retrigger the deprecation. Making an unrelated edit and resaving the post seems to apply the updates the second time around.

Screen.Recording.2024-10-21.at.3.06.58.pm.mp4

In addition to the migration issue flagged above, I've left a few other thoughts as inline comments where applicable.

These include:

We should be able to avoid introducing the new CSS class to the markup by using CSS sibling selectors for both the latest and BC styles.
- This would also mean that less blocks would need to be migrated, perhaps mitigating a tiny bit of the performance hit.
- i.e. only blocks with both the color overlay and an image or video would have their markup changed requiring a migration.
As the original fix is slated for release in 19.6, we could avoid the need to include styles for .has-modal-open for BC reasons.
- I understand the consistency argument but simply including it for no functional reason and setting a precedent for a block in the editor to mess with the document root classes feels like a stretch.
- Happy to hear others' thoughts on that one. My vote is remove it, we can always add it when there is a pressing need.
We need a new fixture to cover this latest deprecation.
All the non-deprecation-related fixtures for the cover block need to be updated to the latest markup structure.
- This is why the fixture regeneration is throwing the error around an unexpected deprecation being run.
After the above fixture updates, regenerating the fixtures should succeed and the result should be something like past deprecation's serialized HTML being updated to the correct structure.

I suspect that in the process of ironing out the deprecation, the bug I noticed while testing will be uncovered and resolved 🤞

@renatho let me know if anything around my recommendations for the deprecation tweaks isn't clear.

aaronrobertshaw · 2024-10-21T05:46:06Z

packages/block-library/src/cover/editor.scss

+.wp-block-cover:not(.has-no-zindex-in-inner-blocks) {	// Shown while media is being uploaded
+	.components-spinner {
+		z-index: z-index(".wp-block-cover__inner-container");
+	}
+}


Do we need to scope this by the proposed CSS class? The old spinner style would result in the same z-index as the inner container, which comes later in the DOM.

At a quick glance, the positioning of the spinner before the inner container is the same on trunk and this PR. In both cases the spinner is rendered beneath the inner container.

aaronrobertshaw · 2024-10-21T05:47:45Z

packages/block-library/src/cover/save.js

@@ -88,7 +88,8 @@ export default function save( { attributes } ) {
 			'has-custom-content-position':
 				! isContentPositionCenter( contentPosition ),
 		},
-		getPositionClassName( contentPosition )
+		getPositionClassName( contentPosition ),
+		'has-no-zindex-in-inner-blocks'


Could we avoid the introduction of the CSS class entirely using sibling CSS selectors?

This would also mean that only blocks with both an overlay and media background would need the reordered markup, reducing the number of blocks requiring a migration via the deprecation.

aaronrobertshaw · 2024-10-21T05:49:14Z

packages/block-library/src/cover/style.scss

@@ -302,3 +292,32 @@ section.wp-block-cover-image > h2,
 		color: inherit;
 	}
 }
+
+// Backward compatibility for v14 deprecation.
+.wp-block-cover:not(.has-no-zindex-in-inner-blocks) {


As noted in the above thread, it could be possible to avoiding needing .has-no-zindex-in-inner-blocks completely.

aaronrobertshaw · 2024-10-21T05:51:39Z

packages/block-library/src/cover/style.scss

+		// Reset the z-index to auto when the body has a modal open. So when the
+		// modal is inside the cover, it doesn't create a stacking context.
+		@at-root .has-modal-open & {
+			z-index: auto;
+		}


If #66093 isn't slated for release until 19.6, could we also avoid these additional styles? I don't think we need to provide BC for a change that hasn't been released yet.

aaronrobertshaw · 2024-10-21T05:52:57Z

packages/block-library/src/cover/deprecated.js

@@ -244,6 +244,157 @@ const v12BlockSupports = {
 	},
 };

+// Deprecation for blocks that have z-index.
+const v14 = {


This deprecation will need a fixture to cover it. Here's an example for an earlier deprecation.

renatho added 2 commits October 18, 2024 11:49

Remove not used variable

31752de

Change the order of the elements to the expected layers order

6673ec1

So we don't need to set z-index in all the elements, creating the stacking context for the inner blocks, for example.

renatho commented Oct 18, 2024

View reviewed changes

renatho added 2 commits October 18, 2024 12:47

Update z-index styles to be applied only for backward compatibility

e5e0c31

Add position relative to keep inner content on the top

e9c5f0b

renatho force-pushed the fix/improve-cover-zindex-solution branch from cccb26d to e9c5f0b Compare October 18, 2024 15:57

Fix spinner position to be over the overlay

6549f1d

This was referenced Oct 18, 2024

Error on multiple clicks in the navigation modal when having a cover block after this #66066

Open

Fix the navigation issue inside cover blocks #66093

Merged

renatho commented Oct 18, 2024

View reviewed changes

renatho marked this pull request as ready for review October 18, 2024 16:41

renatho requested a review from ajitbohra as a code owner October 18, 2024 16:41

aaronrobertshaw reviewed Oct 21, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Improve cover z-index solution #66249

Improve cover z-index solution #66249

renatho commented Oct 18, 2024 •

edited

Loading

renatho Oct 18, 2024

renatho Oct 18, 2024

aaronrobertshaw Oct 21, 2024

renatho Oct 18, 2024 •

edited

Loading

aaronrobertshaw Oct 21, 2024

github-actions bot commented Oct 18, 2024

github-actions bot commented Oct 18, 2024

renatho commented Oct 18, 2024

aaronrobertshaw left a comment

aaronrobertshaw Oct 21, 2024

aaronrobertshaw Oct 21, 2024

aaronrobertshaw Oct 21, 2024

aaronrobertshaw Oct 21, 2024

aaronrobertshaw Oct 21, 2024

		".wp-block-cover.has-background-dim::before": 1, // Overlay area inside block cover need to be higher than the video background.
		".block-library-cover__padding-visualizer": 2, // BoxControl visualizer needs to be +1 higher than .wp-block-cover.has-background-dim::before

Improve cover z-index solution #66249

Are you sure you want to change the base?

Improve cover z-index solution #66249

Conversation

renatho commented Oct 18, 2024 • edited Loading

What?

Why?

How?

Testing Instructions

Screenshots or screencast

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

renatho Oct 18, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

github-actions bot commented Oct 18, 2024

github-actions bot commented Oct 18, 2024

renatho commented Oct 18, 2024

aaronrobertshaw left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

renatho commented Oct 18, 2024 •

edited

Loading

renatho Oct 18, 2024 •

edited

Loading