WordPress / gutenberg

The Block Editor project for WordPress and beyond. Plugin is available from the official repository.
https://wordpress.org/gutenberg/
Other
10.41k stars 4.16k forks source link

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

Open ciampo opened 3 months ago

ciampo commented 3 months ago

https://github.com/WordPress/gutenberg/assets/1083581/d1ed6a87-a972-47d6-933c-f9fda39038c1

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:

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 commented 3 months ago

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

andrewserong commented 3 months ago

Thanks for the ping! I'll just ping @noisysocks, too, since there was a change back in February (https://github.com/WordPress/gutenberg/pull/59227) that could be related.

noisysocks commented 3 months ago

Yeah these issues sound exactly like the ones I fixed in https://github.com/WordPress/gutenberg/pull/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 commented 3 months ago

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 commented 3 months ago

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)
ramonjd commented 2 months ago

Possibly related