Gutenberg: Paragraph block: becomes invalid when setting text alignment to justified

Created on 3 Aug 2018  ·  18Comments  ·  Source: WordPress/gutenberg

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

  • #6102
  • #7604
  • #8131
Backwards Compatibility [Block] Paragraph [Type] Enhancement

Most helpful comment

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 ...

All 18 comments

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.

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.

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.

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.

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

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!

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

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.

justify-text mov

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.

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 ...

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.

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.

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 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: https://github.com/WordPress/gutenberg/issues/6833#issuecomment-445542756

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.

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:

EditorsKit-Formats

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

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

My current approach for theme (SASS):
```scss
body {
p {
&:not(.has-text-align-center):not(.has-text-align-right) {
text-align: justify;
}
}
}
````

Was this page helpful?
0 / 5 - 0 ratings

Related issues

mhenrylucero picture mhenrylucero  ·  3Comments

youknowriad picture youknowriad  ·  3Comments

wpalchemist picture wpalchemist  ·  3Comments

jasmussen picture jasmussen  ·  3Comments

aduth picture aduth  ·  3Comments