Spacing Input Controls: padding/margin overlays out of sync, horizontal margin not being applied

[ciampo]

spacing.input.controls.mp4

While interacting with spacing input controls for another task, I noticed a few unexpected behaviors:

Padding/margin colored overlays out of sync

The colored overlay shown around a block doesn't seem to reflect the value chosen in the control:

• It doesn't show initially, even when going from "None" to "1" (see in the video at 12 seconds)
• the overlay shows a padding being applied even when going back to "None" (see in the video at 20 seconds)
• in general, it looks like the overlay is off by 1 position with respect to the slider (see in the video between 20 and 30 seconds)
• When enabling custom values and changing the value to 0, the overlay still shows a large padding (see in the video at 34 seconds)

Horizontal margin does not get applied

When applying horizontal margin, I moved the slider but nothing happened to the selected block (see video at 1 minute and 9 seconds)

[ciampo]

cc @aaronrobertshaw @glendaviesnz @andrewserong who I know have worked on this area of the project before

[andrewserong]

Thanks for the ping! I'll just ping @noisysocks, too, since there was a change back in February (#59227) that could be related.

[noisysocks]

Yeah these issues sound exactly like the ones I fixed in #59227.

Running the latest trunk locally, I can't reproduce any of the overlay issues you've mentioned. Is there a step I'm missing? Or something about your environment? What browser are you using?

When applying horizontal margin, I moved the slider but nothing happened to the selected block (see video at 1 minute and 9 seconds)

This one I can reproduce. It looks like the margin-left and margin-right values are being overridden by a CSS rule added by the parent block's layout.

Here's the rule in the site editor:

.editor-styles-wrapper .wp-container-core-group-is-layout-203 > :where(:not(.alignleft):not(.alignright):not(.alignfull)) {
  max-width: 565px;
  margin-left: auto !important;
  margin-right: auto !important;
}

And here's the rule in the post editor:

.editor-styles-wrapper .block-editor-block-list__layout.is-root-container > :where(:not(.alignleft):not(.alignright):not(.alignfull)) {
  max-width: 620px;
  margin-left: auto !important;
  margin-right: auto !important;
}

It makes sense that the layout would add margin-left: auto and margin-right: auto to centre-align the blocks, but I'm not sure why they're marked !important, which overrides the margin that the user sets. Is this to do with a recent specificity change? I'm not very familiar with how the layout CSS works.

[aaronrobertshaw]

Is this to do with a recent specificity change? I'm not very familiar with how the layout CSS works.

This has been the case since the introduction of layout supports. I don't think it is related to the CSS specificity changes.

IIRC there has been a lot of discussion about this on various PRs that adopt margin support on blocks mostly because we don't offer "conditional" support yet. We're left with a situation where on a top-level block the left/right margins are overridden but if the block is nested within a block that doesn't define its own layout then the left/right margins are honoured.

[aaronrobertshaw]

Running the latest trunk locally, I can't reproduce any of the overlay issues you've mentioned. Is there a step I'm missing? Or something about your environment? What browser are you using?

Using the latest trunk I tested across the usual browser suspects. The visualizer only appears correctly for me in Safari. It behaves as per this issue in Chrome, Firefox, and Edge.

Safari	Others (FF, Chrome etc)
Screen.Recording.2024-07-08.at.5.01.59.PM.mp4	Screen.Recording.2024-07-08.at.4.57.19.PM.mp4

[ramonjd]

Possibly related

• Sidebar styles tab crashes block when theme has >= 8 spacing values #64270