Gutenberg: Block Alignments Rethinking

[youknowriad]

Current Issues

Alignments in Gutenberg today suffer from several issues, the most important one being the inconsistency between the different block markups.

An image block aligned left/right or center has the following markup

<div class="wp-block-image">
    <figure class="alignleft"></figure>
</div>

but when it has no alignment or wide/full, it has the following markup

<figure class="wp-block-image alignleft"></figure>

Other blocks like buttons, columns, ... use the align support hook which produces the following markup no matter the alignment applied

<div class="wp-block-something alignleft"></div>

This makes it almost impossible to support properly for theme authors without bugs.

There are more or less valid reasons for these differences but instead of going through history, let's try to focus on what we want to support and how we can fix this.

Use cases

Let's assume we want to build a theme that supports all alignments (the most complex case) and all blocks.

We'll most likely have a wrapper for blocks whether it's coming from the theme's template files .entry-content or a group block.

Now, let's take a look at each one of these use-cases and see how to implement them in terms of markup and styles.

Regular Alignment (no alignment)

markup

<div class="wp-block-something"></div>

Note that the class here is not always present (for valid reasons I want to leave out of the current issue)

styles

.wrapper > * {
    max-width: 600px; /* width of the regular blocks */
    margin-left: auto;
    margin-right: auto;
}

The margin technique is needed here because we want to support wide/full alignments at the same time. (see later)

Wide alignment

markup

<div class="wp-block-something wp-align-wide"></div>

(don't mind the different alignment classNames, I'll explain later)

styles

.wrapper > *.wp-align-wide {
    max-width: 800px; /* width of the wide blocks */
    margin-left: auto;
    margin-right: auto;
}

Full-width alignment

markup

<div class="wp-block-something wp-align-wide"></div>

styles

We can decide here to revert the default styles for the regular blocks or update its selector to exclude the full width blocks

.wrapper > *:not(.wp-align-full) {
    max-width: 600px; /* width of the regular blocks */
    margin-left: auto;
    margin-right: auto;
}

Floated blocks

Now, this is probably the most complex case. What we want here is a block that is marked as a float. That way, the following blocks, will wrap it but we also want the floating to be contained in the "regular" width area.

I saw some themes achieving this by applying computed margins to the block wrapper (left or right) and floating the block itself. In fact, that's the only possible technique for blocks using the "align support hook" but this approach is buggy since you can't really float multiple blocks in a row properly.

So what we're going to do is to add an extra wrapper around the blocks (like the image block above), that wrapper will have the regular size allowing us to float its content properly. So we end up with markup like that

markup

<div class="wp-block-something wp-extra-block-wrapper">
    <div class="wp-align-left"></div>
</div>

styles

.wp-align-left {
    float: left;
}

Centered blocks

Theoretically, we can center blocks without extra wrappers but we can also use the extra wrapper technique similar to float blocks to center blocks easily

markup

<div class="wp-block-something wp-extra-block-wrapper">
    <div class="wp-align-center"></div>
</div>

styles

.wp-extra-block-wrapper {
    display: flex;
    justify-content: center;
}

Alternatives

I'm personally not certain if there are other alternatives. Let me know if you have any.

Consequences

What does it mean if we have to implement this proposal:

• Block markup might need to be changed to add extra wrappers when left/right/center alignments are applied.
• Notice that I've used new classNames for the styling of the alignments. The reason for this is that if we use the current class, current themes will break because of the new markup.
• With these updates, the alignments styles become simple enough that I think we can consider adding them automatically to the "theme" opt-in styles. Themes authors won't have to write them, we can just provide good defaults. (This needs to be prototyped/tested though)

Notes

The wide/full widths used above are examples, one idea here would be to rely on CSS variables and allow InnerBlocks to disable/enable/customize the widths per container.

[ellatrix]

So this is more or less what we currently do for the image block, right?

For left/right floating, a slight variation could be:

markup

<figure class="wp-block-something wp-align-left">
    <div class="wp-aligned-content"></div>
</figure>

styles

.wp-align-left .wp-aligned-content  {
    float: left;
}

The benefit of this would be that we consistently have figure at the top level, and consistently have the wp-align-* class at the top level.

In not sure if it would be valuable, but we could consider always adding the extra inner div wrapper. It might not be useful for basic usage, but it could potentially be used by themes if they'd like some more complex positioning. Additionally it gives more consistency across all alignments.

[youknowriad]

The benefit of this would be that we consistently have figure at the top level, and consistently have the wp-align-* class at the top level.

Good idea especially if we decide to go with our own style and separate classNames.

In not sure if it would be valuable, but we could consider always adding the extra inner div wrapper. It might not be useful for basic usage, but it could potentially be used by themes if they'd like some more complex positioning

Same here, I agree, though only for blocks with align support.

[ellatrix]

Cc @jasmussen for feedback. Here's his codepen: https://codepen.io/joen/pen/zLWvrW.

[ellatrix]

Same here, I agree, though only for blocks with align support.

Right, only for blocks that support alignment, but the block would always have the extra div wrapper, regardless of the alignment selected.

[jasmussen]

I absolutely have thoughts on this and thank you for the ping. I will return with a more in depth comment, but overall I definitely agree this is an area where we can make things way better.

[ellatrix]

Another challenge:

When the outer block wrapper (top level element) is not floated, but rather the extra div element within, it would mess up the selection outline and toolbar position. Currently, we're handling this by creating an exception for alignments. In this case, we'd look if there's a .wp-aligned-content element, and use that to position the toolbar and add the outline to. It would we _nice_ if we didn't have to make an exception, but it seems like there's no other way.

[youknowriad]

@ellatrix right I don't see any other way for that one :(

[ellatrix]

@youknowriad Just exploring some ideas... What if we keep/extend alignment in block support, and internally wrap the block in an "alignment wrapper" element, which get automatically added around both the save and edit component?

• No need for the block to implement anything, only add support. No need to add classes, wrappers...
• No need to do any special handling for selection styles and toolbar positioning.

markup

<div class="wp-align-wrapper wp-align-left">
    <figure class="wp-block wp-block-image">...</div>
</div>

[youknowriad]

Sounds interesting, I believe in that case the Block.* wrapper is the internal element right? I wonder if has any impacts on its behavior.

[ellatrix]

@youknowriad No, the Block.* wrapper is still implemented by the block, so in this case:

<div class="wp-align-wrapper wp-align-left">
    <Block.figure class="wp-block wp-block-image">...</Block.figure>
</div>

The wrapper around the block would be added internally to both edit and save output.

I'll quickly explore this idea and see if it's interesting.

[ellatrix]

This is the markup I'm proposing in the last few comments:

No Alignment

markup

<div class="wp-align-wrapper">
    <figure class="wp-block-image"></figure>
</div>

The wrapper could be omitted here, but personally I like the consistency, and it allow themes to create more complex layouts.

styles

.wrapper > * {
    max-width: 600px; /* width of the regular blocks */
    margin-left: auto;
    margin-right: auto;
}

Wide Alignment

markup

<div class="wp-align-wrapper wp-align-wide">
    <figure class="wp-block-image"></figure>
</div>

styles

.wrapper > *.wp-align-wide {
    max-width: 800px; /* width of the wide blocks */
    margin-left: auto;
    margin-right: auto;
}

Full Alignment

markup

<div class="wp-align-wrapper wp-align-full">
    <figure class="wp-block-image"></figure>
</div>

styles

.wrapper > *:not(.wp-align-full) {
    max-width: 600px; /* width of the regular blocks */
    margin-left: auto;
    margin-right: auto;
}

Left/Right Alignment

markup

<div class="wp-align-wrapper wp-align-left">
    <figure class="wp-block-image"></figure>
</div>

styles

.wp-align-left > * {
    float: left;
}

Center Alignment

markup

<div class="wp-align-wrapper wp-align-center">
    <figure class="wp-block-image"></figure>
</div>

styles

.wp-align-center {
    display: flex;
    justify-content: center;
}

[youknowriad]

I like the consistency here. Awesome proposal @ellatrix

[ellatrix]

Question: isn't no alignment the same as centre alignment? If not, what's the difference?

[youknowriad]

It's not for me. no alignment means "left alignment" but not floated. while center alignment is centered.

[ellatrix]

I'm not sure if "no alignment" being left aligned ever worked. And what about right alignment, but not floated?

[youknowriad]

And what about right alignment, but not floated?

It could be a potential alignment but its need is very small. no-alignments is just any regular inline-block or block element. When you put it inside div, it just stays where it is. The difference is that we don't have a div around it because we want to support full/wide.

[ZebulanStanphill]

(In case anyone is confused about floats and wide/full being called alignments, see #19672.)

The max-width + auto margin approach for no alignment will result in a lot of blocks just appearing centered, won't it? If you had an image element with a smaller width than the content width, and you used those styles, it would just end up being centered, wouldn't it?

Themes that implement wide/full widths via negative margins don't have the centered-by-default issue. Instead, of course, they have to deal with the clunkiness of negative margins, which tend to be a pain to deal with, particularly for the full width when trying to account for the scroll bar, which is not taken into account by vw units. (I know from experience. 😒)

Another approach a theme might use is CSS Grid to handle position/alignment, but of course in that context you can't use floats.

It's also worth noting that some WordPress themes use the float left and float right options for a pull-out position, where lots of negative margin is used to take the floated element completely out of the main content column. Perhaps that should be treated as its own separate option in addition to the existing positions/alignments/widths/etc?

As pointed out in #19672, it's important to note that wide/full widths and left/right floats are technically not even alignments in the first place. So perhaps the technical approach for widths vs floats vs actual alignments should be different, rather than attempting to use the same approach for all of them.

[youknowriad]

If you had an image element with a smaller width than the content width, and you used those styles, it would just end up being centered, wouldn't it?

No, I don't think so. the alignment-wrapper will be centered but not its content.

So perhaps the technical approach for widths vs floats vs actual alignments should be different, rather than attempting to use the same approach for all of them.

Treating them differently means you can apply both at the same time, which is not the case for any of these right?

[ZebulanStanphill]

@youknowriad

No, I don't think so. the alignment-wrapper will be centered but not its content.

Would blocks have an alignment wrapper even when not aligned? That seems like a lot of additional markup.

Treating them differently means you can apply both at the same time, which is not the case for any of these right?

I was more thinking along the lines of not having to use a wrapper for width variants like wide/full, or something like that. I think it's fine to keep the options mutually exclusive in the UI. (Though I do think they should each have more descriptive labels like "Stretch to full width" or "Float left" rather than the misleading and generic "Align ___".)

[strarsis]

"No alignment" just means that no alignment is forced, that the defaults are used.
An example: On a RTL-directional page the default wouldn't be left but right.
Also some themes may want to have everything aligned to center as the default alignment - or left, maybe the theme got some decoration on the left side that should be shown more prominently.
Everything that gives the theme designer more freedom and consistency is a good thing IMHO.

[jasmussen]

As I noted yesterday, I wanted to return with a lot of thoughts. But after reading through the conversation, all of it has already been said, and I've simply added some thumbs up here and there. Notably, Ella's outline for how it could work seems very promising, and could form a great baseline to explore from.

To add a small bit of complexity that's important to the discussion, and this touches upon the #19672 ticket that Zeb also mentioned. Right now we are mixing basic floats with CSS for centering, wide and full-wide. The verbiage change outlined there will help; position right for float right, and align right could potentially address Ella's edgecase:

And what about right alignment, but not floated?

But one point of that verbiage change, and the reason to move them into a dropdown, is also to allow potentially for future flex-based alignments, and even multiple positions and alignments at the same time. Such as:

• sticky
• full-height and full-width
• sticky and floated
• pull left and overlap
• pull right and float
• fix to top|right|bottom|left

I'm not necessarily suggesting those as ones we should add to the block editor, perhaps they are added through extensibility.

But there's yet another aspect — for a template that is built using CSS grid, you might have even more complex tools to position a container. Imagine a CSS grid that has 8x8 cells — you could imagine an interface that positions a div in coordinates 2,4 and span 4 cols and 2 rows.

It's very difficult to fully form a picture of what needs of the editor such alignments might entail, but it's healthy to think about it. High level it does seem like the refactor proposed — an extra alignments wrapper around aligned items — will give us a great deal of extra flexibility to handle such cases.

Do you agree?

[youknowriad]

@jasmussen I do think the refactor gives us more flexibility, but I'm not totally certain it will absorb grid positionning... Because in such cases, it's not one or the other, I'm not sure you can say float something to the left but align the next block in the grid. I believe this is better solved by the Grid block or Grid support for Inner blocks, where basically you'd toggle between "Regluar flow" (like today) and "Grid flow".

[jasmussen]

CSS grid is likely something a theme has to opt into, and doing so would enable new alignments and disable others, like floats, agreed. But it seemed prudent to think of the general alignment markup regardless.

[ZebulanStanphill]

Something that occurred to me yesterday is that the block alignment toolbar is a bit weird compared to the text alignment toolbar. In the text alignment toolbar, you can specifically select left text alignment. The block "alignment" toolbar doesn't let you select that; you can only unselect whatever the current option is and use the default, which is usually (real, not floating) left alignment, or right alignment for RTL sites. For completeness, I think actual left align and right align controls should be introduced.

Also, if we go with @ellatrix's proposal, I'd strongly suggest updating the class names according to the discussion in #19672. If we don't do it then, we may not have another chance to fix the ancient issue of the "align__" classes being poorly and inconsistently named.

Something that concerns me about that proposal is whether it would work in every situation where you have inner blocks that have to be a direct descendant of the parent in order to keep the markup semantically correct. Are there any cases where You would have such a parent-child markup relationship (e.g. ul and li) and also want to be able to align each of the children individually?

[kjellr]

Naming + CSS-grid questions aside, I'll just chime in to say that @ellatrix's proposal makes sense. I really like the fact that we'd be consistent about those wrappers — that inconsistency was a pain point while building in Twenty Nineteen's alignments.

With these updates, the alignments styles become simple enough that I think we can consider adding them automatically to the "theme" opt-in styles. Themes authors won't have to write them, we can just provide good defaults. (This needs to be prototyped/tested though)

Also, please yes let's do this.

[phpbits]

Referencing this one : https://github.com/WordPress/gutenberg/issues/19905. Might be the right time to discuss the renaming as well.

[strarsis]

So there are basically two ways for implementing wide and full alignments in CSS:

• Restrict all children of the main container element (> *) that got no alignment classes to a specific "normal" max-width, use different max-width for alignwide and alignfull alignment classes.
• Give the main container element a "normal" max-width, make the wide and full alignment "break out" by using negative margins/transforms.

Only the 2nd technique allows "breaking" out of a nested, width-constrained block.

I guess both techniques have to be used in combination.
There is one specific but often used pattern for group blocks in many themes:
The group block itself should expand to full width while its contents should still be constrained.

[jasmussen]

This ticket might fix #4747.

[paaljoachim]

A user on the Gutenberg plugin support forum wondered how to use a regular width on the Media & Text Block. I told him this: https://github.com/WordPress/gutenberg/issues/20941

Bottom line: He had to deactivate the default Wide width alignment to get regular alignment.
The standard width alignment is hidden. There should be a ui for it.

EDIT:
It could be something like this:

Advantage:
There is an default alignment visible in the UI alignment options popup.
Showing that there is an alignment that starts out as default and the user can then just change to any of the options available.
There is always one alignment selected. One can not turn off all alignments.
As turning off alignment is really outside the consistency in choosing which alignment to use.

The wording as I thought about it is the page content width.

[jasmussen]

Bottom line: He had to deactivate the default Wide width alignment to get regular alignment.
The standard width alignment is hidden. There should be a ui for it.

That's wrong, though:

An argument can be made that we should add a "no alignment" button in the menu.

[ZebulanStanphill]

I agree that there should be a "no alignment"/"default"/"auto" option.

[jasmussen]

Good points. Let's try to move towards a mockup stage for "no alignment" / reset alignment.

Keeping in mind the forward thinking that is expressed in this ticket (ability to have multiple alignments, such as both full wide and full height), and perhaps keeping in mind alignments such as those discussed in #20836, is there a pattern to resetting such alignments that works for both? Perhaps simply a "Reset" button?

[strarsis]

@jasmussen: So this would be like allowing blocks to support multiple block styles but for alignment states.

[jasmussen]

Well not so much multiple styles, though that's interesting on its own. And not all alignments are compatible so we'd need special groups here. You can't add both left and right, for example but you could potentially do full wide and full height or left and sticky. There's a separate conversation on some rephrasings to "position" to help that categorization.

[paaljoachim]

Here is an wireframe idea of selecting two different alignments.

1. User first selects initial alignment of block.
2. Below the grey line. Selects another alignment.

A modified screenshot (and adjusted) from @retrofox stale PR. https://github.com/WordPress/gutenberg/pull/16738

[strarsis]

@jasmussen: Wouldn't be left + right alignment together on a philosophical level the same as center alignment? 😸

[jasmussen]

😉

On a philosophical level, I'd suggest left and right together would mean "stretch to both sides".

[ZebulanStanphill]

With regard to the "full screen" option in #16738, I would prefer if it was changed to a "full (viewport) height" option that could be combined with any of the horizontal options, so you could have a full height + floated left block or a full height + full width block to achieve a full screen effect.

This "full height" option would likely belong in a "vertical positon/alignment/whatever" toolbar/dropdown, separate from the horizontal options.

As for the horizontal options, I'm fairly certain that they are all mutually exclusive, so it's fine to group them all together in the same toolbar/dropdown:

• auto/none/default
• align left
• align center
• align right
• float left
• float right
• wide width
• full width

A vertical toolbar/dropdown could potentially include options like:

• auto/none/default
• align top
• align center
• align bottom
• tall height
• full height

The top, center, and bottom options would essentially just be the same options as the vertical align options on individual Column blocks. These options would usually only be available for blocks in horizontal nested contexts. The tall/full height options, on the other hand, could be made available for a wider variety of blocks, e.g. Image or Cover blocks.

Any one of the vertical options could be used at the same time as any one of the horizontal options.

[strarsis]

Would these alignment options control the alignment of the block itself or the alignment of its content (child blocks)?

[ZebulanStanphill]

@strarsis All of the options in my lists above affect the block itself. That's why I compared the vertical top/center/bottom options to what individual Column (note the lack of "s") blocks have. In the case of those blocks, they make use of the align-self CSS property, which is pretty self-explanatory.

[ZebulanStanphill]

Alignment/position of a block's children is a whole separate matter, and I'm pretty sure no one is discussing that right now. Working out self (block-itself) alignment/position/etc. controls first will probably make figuring out child alignment/position way easier, though.

[ellatrix]

What would you expect a full aligned image in an unaligned group block to look like?

[youknowriad]

@ellatrix This is where I think, the group block should not allow full/wide alignments if it's not itself wide/full alligned. (prop for InnerBlocks to define supported alignments).

A full aligned image in an unaligned group block should show just like a regular image.

[ellatrix]

@youknowriad Ok, that's what I thought as well. Perfect 👍

I'm working on an updated proposal.

[strarsis]

@youknowriad: I must politely disagree here. There are some CSS techniques that allow the "breaking out" of a block even if its parent blocks are all constrained. This may make sense sometimes.
Imagine a group block that got a special background effect and contains other blocks.
One of the group blocks inside should still break out and have wide or full width,
it would be possible using CSS (negative margins and vw stuff).
But when the block doesn't allow wide/full alignment when its parent block is normally aligned,
this wouldn't be possible by the UI although it is visually and technically possible.

[ellatrix]

I don't think that would be compatible with @jasmussen's https://codepen.io/joen/pen/zLWvrW. Wide alignments are restricted to the width of the parent.

[ZebulanStanphill]

@ellatrix Does that mean that, in order to support wide/full alignments, block-based themes would have to use full-width "Post Content" blocks in their post/page templates?

[jasmussen]

To a great extent, if alignments will still involve CSS classes, presumably a theme can do whatever they like with those classes, correct? Including changing what a fullwide block inside a not fullwide group is.

[ZebulanStanphill]

@jasmussen It seems a bit weird to have different behavior for that particular case depending on your theme. I would think that users would view an inconsistency like that as the theme breaking their content. Whatever the behavior for full-width-inside-not-full-width should be, I think we should aim for it feeling consistent regardless of theme. I expect the exact width of "wide" to change depending on the theme; I don't expect wide-inside-not-wide to work in one theme but not the other for no apparent reason.

Unlike the case of the theme having to opt-in to show the wide/full options in the toolbar in general, I don't see any reasonable way to show or hide the wide/full options for nested blocks in not-wide blocks depending on what theme you use... unless you want to add another theme supports flag, and that's a bad idea in my opinion.

[strarsis]

Example CSS for full align that breaks out of width-constrained parent elements: https://www.billerickson.net/full-and-wide-alignment-in-gutenberg/

It boils down to the interpretation of "wide alignment" and "full alignment":

• No width (max-width) constraints.
• Breaks out of parent element width, occupying the whole viewport width.

"Wide alignment" could also be interpreted the same way:

• Wider width (max-width) constraints than normal/default alignment.
• Breaks out of parent element width but doesn't occupy the whole viewport width.

Themes may interpret this differently: A group may be unconstrained by width for some background fx (e.g. red stripe for the whole page width) but still constrain its content width.

[youknowriad]

To a great extent, if alignments will still involve CSS classes, presumably a theme can do whatever they like with those classes, correct? Including changing what a fullwide block inside a not fullwide group is.

For me, classnames should be seen as implementation detail and ideally, themes don't even provide styles for these, it just works. That's better for theme authors because it's simpler and it's better for the editor because it knows semantically what qn alignment means and can decide to change implementation, provide smart features...

[jasmussen]

For me, classnames should be seen as implementation detail and ideally, themes don't even provide styles for these, it just works. That's better for theme authors because it's simpler and it's better for the editor because it knows semantically what qn alignment means and can decide to change implementation, provide smart features...

I don't disagree — but we still _will_ have classnames, correct? Although I strongly agree that a lot of the complexity can be handled by out of the box CSS, if I'd like to — for example, attach a pseudo element badge in the top right corner of a full-wide image, I could hook into the class and do that, right?

[ellatrix]

I'm starting to think we need to separate "breaking out" from the main column (wide and full) from alignments (left, right, centre). Technically, you could have a floated image within the main column, but you could also have a floated image "broken out"/"pulled out" to the side.

[youknowriad]

Technically, you could have a floated image within the main column, but you could also have a floated image "broken out"/"pulled out" to the side.

The question is if it's clear enough from a UX perspective, I'm not sure about it. while technically they can be combined, for a user, it's very hard to understand. The solution for these advanced use-cases IMO is the ability to register custom alignments (but they apply in the same way, class to the extra wrapper)

[ellatrix]

I think it could be easier to understand for a user if these two concepts are separated. For example, I make a block break out to full width and then float = the pulled out look. If I just make an image float without breaking out the block, it stays in the main column.

[ellatrix]

Alternative Proposal

https://codepen.io/iseulde/pen/rNVQLKe

No Breakout

markup

<div class="wp-block wp-block-post-content wp-breakout-container">
    <p>...</p>
    <div class="wp-breakout-none"><!-- optional -->
        <figure class="wp-block-image"></figure>
    </div>
</div>

styles

.wp-breakout-container > * {
    width: 600px;
    margin-left: auto;
    margin-right: auto;
}

Wide Breakout

markup

<div class="wp-block wp-block-post-content wp-breakout-container">
    <p>...</p>
    <div class="wp-breakout-wide">
        <figure class="wp-block-image"></figure>
    </div>
</div>

styles

.wp-breakout-container > .wp-breakout-wide {
    width: 800px;
}

Full Breakout

markup

<div class="wp-block wp-block-post-content wp-breakout-container">
    <p>...</p>
    <div class="wp-breakout-full">
        <figure class="wp-block-image"></figure>
    </div>
</div>

styles

.wp-breakout-container > *:not(.wp-breakout-full) {
    width: 600px;
    margin-left: auto;
    margin-right: auto;
}

Left/Right Alignment

markup

<div class="wp-block wp-block-post-content wp-breakout-container">
    <p>...</p>
    <div class="wp-breakout-(none|wide|full)">
        <figure class="wp-block-image alignleft"></figure>
    </div>
</div>

styles

.alignleft {
    float: left;
}

Center Alignment

markup

<div class="wp-block wp-block-post-content wp-breakout-container">
    <p>...</p>
    <div class="wp-breakout-(none|wide|full)">
        <figure class="wp-block-image aligncenter"></figure>
    </div>
</div>

styles

.aligncenter {
    margin-left: auto;
    margin-right: auto;
}

---

Post Content

Now notice how, without a .wp-breakout-container, basic floating keeps working, for example in a column. The .wp-breakout-container can be added by a component that opts in to it, and in that case, child blocks will have wide and full alignment capabilities if the child block supports alignment. For FSE, the post content block must add breakout container support. For the old way of site rendering, we can wrap the_content() with an element with this .wp-breakout-container class, and add this class also to the root block list in the post editor.

[ellatrix]

Demo: https://codepen.io/iseulde/pen/rNVQLKe.

[ZebulanStanphill]

@ellatrix Is it possible to make that system work with (actual) left/right alignment options? E.g. I have an image that is thinner than the standard content width, and I want it to be aligned to left or right (but not floated). It seems like the system would cause it to be centered.

[ellatrix]

@ZebulanStanphill This is currently not possible, right? Do you mean if it would be possible with this new system?

[ZebulanStanphill]

@ellatrix I just checked, and it seems to be working differently than I remember. (Given all the changes that have taken place over the past several releases, it probably has changed.)

If I use the size handles on an Image to shrink its width, it stays centered. But then if I hit the "Reset" button in the Image dimensions section of the Inspector, the block takes up the entire content width, but the image itself is still the small width, aligned to the left. But then if I start dragging the size handle again, when I let go the image suddenly jumps to being the full content width.

(I can also drag the image size to be larger than the content width without even selecting the wide/full options, surprisingly. It is constrained to the content width on the front-end, though.)

A less buggy example would have been the Button block, back before the Buttons block existed and you could insert a single unnested button. By default, that would be left-aligned but (unless it was filled to the brim with text) far thinner the content width.

If I manually insert one unnested Button, it appears centered in the editor, but not on the front-end. It used to also not be centered in the editor, but something seems to have changed since then.

I tested this in Twenty Twenty.

[strarsis]

Please remember that there are also image (blocks) that can be "aligned" which means "floated" in the current context. This means an image block not just goes to the left/middle/right or stretch in a certain way, text would float around it. This behaviour differs significantly from the one of the other blocks. It also shows that a "No alignment" state is important because images that shouldn't be floated need this default state.

[Netzberufler]

It was mentioned a few times that there are basically two approaches for alignments:
1) Using max-width and margin auto
2) Using negative margins with vw units

For my themes I went with negative margins because I think the first approach is not very robust.

Any custom block or custom block style from third-party plugins which accidentally overrides the margin value breaks the theme layout.

For example:

p.is-custom-style {
    margin: 0 0 3em;
    ....
}

.wp-custom-block {
    margin: 0;
    ....
}

Not sure if you have already plans to prevent that but I thought I mention it here.
It was one issue I had while initially adding styles for wide and full block alignments.

[mrwweb]

As a theme author who's been consistently working the block editor for a year+ now, I just want to weigh in on the primary issue I've run into with alignment classes.

In this situation:

<div class="wp-block-image">
    <figure class="alignleft"></figure>
</div>

I can't write the selector .alignleft + * to apply to the block following a floated element. I often need to do this to deal with margin/alignment issues. Just adding a class to the wrapper indicating the contained alignment would solve all my problems:

<div class="wp-block-image is-aligned-right">
    <figure class="alignleft"></figure>
</div>

[strarsis]

@youknowriad: There is one thing I find quite confusing: In backend/editor there is also the wp-block class. Can this class be used to replace selectors like > * as used in frontend? Typographic elements like paragraphs don't have the wp-block class assigned in frontend, so wp-block only reliably select all blocks in backend? Or should I rather use * > .editor-styles-wrapper for a (separate, unwrapped) editor stylesheet? Is this an extra nice-to-have feature for backend styling? .wp-block got max-width by default backend styles, hence it can interfere with any frontend styles that impose their own max-width.

[youknowriad]

There is one thing I find quite confusing: In backend/editor there is also the wp-block class. Can this class be used to replace selectors like > * as used in frontend?

right now wp-block is only an editor class and it's important to support customizing the editor widths https://developer.wordpress.org/block-editor/developers/themes/theme-support/#changing-the-width-of-the-editor

Ideally, we'd just rely on something like .entry-content > * but themes are inconsistent so if we use entry-content on the editor, it's not certain the editor styles will match.

If we want to solve the alignment CSS in core and apply them automatically on the frontend like this issue suggests to make it easier for theme authors to support alignments, this need to be solved somehow.

[paaljoachim]

What other actionable items is needed for this issue?