Twenty Nineteen: Inconsistent spacing between Table Caption and Table in Table Block

[sainathpoojary]

In the Twenty Nineteen theme, the Table block displays inconsistent spacing between the table caption and the table.

• Editor: The caption is directly attached to the table without any spacing.
• Frontend: There is noticeable spacing between the table caption and the table, creating a visual discrepancy.

Steps to Reproduce

1. Activate the Twenty Nineteen theme.
2. Create a new post or page using the Block Editor (Gutenberg).
3. Add a Table block and insert some sample content.
4. Add a caption for the table.
5. Observe the spacing between the caption and the table in the editor.
6. Publish the post and view it on the frontend.
7. Notice the extra spacing between the caption and the table that was not present in the editor.

Preview:

This PR addresses the issue of inconsistent spacing between the table caption and the table in the Twenty Nineteen theme. The spacing differs between the editor and the frontend.

• Added a bottom margin to the table in the editor (style-editor.css) to match the frontend display.

Before:

After:

Trac ticket: #63143

[SirLouen]

Test Report

Description

This report validates the patch works as expected with a minor caveat

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/8559.diff

Environment

• WordPress: 6.8-beta2-59971-src
• PHP: 8.2.28
• Server: nginx/1.27.4
• Database: mysqli (Server: 8.4.4 / Client: mysqlnd 8.2.28)
• Browser: Chrome 134.0.0.0
• OS: Windows 10/11
• Theme: Twenty Nineteen 3.0
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.0

Actual Results

1. 🟠 Issue resolved with patch, but some additional review is suggested

Additional Notes

• The frontend margin-bottom is 1rem, not 1.375rem. Not a big deal, but technically, we are looking to harmonize both views. Should we normalize the base size in the editor to 22px to get the same px with 1rem in for both results? For example by adding to set the same px standard as the front-end view.

  html {
      font-size: 22px;
  }
  

[sainathpoojary]

Hey @SirLouen,

I agree that normalizing the base size to 22px in the editor is a good idea. However, I was wondering would updating the base size to 22px cause any regressions in areas where styling was done assuming 16px as the base?

Looking forward to your thoughts!

[sabernhardt]

the margin does not belong in the editor with WordPress 5.3

[sabernhardt]

normalizing the base size to 22px in the editor

I do not recommend changing the base size on the html element. The theme's styles need to work even when the editor is not in an iframe. Also, calculations involving $size__spacing-unit in style-editor.scss seem to be based on 16.

The theme gave table elements a bottom margin on the front without defining the same margin in the editor. Of course, with WordPress 5.0's editor, the margin was unnecessary. The figcaption was not available until 5.4.

At least WordPress 5.3 would have an issue with the proposed margin on .wp-block-table table, but that is quite minor and the situation should be rare. The selector below would add a margin to tables that have a later sibling element, regardless of whether it is inside a Table block, but that could be over-complicated.

:where(.editor-styles-wrapper table:not(:last-child)) {
	margin-bottom: 1.375rem;
}

Also, the measurement theoretically could be 1em in the editor, which would be accurate for the default font size. However, if the table's font size is customized, it would be slightly off 1rem on the front.

The patch will need to edit style-editor.scss in addition to style-editor.css, and the spacing is different in each (indent with tab in SCSS, or two spaces in CSS).

[SirLouen]

I think the @sabernhardt suggestion is accurate. Anyway, it's near impossible that a site in 5.X would be willing to specifically update a theme.

I think a full review is needed to see if there could be adaptability to 22px as the theme main file:
​https://github.com/WordPress/wordpress-develop/blob/50bb23e860da86cd67e4f1d388767314bf09ea21/src/wp-content/themes/twentynineteen/style.css#L2214-L2217

@sabernhardt can you explain to me this:

The theme's styles need to work even when the editor is not in an iframe.

Where is style-editor.css being used apart from the iframe? I thought that this files were ad-hoc made for compatibility with these iframes.

@sainathpoojary regardless what you end choosing to do, don't forget, as Stephen said, to also add the edits to the SCSS file!

[sabernhardt]

Where is style-editor.css being used apart from the iframe?

Widgets are not in an iframe even now. The post editor was not in an iframe until WordPress 6.3, and it still was not framed with certain plugins or with the Custom Fields panel after 6.3.

it's near impossible that a site in 5.X would be willing to specifically update a theme.

It should be uncommon, but Twenty Nineteen only requires 4.7.

I think a full review is needed to see if there could be adaptability to 22px

That is unnecessary to fix the table/figcaption bug for this ticket, and a full review—with refactoring—would be a large project for a six-year-old 'classic' theme.

[SirLouen]

Replying to sabernhardt:

Where is style-editor.css being used apart from the iframe?

Widgets are not in an iframe even now.

True, I completely forgot about Widgets editor. They should definitely be revamped. There should be a 1:1 in classic themes stylesheets.

would be a large project for a six-year-old 'classic' theme.

True, plus I've been digging a little further and I see that styles are completely inconsistent among both versions.

For example, these two styles are exactly the other way around. The bigger margins are being placed in the style that already has bigger margins.

style.css:

.entry .entry-content .wp-block-pullquote blockquote {
  border: none;
  margin-top: calc(4 * 1rem);
  margin-bottom: calc(4.33 * 1rem);
  margin-right: 0;
  padding-left: 0;
}

style-editor.css:

.wp-block-pullquote blockquote {
  margin-top: calc(3 * 1rem);
  margin-bottom: calc(3.33 * 1rem);
  hyphens: auto;
  word-break: break-word;
}

}}}

So my conclusion is: Whatever you set, it will be right.