[Admin reskin] Admin Help still uses old colors

[fabiankaegy]

The "Help" menu in the admin got missed and still uses the old colors.

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

## Use of AI Tools
none

[ozgursar]

Patch Testing Report

Patch Tested: ​https://github.com/WordPress/wordpress-develop/pull/11070

Environment

• WordPress: 7.0-beta2-61752-src
• PHP: 8.2.29
• Server: nginx/1.29.4
• Database: mysqli (Server: 8.4.7 / Client: mysqlnd 8.2.29)
• Browser: Chrome 145.0.0.0
• OS: macOS
• Theme: Twenty Twenty-Five 1.4
• MU Plugins: None activated
• Plugins:
  • Code Snippets 3.9.5
  • Test Reports 1.2.1

Steps taken

1. Inspect Admin Help menu colors using Dev Tools
2. Notice active tab with old border-left color of #72aee6
3. Apply patch
4. Inspect the element confirm the new border-left color of var(--wp-admin-theme-color)
5. ✅ Patch is solving the problem

Expected result

• We expect to see the new CSS variable --wp-admin-theme-color color instead of the old value

Screenshots/Screencast with results

Before

After

[noruzzaman]

Test Report

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/11070

Environment

• WordPress: 7.0-beta2-20260226.234351
• PHP: 7.4.33
• Server: PHP.wasm
• Database: WP_SQLite_Driver (Server: 8.0.38 / Client: 3.51.0)
• Browser: Chrome 145.0.0.0
• OS: macOS
• Theme: Twenty Twenty-Five 1.4
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.1

Steps taken

1. Inspect Admin Help menu colors using Dev Tools.
2. Notice active tab with old border-left color of #72aee6.
3. Apply the patch from ​11070.
4. Compile assets using 'npm run build'.
5. Inspect the element and confirm the new border-left color of var(--wp-admin-theme-color).

Expected result

• We expect to see the new CSS variable --wp-admin-theme-color instead of the hardcoded color value.

Actual Results

Patch is solving the problem. The active help tab now correctly uses the admin theme color variable.

Screenshots

Before	After

[shailu25]

Test Report

This Report Validates that the indicated patch address the issue.✅

Patch Tested: ​https://github.com/WordPress/wordpress-develop/pull/11070

Environment:

WordPress - 7.0-beta2-20260226.234351
OS - Windows
Browser - Chrome
Theme: Twenty Twenty Five
PHP - 7.4.33
Plugin - None

Actual Results:

• Issue Resolved with Patch ✅

Supplemental Artifacts

• Attached

[shailu25]

Before Patch

[shailu25]

After Patch

[tusharaddweb]

I’ve applied the patch and tested it on WordPress 7.0 Beta 2. The issue is resolved and everything is working as expected.

Before applying the patch:-
​https://prnt.sc/J8WTYBO_nIuC

After applying the patch:-
​https://prnt.sc/e33sHAqkmwIw

[audrasjb]

Self assigning for final review.

[audrasjb]

Marking this ticket with changes-requested as per Joe's comment in the PR:

The use of transparency on the background colors is leaving a visible border between the selected tab and the help tab content, so I think these colors need to be solid.

Yes, I agree with the point we need to use solid color which will blended on a white background and results in equivalent hex.

I used AI tool and found the equivalent to be #EFF2FE this hex value. We can use this as a solid color. On adding this it looks good without any visible border.

If the user changes their admin color scheme, using the hex value for a background won't work as it would not match the color scheme:

Suggestion would be to use a pseudo-element to "cover" the border:

.contextual-help-tabs .active {
	padding: 0;
	margin: 0 -1px 0 0;
	border-left: 2px solid var(--wp-admin-theme-color);
	background: rgba(var(--wp-admin-theme-color--rgb), 0.08);
	/* box-shadow: 0 2px 0 rgba(0, 0, 0, 0.02), 0 1px 0 rgba(0, 0, 0, 0.02); */
	background: color-mix(in srgb, var(--wp-admin-theme-color) 8%, white);

	&::after {
		content: "";
		position: absolute;
		top: 0;
		right: -1px;
		width: 2px;
		height: 100%;
		background: inherit;
		z-index: 2;
	}
}

https://core.trac.wordpress.org/ticket/64744

Thanks for the feedback and the proposal @amesplant !
I created a new PR with these changes: #11358
Closing this PR in favor of #11358.

This looks good to me.
[Uploading screen-capture (10).webm…]()

​screen-capture (10).webm

[audrasjb]

Marking this as waiting for dev-feedback.

[joedolson]

@audrasjb 👍

[audrasjb]

In 62145:

Admin: Use admin color scheme variable for bar, highlight, and contextual help styles.

This changeset ensures the styles for bar, highlight and contextual help always take into account the admin color scheme settings.

Reviewed by joedolson.
Props fabiankaegy, audrasjb, ozgursar, noruzzaman, shailu25, sandipsinh007, tusharaddweb, hbhalodia, amesplant, joedolson.
Fixes #64744.
See #64308.

[wildworks]

.contextual-help-tabs .active::after {
	content: "";
	position: absolute;
	top: 0;
	right: -1px;
	width: 2px;
	height: 100%;
	background: inherit;
	z-index: 2;
}

This style causes an overflow, resulting in an unintended scrollbar always appearing on Windows OS. What is the purpose of this style in the first place? In my environment, removing these styles does not cause any visual issues.

[wildworks]

Help menu with scrollbar

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

## Use of AI Tools

None

## Screenshots

### Before

### After

[SergeyBiryukov]

Replying to wildworks:

.contextual-help-tabs .active::after {
	content: "";
	position: absolute;
	top: 0;
	right: -1px;
	width: 2px;
	height: 100%;
	background: inherit;
	z-index: 2;
}

This style causes an overflow, resulting in an unintended scrollbar always appearing on Windows OS. What is the purpose of this style in the first place? In my environment, removing these styles does not cause any visual issues.

It appears to originate from ​this comment.

[sabernhardt]

I think removing the pseudo-element (PR 11396) is correct. It was intended to cover a border for the active help tab, but I do not find the border there in Chrome or Firefox with Windows 11 when I apply the patch.

If some browser does require the pseudo-element:

1. It is not positioned correctly—in relation to the active tab—because the list item lacks position: relative.
2. It probably should be hidden for small screens, at the 782px breakpoint.

[audrasjb]

Hello and thank you both for reopening the ticket and discussing this issue. No problem we can remove the pseudo element but I don't really get why the border would be ok now without it: when I tested the ticket, the PR using this small hack was the only one where the border was not visible… (I'm running a very classic MacOS/Chrome environment).
By the way we don't want that scrollbar anyway.
I'll try to reproduce the border issue too.

[audrasjb]

Well I tested the border issue with the exact same config I previously had and I can't reproduce it anymore… let's add a follow-up commit with PR11396 as it fixes the scrollbar issues, simplifies the approach and doesn't seem to introduce any issue.

[mukesh27]

#64997 was marked as a duplicate.

Looks good to me.
### Before:

### After:

[wildworks]

After re-reading ​this comment, I don't think this pseudo-element is necessary at all. The following CSS is actually what removes the right border of the active tab.

.contextual-help-tabs .active {
    margin: 0 -1px 0 0;
    background: color-mix(in srgb, var(--wp-admin-theme-color) 8%, white);
}

[sabernhardt]

Yes, using color-mix() fixed the border issue. The pseudo-element was suggested when the background used RGBA.
background: rgba(var(--wp-admin-theme-color--rgb), 0.08);

[audrasjb]

In 62187:

Administration: Prevent horizontal scrollbar in contextual help panel.

In [62145], an ::after CSS rule was added that caused an overflow, resulting in an unintended scrollbar always appearing on Windows OS for example. This changeset removes the related CSS rule which is unnecessary to fix the initial issue.

Follow-up to [62145].

Props wildworks, SergeyBiryukov, sabernhardt, audrasjb, huzaifaalmesbah, mehrazmorshed, mukesh27.
Fixes #64744.

[audrasjb]

Reopening to consider backporting [62187] to 7.0.

[SergeyBiryukov]

Replying to audrasjb:

Reopening to consider backporting [62187] to 7.0.

Should the code from comment:29 be added instead of the removed code?

[wildworks]

Reopening to consider backporting [62187] to 7.0.

Approved

Replying to audrasjb:

Reopening to consider backporting [62187] to 7.0.

Should the code from comment:29 be added instead of the removed code?

Since the code from comment:29 already exists, I think we can simply backport [62187] to 7.0.

[audrasjb]

@SergeyBiryukov @wildworks yes, I think we can go with [62187] as a follow-up to [62145].

[wildworks]

In 62190:

Administration: Prevent horizontal scrollbar in contextual help panel.

In [62145], an ::after CSS rule was added that caused an overflow, resulting in an unintended scrollbar always appearing on Windows OS for example. This changeset removes the related CSS rule which is unnecessary to fix the initial issue.

Follow-up to [62145].

Reviewed by wildworks, SergeyBiryukov.
Merges [62187] to the 7.0 branch.

Props wildworks, SergeyBiryukov, sabernhardt, audrasjb, huzaifaalmesbah, mehrazmorshed, mukesh27.
Fixes #64744.