Paragraph block: becomes invalid when setting text alignment to justified

[ZebulanStanphill]

The issue

You can not set the text-align CSS property of a Paragraph block to justify. If you add it manually via Edit as HTML, the block will become invalid. Justified text alignment should be allowed, even if it is not exposed through the UI.

How to reproduce

1. Insert a Paragraph block.
2. Click the ellipsis (More Options) and choose Edit as HTML.
3. Add the following to the <p> tag: style="text-align:justify".
4. Try unfocusing the block.
5. Notice that the block becomes invalid.

Related issues and PRs

• Classic + Custom HTML blocks: Convert to Blocks removes valid inline formatting #6102
• Block Validation, Deprecation and Migration Experience #7604
• Block validation triggers when reverting a class change #8131

[tofumatt]

Just throwing this out there: if it's not important enough to surface via the UI, is it something we want to keep? A more richly-featured paragraph block with a justify alignment is possible, but maybe if there's no way to affect a change in the UI we shouldn't allow it in a basic block like this? 🤷‍♂️

cc'ing @karmatosed @mtias–I'm curious what our rule around allowing options that the UI doesn't expose is? Do we generally say "okay" or do we want to explicitly remove stuff that we don't support in our UI?

The latter is my preference as it's simpler but is obviously a bit needlessly hostile toward legacy/custom/expertly-made content.

[karmatosed]

Whilst I feel we shouldn't surface things we don't have in UI the issue is we do have the ability to add HTML. As a result I think we have to at least not have this break as it is valid HTML.

[azaozz]

Seems we will need a (new) way to set/update block props: by parsing the (user edited) HTML. That seems quite doable for simple blocks and HTML attributes but can quickly get "out of hand" for complex blocks (and introduce edge cases).

On the other hand editing the HTML is probably the most "unfriendly" way of doing this. Wondering what's the right balance here:

1. Leave all uncommon settings/attributes for plugins (that should be able to add UI/buttons for them).
2. Add support for setting and editing tags and attributes when editing the HTML (without invalidating the bloc).
3. Support them with keyboard shortcuts but leave any UI for plugins.

To me personally number three seems the best balance.

[danielbachhuber]

Related #6878 (comment) #10204

[KokkieH]

Just noting the Underline shortcut - Cmd/Ctrl-U - also no longer works. Using inline styling to add it does not make the block invalid the way adding justification does, though.

[mtias]

It'd be good to test to see if a plugin can add a "justify" button using rich text.

[burnuser]

No "justify" option is a serious Backwards Compatibility issue!
A lot of existing sites use justify (supported by a TinyMCE Advanced button or other Plugins).
And removing this alignment when converting Classic to regular Gutenberg blocks makes a massive impact on the visible layout of this sites!
Moving this issue back in the timeline (5.0.x Follow Ups) is a very bad idea!
Dont't make people hate Gutenberg from the fist day!

1.) Make "justify" work for existing posts/pages which are converted to Gutenberg blocks.
2.) Enable at least a keyboard shortcut like Alt+Shift+J
3.) Allow manual setting in HTML which is a prerequisite for the work of a plugin => Even if a toolbar-button is used to justify a paragraph, quote or list block, the result must me also be accepted, editable, saved and visible in the resulting HTML (view) of this block!

[ellatrix]

This has nothing to do with the RichText component. Removing the label.

[dmsnell]

Seems we will need a (new) way to set/update block props: by parsing the (user edited) HTML

Noting here that I don't think the problem is the update cycle on user-edited HTML. The problem in this case is that the block isn't defining the alignment attribute as being sourced from the inline CSS. I ran an experiment and added the justify attribute to the JSON attributes in the block comment delimiter. It worked.

This is not to say that we don't have a problem, but more to direct the problem statement to the cause of the problem. I think that had we chosen a custom JSON-format stored in the database we would have a different way of wording this, but as we are using HTML as our source of truth we have the appearance that we should be able to change the HTML without breaking blocks. That is, we are experiencing the tension between having freeform HTML and structured semantic types of content stored in blocks as HTML.

On one hand we might say that adding a custom inline CSS rule shouldn't invalidate a block, but on the other hand we're also at a loss for how to handle that in the general sense when a block doesn't understand the content passed into it, and there's no way we can provide any guarantee that those custom changes will persist after editing the block again.

[burnuser]

I know that "justify" formatting option was removed from WordPress intentionally, but although for some developers this seems to be a holy crusade, apparently many users are not willing to do without it.
And regardless of the need for always correct HTML presentation, the question arises whether it would not be the simplest and best solution for the moment to simply include justification as a standard button and function again in WordPress.
A quick and easy to implement solution for a big problem ...

[dmsnell]

Thanks for replying @burnuser, I'm sorry if I was unclear. What I meant to communicate was that this issue as written should probably be closed and recreated as a new feature request: "Please support justified text in the paragraph block."

Or… it should probably be closed and recreated as a new feature request: "Preserve unsupported but non-breaking changes to block code" or something like that.

[BridgwaterNews]

We run a local newspaper website, and have always used full justification. I've been getting worried about not being able to get it sorted, and the idea of going into every news story to add css is a nightmare.

However, the simple solution, if you are going to use full justification on all posts is to add the following css to your theme:

.post { text-align: justify; }

Obvious to most, I'm sure, but it's an option not mentioned anywhere that I've looked.

I suppose you could just add that to the advanced section on single posts, but not something I've tested.

[BridgwaterNews]

Another solution, is to use the 'Classic Block', which I've tested and shows the full justify button which is added with the free WP Edit plugin.

[mikeicode]

I suppose you could just add that to the advanced section on single posts, but not something I've tested.

You can target a single block with CSS to set the justify, I posted info here: #6833 (comment)

[helen-oneill]

Another solution, is to use the 'Classic Block', which I've tested and shows the full justify button which is added with the free WP Edit plugin.

I've just looked for this... I can't see it.

[phpbits]

Added Justify alignment format on EditorsKit plugin ( https://wordpress.org/plugins/block-options/ ) together with highlighted text color and underline controls. Here's how the "Justify" works:

Hoping this will solve everybody's problem :) Thanks!

[joxerg]

So no intention to have Justify by default? seriously??

[strarsis]

My current approach for theme (SASS):

body {
  p {
    &:not(.has-text-align-center):not(.has-text-align-right) {
      text-align: justify;
    }
  }
}

[sabernhardt]

The paragraph block fails validation with possibly any style attribute on the <p> tag (using WordPress 5.7.2 and Gutenberg 10.6.0).

Each of these contained "unexpected or invalid" content:

• <p style="text-align:justify;">text</p>
• <p style="text-align:left;">text</p>
• <p style="text-decoration:underline;">text</p>
• <p style="text-decoration:none;">text</p>
• <p style="margin: 0 0 3em;">text</p>
• <p style="color:#900;">text</p>

(Adding the color to a span tag within the paragraph does work, though.)
<p><span style="color:#900;">text</span></p>

[danielbachhuber]

Opened a PR to add a 'Justify' option to alignment controls: #48146

Would love a review from anyone who wants to test it 😊

[danielbachhuber]

I lied. 'Justify' is going in Global Styles first #48202

[t-hamano]

I tested this issue with the latest version of Gutenberg, and when I change the text alignment in the block toolbar, the attributes and class names are changed instead of the inline styles.

<!-- wp:paragraph {"align":"justify"} -->
<p class="has-text-align-justify">Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.</p>
<!-- /wp:paragraph -->

And if you change this attribute and class name to "justify" in the code editor, the block will NOT break. I think this problem can be solved by providing a UI for justifying and defining a CSS style called has-text-align-justify. In other words, I think the approach tried in #48146 is still valid.

One concern is that if we add the justify option to the AlignmentControl, it will be exposed to all blocks where that component is used or any custom blocks that use that component. Therefore, I'm concerned that developers will be forced to explicitly override the default alignmentControls prop if they do not wish to expose the justfiy option as before.

I know that "justify" formatting option was removed from WordPress intentionally

In the classic editor (and the Classic block), the justify button is not visible, but the shortcut is available. Does anyone know why the UI is intentionally not visible?

[t-hamano]

I submitted #59531, which aims to add new "textAlign" block support to also allow for the provision of a "justify" option UI for the Paragraph block in the future.