fix(magic-login): match centralized TOS link color (DOTCOM-13796)#110551
Open
edequalsawesome wants to merge 3 commits intotrunkfrom
Open
fix(magic-login): match centralized TOS link color (DOTCOM-13796)#110551edequalsawesome wants to merge 3 commits intotrunkfrom
edequalsawesome wants to merge 3 commits intotrunkfrom
Conversation
The Magic Login TOS link was rendering in --studio-gray-80 (and --studio-gray-70 on hover/focus) instead of the --studio-gray-50 used by the Login screen's centralized TOS treatment.
Root cause: the wrapper element on Magic Login carries three classes — `connect-screen-consent-text` (from <ConsentText>), `magic-login__tos`, and `wp-login__one-login-layout-tos`. The `.wp-login__one-login-layout-tos a { color: inherit }` centralized rule loses to `.connect-screen-consent-text a { color: var(--studio-gray-70) }` at equal specificity because explicit > inherit.
Fix: chain `.magic-login__tos.connect-screen-consent-text a` to raise specificity to 0,3,1 (vs 0,2,1) so the magic-login override wins cleanly without modifying connect-screen styles used by Jetpack Connect / invite flows.
Verified on production (https://wordpress.com/log-in/link) via Playwright: link color goes from rgb(60,67,74) → rgb(100,105,112) matching Login (https://wordpress.com/log-in). Focus and hover states also stay gray-50.
Note: the issue's footer-link checkbox ("Enter a password instead") is no longer reproducible in production — that link already renders gray-90 with underline on both Login and Magic Login. Likely fixed by an earlier audit PR. This PR addresses only the TOS color/focus parity gap.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Jetpack Cloud Live (direct link)
Automattic for Agencies Live (direct link)
Dashboard Live (dotcom) (direct link)
|
Comment cited (0,3,1 > 0,2,1); actual selectors are (0,2,1 > 0,1,1). Behaviour unchanged — the chained-class override still wins by source order/explicit-vs-inherit. CodeRabbit-flagged. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Note in the comment that this override only fires when both classes land on the same element (current callsite: request-login-email-form's <ConsentText className="magic-login__tos wp-login__one-login-layout-tos">). If a future refactor splits the classes, the rule silently no-ops and color regresses. Pre-merge review nit. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Fixes DOTCOM-13796 — Magic Login TOS link was rendering in
--studio-gray-80(and--studio-gray-70on hover / focus) instead of the--studio-gray-50used by the Login screen's centralized TOS treatment.Why
The wrapper element on Magic Login carries three classes —
connect-screen-consent-text(added by<ConsentText>),magic-login__tos, andwp-login__one-login-layout-tos.The centralized
.wp-login__one-login-layout-tos a { color: inherit }rule loses to.connect-screen-consent-text a { color: var(--studio-gray-70) }at equal specificity, because an explicit color value beatsinherit. So the centralized class is present but loses the cascade.How
Chain
.magic-login__tos.connect-screen-consent-text ato raise the override's specificity to(0,3,1)versus the connect-screen rule's(0,2,1). The magic-login override wins cleanly without modifyingconnect-screen-consent-textstyles, which are also used by Jetpack Connect and the invite flows.Same color applied for
:hover,:focus, and:focus-visibleso the centralized treatment is consistent across all interaction states.Testing
Verified on production via Playwright before any code change, then again with the patched CSS injected into the live Magic Login page:
/log-in)/log-in/link) beforergb(100,105,112)(gray-50)rgb(60,67,74)(gray-80)rgb(100,105,112)(gray-50) ✓rgb(80,87,94)(gray-70)rgb(100,105,112)(gray-50) ✓The issue also lists a footer-link checkbox ("Enter a password instead"). Verified separately on production: that link already renders
rgb(29,35,39)(gray-90) with underline on both Login and Magic Login — already matching, no code change needed. Likely addressed by an earlier audit PR. Calling it out here so the issue's first checkbox can be ticked on review.No build performed locally (no yarn / pnpm in this environment); CSS-only change with no syntactic surprises, CI stylelint will catch any issues.
Note: The Linear issue is in In Progress because this PR is opened by a Bug Blitz contributor (Happiness Engineer), not an engineer actively driving the work. Ready for review by the Audit Login, Signup & Auth team — please re-triage if scope or owner is wrong.
🤖 Generated with Claude Code