Block Controls - rename align to position and repurpose align to mean justify

[getdave]

Yes, I thought we were discussing using alignment for the distributions of elements within the container (left, center, space-between, etc) and position for how the container is displayed (wide, full-width, floated, etc).

Originally posted by @mtias in #19386 (comment)

Description

(If I understand him correctly) Matias raised a point about potentially renaming
Block “Align” controls to “Position” and repurposing “Align” to mean something more akin to “Justify”.

To be clear, the new terminology would be:

1. Position - how the container is displayed (wide, full-width, floated, etc).
2. Align - for the distributions of elements within the container (left, center,
   space-between).

This would be a significant change because align is already in use to mean float / width.

Questions

• What are the implications for existing Blocks (both Core and 3rd party)?
• What are the implications for Themes?
• Should we be looking to create new controls or deprecate existing controls?
• Should we do a design exploration of this before jumping into code?
• Is the suggested nomenclature suitable? Could it be improved? Is it comprehensible for non-technical users?

See also this WP Slack "conversation".

[karmatosed]

I don't mind on surface changing these but justify means something so rather we don't use that term. For me this makes sense:

• Position: what happens to the container, where it is placed and layout, could include later 'off grid'
• Alignment: what happens to content in the container

[mapk]

This makes a lot of sense to me in the way of terminology and how the current align functionality is more about positioning.

I imagine this will cause the classes to change from alignwide or alignfull to something more like positionwide or positionfull. This seems like a pretty big impact for themes. cc @kjellr @allancole.

[kjellr]

I imagine this will cause the classes to change from alignwide or alignfull to something more like positionwide or positionfull. This seems like a pretty big impact for themes. cc @kjellr @allancole.

That's a good point. This is obvious but if we do change those classnames, we'll just need to ensure backwards compatibility with all the themes that use those (both in the front end and editor). That's generally fine, but my only hesitancy is just that it'll require including a lot of extra CSS make that happen.

[joyously]

I imagine this will cause the classes to change from alignwide or alignfull to something more like positionwide or positionfull. This seems like a pretty big impact for themes.

If you had listened, back at the beginning, we wouldn't be in this now... #11881

Position also has a meaning in CSS, which doesn't match up with the new usage.
Perhaps separating the width options from the side to side options would make it clearer.
Block alignment and Text alignment and Text distribution (or Content distribution or Content spacing or Content arrangement) are all separate from Width.
But it seems that Block alignment has the most legacy and shouldn't e the one that changes.

[getdave]

@joyously Thanks for your feedback. This issue obviously has a history which I wasn't aware of. I'm ready and willing to work with you and others to help move this forward if there is broad support for it (and it seems like there is!).

Position also has a meaning in CSS, which doesn't match up with the new usage.

I definitely take your point here. The question I'm asking myself is do most users think in terms of CSS? I appreciate position in CSS is different but I'd like to get some perspective on what someone who doesn't know anything about the technical side of websites feels about this term.

As you mention another option could be "Layout".

Perhaps separating the width options from the side to side options would make it clearer.

Personally I think we may need to consider this. As things stand you can't have both "width" and "alignment" (read float left/right) applied together. The downside to splitting these would be adding additional buttons to the UI.

[ZebulanStanphill]

It should be noted that aligncenter is, unlike all the other align___ classes, actually an alignment, so it may belong in a separate toolbar from the other options.

There are at least 4 different things here:

• floats: alignleft, alignright
  • note that some themes use negative margins or something similar to pull blocks out of the main content column entirely, avoiding the standard text-wrapping float look
  • also note that there have been proposals to add a center or even top/bottom float options to CSS, though I'm not sure if these will ever go anywhere
• size options: alignwide, alignfull
  • given the occassional theme behavior for floats mentioned above, it might make sense to group these together; on the other hand, perhaps "pulling to the left out of the main column" and standard "float left with text wrapping around" should be treated separately and themes shouldn't be doing what they do right now
• literal block (horizontal) alignment: aligncenter
  • this is often accomplished with left and right margins, though a block layout using flex or grid could use a different approach; a block could also be aligned to the left or right without having float behavior
• alignment of items within the block: see CSS properties like justify-content, justify-items, align-items, etc.

[ZebulanStanphill]

Another thing to note is that floating, pulling out of the main column, and wide/full widths are all mutually exclusive: it doesn't make any sense to use two of these at the same time. Because of that, it may make sense to put them all in the same toolbar. However, they should probably still use more descriptive names and not just share the term "align".

[ZebulanStanphill]

(Continued from my previous comment...) The options in this combined toolbar could be labeled as follows:

• Float left
• Float right
• Pull left
• Pull right
• Stretch to wide width
• Stretch to full width

I have no idea what you would call this toolbar as a whole, though. Block flow options, perhaps?

[joyously]

Even if users don't know what Position in CSS is, I still don't think you should use it because future enhancements might include actual position choices, such as relative, absolute, fixed, or sticky.

[allancole]

This is obvious but if we do change those classnames, we'll just need to ensure backwards compatibility with all the themes that use those (both in the front end and editor). That's generally fine, but my only hesitancy is just that it'll require including a lot of extra CSS make that happen.

Overall, I think accurate naming in general will help users understand the UI better. But I’m also super hesitant about backwards compatibility related to changing this.

I personally feel it’s better to let Gutenberg control how these classes work exclusively. The only thing a theme designer is ever concerned with related to these classes is the resulting widths of a block once rendered. With just a few variables like $content-width=800px, $wide-content-width=1200px, $position-behavior=pull/float. themes could influence the alignment classes without actually writing selectors that are subject to change in core later (as suggested here).

Also want to point out that content widths are probably the only place where it might makes sense to do something like this. We already have a global $content_width variable in PHP that controls the width of media and embedded content to make content fit a theme’s design. This feels like the same kind of decision here with some added complexity for wide and floating behaviors.

I find that it’s too easy to break things when fiddling with or overriding the alignment classes especially with responsive styles which are really hard to solve in a theme. A lot of time you don’t even know you’re doing it wrong until much later when a class name changes in core or a new block gets introduced that needs to work differently.

[jasmussen]

There is some discussion happening in #19944 which touches icon naming. It's not extremely critical that we get it 100% right at this point in time, because those icon names are easy to change. But in case you'd like to share input, it's a good opportunity to do so.

[ZebulanStanphill]

Reposting #20689 (comment) here to get some feedback on some class name ideas:

If we were to put them all under a single naming scheme, I'd go with something like this:

wp-position-xxx with the xxx replaced with one of the following for each of the possible values:

• align-left (as in actual left alignment)
• align-right
• align-center
• float-left (or maybe pull-left)
• float-right (or maybe pull-right)
• stretch-wide-width (or maybe just wide)
• stretch-full-width (or maybe just full-width)

I'm not sure whether wp-position- is the right naming scheme, though. CSS already has a thing called position that isn't really the same concept. Perhaps it may also be worth distinguishing from potential vertical options by using wp-horizontal-position- or wp-x-position- or something like that.

But I'm not convinced that different options should use the same naming scheme if they're technically different things. If we were to use more diverse names depending on what exactly the position/alignment/whatever actually is, I would go with something like the following:

• wp-align-left
• wp-align-right
• wp-align-center (or possibly wp-align-center-horizontally or wp-align-center-x to distinguish from potential vertical centering or something like that in the future)
• wp-float-left (or maybe wp-pull-left)
• wp-float-right (or maybe wp-pull-right)
• wp-width-wide
• wp-width-full

I prefer this naming scheme since it's more concise, and doesn't try to fit a redundant, possibly incorrect word like "position" into the class names.

[jasmussen]

In general the naming convention seems worth it to me — and "worth it" is something it has to be because it's a big change.

I would avoid a wp- prefix, though, as it does not seem to add any value, just some "branding" if anything.

[kjellr]

I would avoid a wp- prefix, though, as it does not seem to add any value, just some "branding" if anything.

The main benefit to something like this would be that it wouldn't interfere with any more generic classnames that older themes may be using. That said, I do agree... I think it's relatively (probably?) safe to just use these without a prefix.

[jasmussen]

The main benefit to something like this would be that it wouldn't interfere with any more generic classnames that older themes may be using.

If these new alignments are opt-in, which they are in #20689, this might be a non-issue. I.e. we could make the opt-in be in the code rather than in the CSS with the prefix.

[jordesign]

@jasmussen Just checking in to see if this is a discussion/decision that still needs resolution?

[jasmussen]

I think at this point it largely boils down to the feasibility on the implementation side. What's actually pragmatically possible at this point. Perhaps @tellthemachines has some insights?