Fonts: Quote axis tags when compiling an array font-variation-settings

[Jiwoon-Kim]

WP_Font_Face::compile_variations() turned an array font-variation-settings into wght 400GRAD 0: no quotes around the axis tags and no commas between the axes, so browsers drop the declaration. It now prints "wght" 400, "GRAD" 0.

The string form, which theme.json documents, is passed through unchanged and is not affected.

Tests: two cases in the WP_Font_Face dataset, one for the string form and one for the array form. Before the fix the array case fails with font-variation-settings:slnt 0wght 400;; after it, phpunit --group fonts passes (232 tests, 930 assertions), and phpcs reports nothing on the two changed files.

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

Use of AI Tools

This pull request was prepared with Claude Code (Anthropic). It located the defect, wrote the fix and test cases, and ran the tests and coding standards checks locally in the wordpress-develop Docker environment.

[github-actions]

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 kimjiwoon, ugyensupport.

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

[github-actions]

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.

[dugyen]

Test report

Tested against a fresh wordpress-develop clone at trunk (ba9d19e41e), PHP 8.5.7, PHPUnit 9.6.36, MySQL.

Method: applied only the new dataset-case hunk to unpatched trunk first (source untouched) to confirm the array-form case reproduces the bug, then applied the source fix on top and re-ran, then ran --group fonts in full and phpcs on both changed files.

Results:

Run	Result
--group fonts, before fix (test-only patch on unpatched source)	2 failed / 232 — the new "variation settings array" case fails with font-variation-settings:slnt 0wght 400;, exactly the invalid CSS described in the ticket
--group fonts, after fix (full patch)	232 / 232 passed (930 assertions) — matches the numbers in this PR's own description
phpcs --standard=phpcs.xml.dist on both changed files	0 errors
Direct repro of the ticket's own example (compile_variations( array( 'wght' => 400, 'GRAD' => 0 ) ) via reflection)	font-variation-settings:"wght" 400, "GRAD" 0; — matches the ticket's "Expected" line exactly

The diff also applied cleanly (git apply --check) against current trunk with no conflicts.

Visual check: also rendered the real compiled CSS through a live variable font (Inter, wght+opsz axes) in a browser to confirm the practical effect, not just the string diff. Before the fix, the malformed declaration (font-variation-settings:wght 900opsz 32;) is invalid CSS and the browser drops it entirely, so the text renders at the font's default weight. After the fix, the same declaration (font-variation-settings:"wght" 900, "opsz" 32;) is valid and the browser applies it, rendering at weight 900. Happy to attach the before/after screenshots if useful — didn't want to route them through a public image host for this comment.

No regressions found in --group fonts; the string-form path (already correct) is unaffected. LGTM.