[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