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: yogeshbhutkar <yogeshbhutkar@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: Zodiac1978 <zodiac1978@git.wordpress.org>

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

Excellent work, @yogeshbhutkar!

Maybe we should reduce the spacing for nested VStack and use 4 instead of 8 there as well. What do you think?

Screenshots

Before

After

Thanks for the review, @Mamaduka.

I have a few more points regarding the Tracks UI that I'd like to discuss.

The Apply button in the Edit Tracks section feels redundant. Since each control already uses an onChange handler, changes are applied immediately, making the button unnecessary and potentially misleading.

Ref.

In addition to reapplying existing values, the Apply button also sets default values when no input is provided. (I'd consider it to be a surprising behavior)

Ref.

I think instead of language scoping the label, it's best to keep it as Track, as this is what Chrome displays for Tracks with empty labels. And instead of doing this on button press, I'd suggest adding these defaults while destructuring the data. (No surprises, the user knows the default values beforehand)

I believe it's best to discard the Apply button for these reasons. I also propose introducing a Back button to go to the previous component where all the tracks are listed.

Ref.

Currently, it's possible to save tracks with empty labels simply by leaving the label blank and clicking outside the popover. In Firefox, these tracks are displayed without any label, which could be confusing. We might want to consider either preventing tracks without labels from being rendered on the front-end or showing a warning if a label is missing.

Ref.

P.S. I plan to address these points as follow-ups, depending on their feasibility.

The Apply button in the Edit Tracks section feels redundant. Since each control already uses an onChange handler, changes are applied immediately, making the button unnecessary and potentially misleading.

Having an 'Apply' button is generally better for accessibility and UX. It's better to keep it.

Currently, it's possible to save tracks with empty labels simply by leaving the label blank and clicking outside the popover.

This is a standard behavior for some popover forms to prevent content loss. We could refactor the track editor and keep the editing state internal, and only call onChange when the "Apply" button is pressed.

It would be helpful to understand the rationale behind introducing the default values logic. As far as I can tell, the <track> element has no required attributes.

Let's merge this, and feel free to follow up on some of these points in a new PR.