/* * AWT theme baseline overrides on top of @carbon/styles. * * Carbon's pre-built styles.css bundles all four themes (white/g10/g90/g100) * with each defining :root tokens. CSS cascade means the LAST :root (g100, dark) * wins by default — which is why form fields, toggles, etc. were invisible * (dark colors on a white page). Carbon also ships a .cds--white class scope * that re-declares every token with white-theme values; we apply it to * via the body_class filter in functions.php so the entire document inherits * white-theme tokens. * * Everything else here is glue: layout for the fixed UI shell header, list * marker spacing, a Stage 0 menu positioning override (Carbon's React menu * uses floating-ui to portal-position — Stage 1 territory), and a minimal * vertical rhythm between blocks. Stage 1 layout templates will replace the * vertical-rhythm rule with proper Carbon spacing tokens. */ /* -------------------------------------------------------------------------- Autofilled fields keep the theme's colours. Chrome paints an autofilled field with its own pale yellow fill and its own text colour, ignoring `background-color` entirely — the only way to override the fill is a large inset shadow, which is the long-standing workaround. Left alone, an autofilled field in dark mode is pale yellow behind near-white text, which is unreadable, and in light mode it simply looks broken. `-webkit-text-fill-color` is what actually colours autofilled text; `color` is ignored there too. -------------------------------------------------------------------------- */ input:-webkit-autofill, input:-webkit-autofill:hover, input:-webkit-autofill:focus, input:-webkit-autofill:active, textarea:-webkit-autofill, select:-webkit-autofill { -webkit-text-fill-color: var(--cds-text-primary, #161616); caret-color: var(--cds-text-primary, #161616); box-shadow: 0 0 0 100vmax var(--cds-field, #f4f4f4) inset; } /* -------------------------------------------------------------------------- Form controls that no block rendered. Not everything on a page comes from a block. WordPress's password form is core markup; a Custom HTML block can hold a hand-written form; a plugin can print one. All of them arrive as bare browser widgets in the middle of a themed page — different heights, different fonts, and a focus ring that varies by browser, on a theme whose whole claim is consistent accessible defaults. Scoped to the Custom HTML block, which is where hand-written markup lives — and to blocks that bring no stylesheet of their own, because a block with a `