Size Change: -2.27 kB (0%)

Total Size: 863 kB

_{compressed-size-action}

@youknowriad Yes, that sounds like a good idea. :) I was thinking it might be useful to have some sort of Block.* variant that can be used in the save function. This component could then add the class by default, and it future proofs anything we might want to add in the future.

Something unrelated I'm wondering, why did you go with <Block.* instead of <Block tagName={"something"} as it's a pattern that is widely used in our codebase?

So that it could be passed to e.g. RichText: <RichText tagName={ Block.p } />. This is a bit inspired by react-spring.

They could be seen as enhanced tags. :)

In my testing, floats are not working properly because it seems the width of the figure is always $content-size even if the image is small.

(same for wide and full)

Seems like the breakage is because of these editor styles https://developer.wordpress.org/block-editor/developers/themes/theme-support/#changing-the-width-of-the-editor

We need to figure a new way for these? or appy the wp-block className differently

One potential solution is to extract the styles defining the widths from here https://github.com/WordPress/gutenberg/pull/20656/files#diff-556b1933de5650dc555c469c584accc2R116 and move them to editor-styles.css

another solution would be to rely on CSS variables (but maybe it's too soon for this)

For the className automatically added to save, I've been wanting to remove the automatic addition for some time now to match edit and server. So might we can tie the removal of the magic addition with the lighterBlockWrapper opt-in behavior?

What's the behaviour for server? What do you envision for save? I was thinking of mirroring Block.* in the save function as well, which would automatically have the classes and filtered props etc. What do you think?

I was thinking of mirroring Block.* in the save function as well

This would work, In the server we do nothing, we rely on the block author.

So I've been thinking about this more and we have two possibilities I think:

First approach

To have the following styles in editor styles. Instead of asking theme authors to add this to their editor styles, we could potentially have a CSS transform to generate it from https://developer.wordpress.org/block-editor/developers/themes/theme-support/#changing-the-width-of-the-editor

It's tricky though and there might be things we'll be missing.

.wp-align-wrapper {
	max-width: $content-width;
}

.wp-align-wrapper > .wp-block,
.wp-align-wrapper.wp-align-full {
	max-width: none;
}

.wp-align-wrapper.wp-align-wide {
	max-width: 1100px;
}

Second approach

Apply the wp-block class to the alignment wrapper in the editor. I think it makes sense if we consider that the main/only use-case for this class (why it exists) is to serve the purpose of assigning block widths in different alignment situations. Now, when we do this should we remove it from the block wrapper Block.* too (so it needs to know about the existence of the alignment support, I wonder if it could even be responsible for the alignment support: adding the wrapper...)

What's left is a CSS transform for editor styles to match [data-align="full"] [data-align="wide"] to the new classNames, unless we also keep these data attribute for BC.

I'm leaning towards the second approach with Block.* responsible for the alignment wrapper addition. What do you think?

Closing this PR out as the original issue referenced has closed:

#20650 (comment)

If that's incorrect, feel free to reopen!