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.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: aduth <[email protected]>
Co-authored-by: jameskoster <[email protected]>

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

Size Change: +396 B (+0.02%)

Total Size: 2.58 MB

_{compressed-size-action}

I rebased this after #73215 was merged, with a few changes to align to some of the decisions made in the other pull request:

• Use shorthand token names (e.g. xs instead of x-small)
• Flatten groupings to eliminate the flow nesting (i.e. now just --wpds-dimension-gap-sm), common gap groupings
• Introduce a new 2xs gap token (4px default)
• Aligned the values between gap and surface paddings (not inherently connected)

The unit test failures seem to be stemming from the JSDOM upgrade, which I may end up spinning off into its own pull request to review independently.

Error: TestingLibraryElementError: Unable to find an accessible element with the role "link" and name "I'm an anchor link! (opens in a new tab)"

Here are the accessible roles:

  link:

  Name "I'm an anchor link!(opens in a new tab)":

It's an interesting nuance of computing accessible names and whether two adjacent elements are joined with any whitespace, where the browser renders these as <span>I'm an anchor link!</span><span aria-label="(opens in a new tab)"></span>. Apparently it's an ongoing discussion in the spec of computing accessible names. After digging into it, I've determined the root cause to be an interaction between dom-accessibility-api (which powers the getByRole name matching) and JSDOM, where dom-accessibility-api considers getPropertyValue('display') of an element. In earlier versions of JSDOM, a <span> would not report any value here, but in recent versions this is now 'inline'. Thus, the computed name has no space between the link text and the "(opens in a new tab)".

My read of the relevant specification is that this is a more accurate reflection of how a browser would be expected to behave:

§2.6.4 Name From Each Child: For each rendered child node of the current node:
[...]
§2.6.4.3 Append the result to the accumulated text.

The unit test failures seem to be stemming from the JSDOM upgrade, which I may end up spinning off into its own pull request to review independently.

Separate pull request at #73472

It looks like a smaller JSDOM version bump is enough to get the support we need for CSS properties without having to deal with all the other breaking changes and performance regressions that came up in #73472.

I think this should be good to move forward as-is after a review.

Flaky tests detected in 6c52a30.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/19900280690
📝 Reported issues:

• [Flaky Test] should show the original content after revert and page reload #68604 in /test/e2e/specs/site-editor/template-revert.spec.js