Fixed
Project:
Drupal core
Version:
main
Component:
Admin theme
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
3 Oct 2026 at 16:00 UTC
Updated:
3 Nov 2026 at 01:41 UTC
Jump to comment: Most recent, Most recent file




Comments
Comment #2
shank115 commentedI was able to reproduce this locally with the default_admin theme in dark mode.
I think the cause is this hard-coded colour in core/modules/workspaces_ui/css/workspaces.overview.pcss.css:
It's more specific than the theme's "table tr" rule, so the light background shows even in dark mode. On hover the theme's "table tr:hover" rule wins, which I think is why hovering looks correct.
A few possible ways to fix it:
1. Use light-dark() with transparent
Simplest fix, but the active row would no longer be highlighted in dark mode.
2. Use light-dark() with a subtle dark colour
This keeps a faint highlight in dark mode. It still stays in the module and doesn't depend on any theme.
3. Move the style to the admin theme
There's already a @todo saying this should move to the admin theme. default_admin could style it with its own variable, which already works in both modes (the hover state uses it):
I'd lean towards option 3, since it matches the
@todoand would follow the theme's accent colour. Options 1 or 2 would be a smaller change if we'd rather keep it in the module for now.Please let me know which approach sounds best.
Comment #5
hoxton commentedhey @shank115, i think using the existing behaviour of other listings, using transparent give acceptable returns too.
Comment #6
hoxton commentedComment #7
hoxton commentedComment #8
rkollerthanks for an initial MR @hoxton... i've tried to check it out, but problem is, you are using the branch name "main" which is already taken. so the MR does not work... but i've manually applied the change using the transparent keyword. that way the state isn't visible at all. that is not in line with WCAG2.2 SC1.4.11
i've then manually applied the suggestion in #2.2 and #2.3 as well ... with that approach in both cases the active state is at least somehow visible. main problem is that it doesnt meet the required minimum of 3:1 for state, both have a contrast of around 1.28:1 and 1.29:2... that reminded me to another issue #3207233: Improve the visual indication of the active workspace in the Workspaces listing UI that is basically about the visual indication of the active workspace. the linked issue was about the light mode only with claro and the dark mode from gin was not on the radar yet (which complicates things further)
the white background in dark mode is definitely a serious problem. so i am tempted to vote for a preliminary fix with an approach like suggested in #2.2 or #2.3 so the active workspace becomes at least legible again and to some extend highlighted in dark mode and do the proper fix in #3207233: Improve the visual indication of the active workspace in the Workspaces listing UI?
Comment #9
mgiffordI think this is fixed. At least as to what has been called out in the issue description. Here is a before-after screenshot:
This looks mergable. I had no problems applying it. I set it up in Tugboat too and was able to verify the fix worked.
There will be other issues, but at as far as color contrast goes, with light/dark mode Accessibility Insights didn't see any on this page.
Comment #10
rkoller-1 for RTBC from my end. the name of the feature branch has a naming collision (main) with the main branch, and yes in dark mode the active workspace becomes legible again but by using transparent as the color of choice for the active workspace the coloring of that active workspace is getting dropped - not only for the dark mode but for the light mode as well. wcag compliant labeling of the active workspace can be part of #3207233: Improve the visual indication of the active workspace in the Workspaces listing UI but i wouldnt drop the labeling of the active workspace entirely for light and dark mode as the fix. there are better ways for a preliminary fix until there is a consensus for a proper overall fix in #3207233: Improve the visual indication of the active workspace in the Workspaces listing UI imho.
Comment #11
catchMoving back to needs review per
#15#10.Also noting there's a @todo in the CSS that it should be moved to the admin theme before workspaces is stable, which never happened - should we do that there?
Comment #12
mgifford@catch do you mean #10?
I'll ask @mherchel about the CSS/Admin Theme.
Comment #14
rkolleri've manually tested #2.3 locally and that worked as a preliminary fix. as @shank115 proposed it is enough to set
i've tried to simply create a new MR to solve the naming conflict with the default main branch as well. therefore i've simply clicked the "create new branch" link on top of the issue... cuz i was able to fetch the issue fork but i was unable to checkout the one namedmain. the idea was to simply create a new MR, being able to check it out and then make the necessary changes locally and then push those changes up. problem is ive created a new MR based onmainbut i am unable to checkout it out with the given command:i get
<del>fatal: 'drupal-3627936/3627936-active-workspace-has-broken-styling' is not a commit and a branch '3627936-active-workspace-has-broken-styling' cannot be created from it</del>i guess i've misunderstood some of the innerworkings of git and feature branches :(i had to readd and refetch the feature branch then the checkout worked. the changes should be up soonish.
Comment #15
mgiffordSo agreed this isn't ideal:
I'm fine with your suggestion
In the related issue, I recently used (via AI & me), to have explicit light/dark modes:
And ya, should this be moved to the admin theme before Workspaces is marked stable?
Comment #16
rkolleri've pushed a commit to MR17471 replacing the transparent color / previous fixed color with the variable
var(--admin-color-bg-item)proposed by @shank115 in #2. the MR also fixes the name collision in MR17349 with the main branch.and I agree with the suggestion by @catch, the probably cleanest would be removing the styling from the workspaces module and move that already within this issue over to default admin. MR17471 might need another update for that. but for now the coloring by accent colors is now testable in MR17471.
Comment #19
mherchelAdded a code comment, so we can still support Claro.
Comment #20
rkollerthanks @mherchel, i've updated the MR with your suggestion. linting passes, but there are some warnings in the context to phpunit but probably unrelated with this MR since these are CSS only changes? so ive set it back to needs review.
Comment #21
smustgrave commentedHate to re-upload the same screenshots but did try and cleanup the summary some.
After
Comment #22
smustgrave commentedComment #28
mherchelCommitted and backported to 12.0.x, 11.x, 11.5.x, and 11.4.x.