[wp-trac] [WordPress Trac] #63861: Explore removing wpmu activation styles
WordPress Trac
noreply at wordpress.org
Fri Jan 30 16:00:22 UTC 2026
#63861: Explore removing wpmu activation styles
-----------------------------------+---------------------------------------
Reporter: joedolson | Owner: (none)
Type: enhancement | Status: assigned
Priority: normal | Milestone: 7.0
Component: Login and | Version:
Registration |
Severity: normal | Resolution:
Keywords: needs-patch | Focuses: accessibility, multisite
-----------------------------------+---------------------------------------
Changes (by sabernhardt):
* component: General => Login and Registration
Old description:
> This was briefly raised in https://core.trac.wordpress.org/ticket/40361,
> but wasn't resolved in that ticket.
>
> The `wpmu_activate_stylesheet` action loads inline CSS when activating a
> user on the front end. These styles are unlikely to be generally useful
> in design, and are specifically problematic for contrast in dark mode or
> dark designs.
>
> Even if they're potentially useful for backwards compatibility, it seems
> past time to reconsider them. There are many other ways to provide styles
> in this context.
New description:
This was briefly raised in #40361, but wasn't resolved in that ticket.
The `wpmu_activate_stylesheet` action loads inline CSS when activating a
user on the front end. These styles are unlikely to be generally useful in
design, and are specifically problematic for contrast in dark mode or dark
designs.
Even if they're potentially useful for backwards compatibility, it seems
past time to reconsider them. There are many other ways to provide styles
in this context.
--
Comment:
> This is actually pretty nasty to wrestle with.
Yes. I would recommend fewer new or opinionated styles, though I still
wanted to set the `#key` input text direction to LTR
[https://github.com/WordPress/wordpress-develop/pull/3933/changes#diff-
3034d6250d79ff094454e1f374c3670d1253367f4191dfc536a0e2e7a8cd525c for RTL
languages].
> These styles are unlikely to be generally useful in design, and are
specifically problematic for contrast in dark mode or dark designs.
Could you share how the styles were problematic with the
[https://github.com/wpa11yday/wpaccessibilityday/commit/8ca1230eebaee2e3ed9f8f44ac4b5f6c2e314d1e
#diff-155f2ba1fefc9789698c08ff3f53003db38bba7bbee77fb92781edb8ad7e1e9dR727
Gravity Forms User Registration plugin]? If it was from the `.error`
colors, I could not find where the class might be added in core (even
going back to when [https://mu.trac.wordpress.org/browser/trunk/wp-inst
/wp-activate.php?rev=543 wp-activate.php was created]).
Looking at each of the current selectors:
1. Container: On #40361, I wanted to prevent text touching the side of the
window/viewport, and I moved the 90% width value from the input fields to
the container. Adding a small amount of padding (PR 10823 has 1.5rem)
would achieve the same purpose. Of course, almost all block themes have
header and footer text that touches the side because they still use the
old `theme-compat` templates (#63499, #55023).
2. Form: Using a `rem` measurement can make the value //more// uniform
among themes, but `wp-signup` uses `2em` and `1.5rem` would still have
some differences when the themes set the root font size. For example,
Twenty Fifteen sets the root size to 62.5% (usually 10 pixels) and Twenty
Nineteen sets it to 22 pixels.
3. Inputs (`#submit, #key`): Inputs inherit colors and focus styles from
the theme, so adding a specific background color to the container is not
very friendly. I do not mind changing the submit to `auto` width, which
could help when the paragraphs have no margin (such as Twenty Twenty-One).
4. `#language` element: Unless someone knows where this is added, I would
remove the rule.
5. `.error` class: I was going to suggest removing this rule because I
could not find the class in core. If the background color is changed, it
could reuse `#ffebe8` from `wp-signup` styles.
6. `span.h3`: I considered switching these elements to `strong` tags so
they would fit better with theme styles, but some sites //can// have
special CSS for those `span` elements. Directory searches found
[https://wpdirectory.net/search/01KG7F66GQDYSC1QXT44MRGDY1 one theme] and
[https://wpdirectory.net/search/01KG7F4XT7Y13A2S267451X0JZ a few plugins]
that matched `span.h3`. If the font weight remains at `600`, I agree with
removing the padding and larger font size.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/63861#comment:11>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list