Block Library: Use --wpds-cursor-control design token

[hbhalodia]

What?

Part of: #76221

Why?

• Update the instances of cursor: pointer to use the desgin token for better maintainence in block library package.

How?

• Removed cursor: pointer and used cursor: var(--wpds-cursor-control);

Testing Instructions

1. Open any post/page.
2. Add any of the blocks that are updated, Accordion, Image, details, navigation, tab-menu-item etc and check if it uses the design token using inspect element.

Testing Instructions for Keyboard

• None

Use of AI Tools

• None

[hbhalodia]

Hi @mirka, Just have an doubt over these 2 sources,

gutenberg/packages/block-library/src/button/style.scss

Lines 6 to 8 in 9408691

	.wp-block-button__link {
	cursor: pointer;
	display: inline-block;

gutenberg/packages/block-library/src/social-link/editor.scss

Lines 7 to 13 in 9408691

	.wp-block-social-link-anchor {
	align-items: center;
	background: none;
	border: 0;
	box-sizing: border-box;
	cursor: pointer;
	display: inline-flex;

Do we need to update this to use cursor: var(--wpds-cursor-control);? This is because for the links I read here #76218 (comment), that it should always be the pointer.

If not needed to change, I can add the line /* stylelint-disable-next-line declaration-property-value-disallowed-list -- Links should always use pointer. */, so that when we add the rule globally it would be passed.

Thanks,

[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.

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: hbhalodia <hbhalodia@git.wordpress.org>
Co-authored-by: mirka <0mirka00@git.wordpress.org>

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

[Copilot]

Pull request overview

Updates @wordpress/block-library styles to use the --wpds-cursor-control design token instead of hard-coded cursor: pointer, enabling global cursor configuration via the design system.

Changes:

• Replaced multiple cursor: pointer declarations with cursor: var(--wpds-cursor-control) across several block styles.
• Added an Unreleased changelog entry documenting the cursor token migration.

Reviewed changes

Copilot reviewed 11 out of 11 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
packages/block-library/src/tabs-menu-item/style.scss	Uses --wpds-cursor-control for the tabs menu item cursor styling.
packages/block-library/src/post-comments-form/style.scss	Uses the token for submit input cursor styling.
packages/block-library/src/playlist-track/style.scss	Uses the token for playlist track button cursor styling.
packages/block-library/src/navigation/style.scss	Uses the token for submenu toggle and responsive container controls.
packages/block-library/src/navigation-overlay-close/style.scss	Uses the token for the overlay close control cursor styling.
packages/block-library/src/navigation-link/editor.scss	Uses the token for editor navigation submenu/placeholder cursor styling.
packages/block-library/src/image/style.scss	Uses the token for lightbox-related interactive controls.
packages/block-library/src/elements.scss	Uses the token for .wp-element-button cursor styling.
packages/block-library/src/details/style.scss	Uses the token for details summary cursor styling.
packages/block-library/src/accordion-heading/style.scss	Uses the token for accordion heading toggle cursor styling.
packages/block-library/CHANGELOG.md	Documents the enhancement in the Unreleased section.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The changelog entry claims this PR “replace[s] all instances”, but cursor: pointer still exists in packages/block-library/src/button/style.scss and packages/block-library/src/social-link/editor.scss. Either update those remaining occurrences to use var(--wpds-cursor-control) (if intended) or adjust this entry to avoid stating that all instances were replaced.

[Copilot]

Pull request overview

Copilot reviewed 11 out of 11 changed files in this pull request and generated 2 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

This changelog entry claims the migration excludes Button and Social Link blocks, but this PR also changes .wp-element-button to use --wpds-cursor-control, and Button block links commonly include the wp-element-button class (so they’ll pick up the token via cascade). Please either adjust the styles so those blocks truly remain excluded, or update the changelog wording to match the actual behavior. Also consider formatting cursor: pointer as code (backticks) for consistency with other entries.

[Copilot]

--wpds-cursor-control is documented as “for interactive controls that are not links” (see packages/theme/src/prebuilt/css/design-tokens.css:103), but .wp-element-button is commonly applied to <a> elements (e.g. Button block / File download button). Switching this selector to the control cursor token means any future global change to that token would also affect link cursors, and it undermines the intent to exclude link-based buttons. Consider limiting the token usage to non-anchor .wp-element-button elements, or ensuring anchor-based .wp-element-button retains the default link cursor behavior.

Suggested change

	.wp-element-button {
	.wp-element-button:not(a) {

[Copilot]

Pull request overview

Copilot reviewed 11 out of 11 changed files in this pull request and generated no new comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[mirka]

Just have an doubt over these 2 sources

Thanks for flagging. These tokens are only meant for "back end" UIs, so they shouldn't be used for front end content styling like button/style.scss. And for something like social-link/editor.scss, the comment says it mimics a front end link, so that's probably also a case to not use the token.

The preemptive stylelint disables sound good 👍

[hbhalodia]

Just have an doubt over these 2 sources

Thanks for flagging. These tokens are only meant for "back end" UIs, so they shouldn't be used for front end content styling like button/style.scss. And for something like social-link/editor.scss, the comment says it mimics a front end link, so that's probably also a case to not use the token.

The preemptive stylelint disables sound good 👍

Thanks will update the PR and resolve the conflicts.

[mirka]

--wpds-cursor-control is intended for back-end UI, but most of the changes in this PR are in packages/block-library/src/*/style.scss, and those files are part of the front-end block-library stylesheet via packages/block-library/src/style.scss. So this would introduce a back-end token into styles that can appear on the front end.

elements.scss is the clearest example, since .wp-element-button is used on front-end anchor elements as well, but I think the same concern applies more broadly to the other style.scss updates in this PR.

Do you think we should just disable the upcoming lint rule for this block-library package?

[hbhalodia]

--wpds-cursor-control is intended for back-end UI, but most of the changes in this PR are in packages/block-library/src/*/style.scss, and those files are part of the front-end block-library stylesheet via packages/block-library/src/style.scss. So this would introduce a back-end token into styles that can appear on the front end.

elements.scss is the clearest example, since .wp-element-button is used on front-end anchor elements as well, but I think the same concern applies more broadly to the other style.scss updates in this PR.

Do you think we should just disable the upcoming lint rule for this block-library package?

I agree that most of them are used are updated on style.scss, but style.scss would load on backend as well correct? I am agreeing to add a lint rule to the elements that are acting as an anchor or are anchor, but how that can be decided? I do not think that many of them have editor.scss, which means style.scss would take precedence on backend.

For eg: accordion-heading, it's not anchor and does not have editor.scss, means should have the token, but since you said only for backend, then should not. Seems a bit contradictory.

IMO, since most of this are on frontend side and our intention is to only apply to backend, I think best would be to add rule to style.scss, anchor elements, and update design token limited to editor.scss.

Let me know if that sounds good, so I can update the PR.

[mirka]

IMO, since most of this are on frontend side and our intention is to only apply to backend, I think best would be to add rule to style.scss, anchor elements, and update design token limited to editor.scss.

Even with this, most styles in editor.scss files seem to be applying in the parts mimicking front end content. The only styles that should clearly be using tokens would be in the inspector sidebar, and it seems there aren't many custom styles being applied there. So while it's possible to look at each instance in editor.scss files and decide whether they should be using tokens, on the whole it would probably be a lot of on-going friction for little benefit. Because even if we did limit the linting to editor.scss files, it would mostly be false positives. There are only two editor stylesheets in this PR, one of which is about links (social-link/editor.scss), and the other one (navigation-link/editor.scss) is actually also about links when you look at it closely.

So for now I'm inclined to omit this entire package from linting.

[hbhalodia]

There are only two editor stylesheets in this PR, one of which is about links (social-link/editor.scss), and the other one (navigation-link/editor.scss) is actually also about links when you look at it closely.

Yeah these are only 2 editor styles, else all are for frontend.

So for now I'm inclined to omit this entire package from linting.

Yes, we could remove the usage of design token for entire package and add the lint rule for all this files.

I would update the PR with the same.

[mirka]

So for now I'm inclined to omit this entire package from linting.

I meant that we will omit the entire package from the lint rule at the stylelintrc level, not disable per-file. So if there's nothing to change in here at the moment, I think we can close.

[hbhalodia]

So for now I'm inclined to omit this entire package from linting.

I meant that we will omit the entire package from the lint rule at the stylelintrc level, not disable per-file. So if there's nothing to change in here at the moment, I think we can close.

Ah okay, I misunderstood that, Yes we can close it.

Whole package linting is disabled in PR - #77501