Skip to content

Twenty Nineteen: fix Separator block's full-width size and placement - #13526

Open
irozum wants to merge 1 commit into
WordPress:trunkfrom
irozum:fix/59203-twentynineteen-separator-fullwidth
Open

irozum wants to merge 1 commit into
WordPress:trunkfrom
irozum:fix/59203-twentynineteen-separator-fullwidth

Conversation

@irozum

@irozum irozum commented Sep 15, 2026

Copy link
Copy Markdown

Fixes the Twenty Nineteen Separator block so that Full width alignment actually spans the full page width, for both the Default and Wide Line styles. Currently the block's own max-width/width rules ignore the alignfull alignment entirely, so choosing Full width has no visible effect on the frontend and the separator is barely visible in the block editor.

Frontend (sass/blocks/_blocks.scss): the Separator block's own max-width: 2.25em (Default) and the is-style-wide bounded max-width were never overridden when .alignfull was applied. Added &.alignfull:not(.is-style-dots) { max-width: none; } so a full-width Default or Wide Line separator now spans edge-to-edge, matching the rest of the theme's full-width block handling. The Dots style is intentionally excluded, since it already renders at a deliberately bounded width.

Editor (style-editor.scss): the editor styles only set an explicit width for the narrow Default style ($font__size-xl); nothing widened the separator when it carried the alignfull class, which is why it appeared barely visible in the editor. Added &.alignfull:not(.is-style-dots) { width: 100%; }, placed after the narrow-width rule so it takes precedence when both classes are present.

Note: the ticket's original 2022 patch also suggested adding a block-editor-iframe__body selector to fix a missing editor margin; that generic fix already landed separately (visible at style-editor.scss:39) and covers this case, so no further change was needed there.

Both compiled style.css and style-editor.css were updated by hand to match, since this environment's Node toolchain couldn't rebuild the theme's SCSS via node-sass (native build failure unrelated to this change); the added rules were hand-verified against the existing compiled output's formatting conventions.

Manual verification: activated Twenty Nineteen locally and tested all four combinations directly in the running site (frontend + block editor, via computed styles and screenshots):

  • Default style + Full width → now spans full width (was capped at 2.25em)
  • Wide Line style + Full width → now spans full width (was capped at the content max-width)
  • Default style, no alignment → unchanged (still 2.25em), confirming no regression
  • Dots style + Full width → unchanged (still bounded by content max-width), confirming it was correctly left out of scope

Trac ticket: https://core.trac.wordpress.org/ticket/59203

Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Sonnet 5
Used for: Implementation and manual browser verification. Reviewed by Igor Rozum.


This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

@github-actions

Copy link
Copy Markdown

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props irozum.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

@github-actions

Copy link
Copy Markdown

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

  • All changes will be lost when closing a tab with a Playground instance.
  • All changes will be lost when refreshing the page.
  • A fresh instance is created each time the link below is clicked.
  • Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
    it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant