/* Theme Name: Smith St Hotel Theme URI: https://www.smithsthotel.com.au/ Description: Dark child theme of Twenty Twenty-Five for Smith St Hotel. Flips the parent's base and contrast presets so the whole site renders red on black, and hands the SPG Events guide its accent colours. Author: Studio Calero Template: twentytwentyfive Version: 0.1.0 Requires at least: 6.6 Requires PHP: 8.2 Text Domain: smith-st */ /* --------------------------------------------------------------------------- Type scale --------------------------------------------------------------------------- Sohne Mono sets much larger than a proportional face at the same pixel size — every glyph carries the widest character's advance, so a line of it occupies far more space than the number suggests. At the inherited 16px the whole site read oversized. One lever, at the root: everything in the theme AND the plugin is sized in rem, so type and the spacing between it come down together and the rhythm is kept. Scaling the font sizes alone would have left the gaps where they were. --------------------------------------------------------------------------- */ html { font-size: 87.5%; /* 14px */ } /* * The events plugin ships deliberately theme-neutral: it inherits font and colour from the page * and exposes its own custom properties. Everything below is the theme filling those in — the * plugin has no idea the site is dark. * * `body` prefix only for specificity: the plugin defines these on `.spg-root`, and stylesheet * load order between a plugin and a theme is not guaranteed. * * ONE selector covers every plugin surface — guide, specials board and single event page — so a * new component cannot quietly keep the light-mode defaults. */ body .spg-root { --spg-accent: var(--wp--preset--color--contrast, #ec1f28); --spg-accent-contrast: var(--wp--preset--color--base, #1a0c0c); /* * The plugin derives muted text and borders by fading currentColor toward TRANSPARENT. * That works when the text is near-white on black (white fading to black = grey, still * legible). With red text it collapses: faded red over near-black measured 1.07:1 — * effectively invisible, and it was carrying the dates, the meta lines and the dish copy. * * So on this theme muted text fades toward the light neutral instead of toward the * background, which keeps it in the red family but legible (~7:1). */ --spg-page-bg: var(--wp--preset--color--base, #1a0c0c); --spg-muted: color-mix(in srgb, var(--wp--preset--color--contrast, #ec1f28) 55%, #f2f0ec); --spg-border: color-mix(in srgb, var(--wp--preset--color--contrast, #ec1f28) 38%, transparent); } /* --------------------------------------------------------------------------- High-contrast mode --------------------------------------------------------------------------- Overriding the two palette PRESETS flips everything at once — theme chrome, blocks and the events plugin — for the same reason the dark palette works: every foreground colour on the site resolves through `contrast`, every background through `base`. `html[data-contrast="high"]` is specificity 0,1,1 against the `:root` rule WordPress emits for presets (0,1,0), so it wins without !important. --------------------------------------------------------------------------- */ html[data-contrast="high"] { --wp--preset--color--base: #000000; --wp--preset--color--contrast: #FFFFFF; /* A near-black surface tint, so panels read as raised rather than as holes. */ --wp--preset--color--accent-5: #1A1A1A; --wp--preset--color--accent-4: #A6A6A6; /* Link accent lightened for a black ground; the dark blue used on white vanishes here. */ --wp--preset--color--accent-3: #8AB4FF; } /* Muted text is a real grey here, not a tint of the brand red: this mode exists to be read. */ html[data-contrast="high"] body .spg-root { --spg-page-bg: #000000; --spg-muted: #CCCCCC; --spg-border: rgba(255, 255, 255, 0.35); } /* Images carry their own contrast; leave them alone. */ /* ---- page titles ---- */ /* The guide is alignwide (1180px) while the title sits in the constrained column (645px), so a left-aligned title reads as pushed off to one side of the listing beneath it. Centring settles it over the content rather than widening the title to match. */ .home .wp-block-post-title, .page-template-default .wp-block-post-title { text-align: center; } /* ---- header nav ---- */ /* * Uppercase. Sohne Mono is already a fairly mechanical face, and caps push the nav further from * the editorial voice of the guide below it — which is what you want from navigation: a label, * not a sentence. * * Tracking is NOT optional here. Uppercase at the same letter-spacing as lowercase sets too * tight to read at a glance, and a monospace face makes it worse because the caps already fill * their advance. 0.06em is measured against the nav's 15.75px, not guessed. * * Applied with text-transform rather than by retyping the labels, so the nav block still reads * "Pub du Jour" in the editor and in the accessibility tree. A screen reader announcing * "P-U-B" because someone typed the label in caps is a real failure mode. */ .wp-block-navigation .wp-block-navigation-item__content { text-transform: uppercase; letter-spacing: 0.06em; } /* The nav inherits `contrast`, which is the brand red — fine, but the current page needs to be distinguishable from the rest without relying on colour alone. */ .wp-block-navigation .wp-block-navigation-item.current-menu-item > a, .wp-block-navigation .wp-block-navigation-item.current_page_item > a { text-decoration: underline; text-underline-offset: 0.35em; text-decoration-thickness: 2px; } /* ---- the toggle ---- */ .ssh-contrast { position: fixed; right: 1rem; bottom: 1rem; z-index: 999; display: inline-flex; align-items: center; gap: 0.5rem; padding: 0.6rem 0.9rem; font: inherit; font-size: 0.8125rem; font-weight: 600; line-height: 1; cursor: pointer; border-radius: 999px; color: var(--wp--preset--color--base, #1a0c0c); background: var(--wp--preset--color--contrast, #ec1f28); border: 2px solid var(--wp--preset--color--contrast, #ec1f28); } .ssh-contrast:hover { color: var(--wp--preset--color--contrast, #ec1f28); background: var(--wp--preset--color--base, #1a0c0c); } /* A visible, high-contrast focus ring in BOTH palettes — the control that makes the site accessible has to be reachable by keyboard without hunting for it. */ .ssh-contrast:focus-visible { outline: 3px solid var(--wp--preset--color--contrast, #ec1f28); outline-offset: 3px; } .ssh-contrast__icon { display: inline-flex; } @media (max-width: 40rem) { .ssh-contrast__text { /* Icon-only on small screens; the accessible name still carries the action. */ position: absolute; width: 1px; height: 1px; overflow: hidden; clip-path: inset(50%); white-space: nowrap; } .ssh-contrast { padding: 0.7rem; } } @media print { .ssh-contrast { display: none; } } /* --------------------------------------------------------------------------- Footer --------------------------------------------------------------------------- */ /* * Carries .spg-root, so it inherits the same --spg-accent / --spg-muted / --spg-border the * guide uses and flips with the high-contrast toggle without knowing the toggle exists. */ .ssh-footer { container-type: inline-size; border-top: 1px solid var(--spg-border); padding-top: 2.5rem; /* * 14px, not the inherited 16. Sohne Mono is a wide face — every glyph carries the widest * character's advance — so a four-column footer that fits comfortably in a proportional * font does not in this one. At 16px "Tue - Thu" and "12pm - 11pm" both wrapped inside a * 200px column; at 14px they do not. Measured, not guessed. */ font-size: 0.875rem; line-height: 1.6; } .ssh-footer__cols { display: grid; /* auto-fit, not auto-fill: four columns should share the row evenly rather than leave a phantom fifth column's worth of space on the right. 11rem, measured: four columns plus three 2rem gaps is 800px, inside the 56rem (896px) the footer shares with the guide above it. At 13rem they needed 928px and wrapped to 2x2. */ grid-template-columns: repeat(auto-fit, minmax(11rem, 1fr)); gap: 2.5rem 2rem; } /* * Four EQUAL columns cannot work here: three of them hold short strings and the fourth holds * email addresses more than twice as wide. Giving Contact 1.35fr sizes the row to its real * content rather than to an average. Only applied once there is room for four across; below * that the auto-fit rule above takes over and they stack. */ @container (min-width: 52rem) { .ssh-footer__cols { grid-template-columns: 1fr 1fr 1fr 1.35fr; } } .ssh-footer__heading { margin: 0 0 0.9rem; font-size: 0.6875rem; font-weight: 700; letter-spacing: 0.12em; text-transform: uppercase; color: var(--spg-muted); } .ssh-footer__subheading { margin: 1.4rem 0 0.5rem; font-size: 0.6875rem; font-weight: 700; letter-spacing: 0.12em; text-transform: uppercase; color: var(--spg-muted); } .ssh-footer__address { margin: 0 0 1rem; font-style: normal; line-height: 1.55; } .ssh-footer__socials, .ssh-footer__contact { margin: 0; padding: 0; list-style: none; line-height: 1.75; } .ssh-footer a { color: inherit; text-decoration: none; border-bottom: 1px solid transparent; } /* * An email address is one unbreakable word. "bookings@smithsthotel.com.au" measures 232px in * 14px mono and was running 32px past its column — invisible here only because Contact is the * last column and it spilled into the page margin. Breaking anywhere is ugly but bounded; * silently overflowing the grid is not. */ .ssh-footer__contact a { overflow-wrap: anywhere; } .ssh-footer a:hover, .ssh-footer a:focus-visible { border-bottom-color: currentColor; } /* * Days and hours as a description list. The two columns are separate cells rather than one * string so they stay aligned however long a day range is — "Tue - Thu" and "Fri" must not * put their hours in different places. */ .ssh-footer__hours { margin: 0; } .ssh-footer__hours-row { display: grid; /* 5rem holds "Tue - Fri" at 14px mono with nothing to spare on either side. */ grid-template-columns: 5rem 1fr; gap: 0.5rem; line-height: 1.75; } .ssh-footer__hours-row dt { color: var(--spg-muted); } .ssh-footer__hours-row dd { margin: 0; } .ssh-footer__bottom { margin-top: 3rem; padding-top: 1.5rem; border-top: 1px solid var(--spg-border); } .ssh-footer__copyright { margin: 0 0 0.9rem; font-size: 0.8125rem; letter-spacing: 0.01em; color: var(--spg-muted); } /* * The Acknowledgement is capped at a readable measure and NOT shrunk to a legal-notice size. * It is a statement the venue is making, not fine print. */ .ssh-footer__acknowledgement { margin: 0; max-width: 46rem; font-size: 0.875rem; line-height: 1.65; color: var(--spg-muted); } @container (max-width: 34rem) { .ssh-footer__cols { grid-template-columns: 1fr; gap: 2rem; } .ssh-footer__hours-row { grid-template-columns: 5.5rem 1fr; } } /* --------------------------------------------------------------------------- Site logo --------------------------------------------------------------------------- */ .wp-block-site-logo img { display: block; /* Height-led, not width-led: the lockup is an arch, so its HEIGHT is what sets how tall the header bar becomes. Width follows from the aspect ratio. */ height: auto; max-width: 200px; } .wp-block-site-logo a { display: block; border: 0; } /* * THE LOGO STAYS RED IN HIGH CONTRAST. It used to be inverted to white, on the reasoning that a * red mark would be the one element failing the contrast the toggle exists to provide. * * That was overcautious. WCAG 1.4.3 explicitly exempts logotypes: "Text that is part of a logo * or brand name has no contrast requirement." A brand mark is not text a reader has to parse, * and stripping the one piece of brand identity out of the accessible view is a worse outcome * than the ratio it was buying. * * Everything that IS text still flips: the toggle's job is the copy, not the logo. */ @media (max-width: 600px) { .wp-block-site-logo img { max-width: 150px; } } /* --------------------------------------------------------------------------- Classic-editor content --------------------------------------------------------------------------- The site moved to the Classic Editor, so page content is plain HTML and shortcodes rather than blocks. Two things silently stopped happening: 1. WordPress no longer enqueues `wp-block-library` on these pages, because there are no blocks to need it. That stylesheet was where the buttons got their pill shape — theme.json sets their colour and padding but no radius, so they flattened to square corners. 2. The block renderer used to ADD `is-layout-flex` to `.wp-block-buttons` at output time. It is not in the saved markup, so it is simply gone. Restating both here means the existing button markup keeps working and an editor can paste the same HTML, without pulling in a stylesheet the site otherwise has no use for. --------------------------------------------------------------------------- */ .wp-block-buttons { display: flex; flex-wrap: wrap; gap: 0.6rem; margin: 1.5rem 0; } .wp-block-button__link, .wp-element-button { display: inline-block; border-radius: 9999px; text-decoration: none; border: 0; cursor: pointer; } /* Same reason: the separator's rule came from the block stylesheet. */ .wp-block-separator { border: 0; border-top: 1px solid var(--spg-border, currentColor); margin: 2.5rem 0; opacity: 1; } /* Alignment utilities that block content got for free. */ .has-text-align-center { text-align: center; } .has-text-align-right { text-align: right; } /* --------------------------------------------------------------------------- Menu heading --------------------------------------------------------------------------- "Menu" is set at the same size as the page title above it, because on the Pub du Jour page the two are peers: the specials and the regular menu are two halves of the same offer, not a section inside one of them. This lives in the THEME, not the plugin. A section heading that matches the page title is a choice about THIS page, and the plugin has to stay sensible for five more venues that may lay their menu out differently. --------------------------------------------------------------------------- */ /* The Food page has TWO section headings and they are peers: the specials board and the regular menu. They were only ever consistent by accident — "Pub du Jour" used to be the page's own h1, so nobody had to style it. Renaming the page to Food took that h1 away and left the board unlabelled, which is how the brand silently disappeared off the page. Both are styled here now. */ .spg-menu__heading, .spg-specials__heading { font-size: var(--wp--preset--font-size--xx-large); line-height: 1.05; margin-top: 3rem; /* Centred, like the page title it is now the same size as. Two 42px headings on one page aligned differently reads as a mistake rather than a hierarchy. */ text-align: center; } /* --------------------------------------------------------------------------- Functions: the three spaces --------------------------------------------------------------------------- Three rooms laid out as a SET rather than a vertical list of headings. They are alternatives to choose between, and a stack of h3s makes them read as a sequence to work through. The page also sat in the 645px content column while the footer beneath it ran to 896px, which made Functions look narrower than every other page on the site. The markup wraps this in .alignwide to match. --------------------------------------------------------------------------- */ /* * One column for the whole page body, 64rem — the same 896px the guide and the footer use. * * Without it the headings sat in the theme's 645px content column while the cards broke out to * the full 1340px wide width, so "The spaces" started 230px to the right of the spaces it was * labelling. Sharing a container is what makes a heading look attached to its content. */ /* .alignwide.ssh-functions, not .ssh-functions alone: WordPress generates `.is-layout-constrained > .alignwide { max-width: }` at 0,2,0, which outranks a single class and stretched this to 1180px instead of the intended 896. */ .alignwide.ssh-functions { max-width: 64rem; margin-inline: auto; } .ssh-spaces { display: grid; /* auto-fit so three cards share the row and two would too, rather than leaving a phantom third column's worth of space. */ grid-template-columns: repeat(auto-fit, minmax(15rem, 1fr)); gap: 1.25rem; margin: 1.75rem 0 3rem; padding: 0; list-style: none; } .ssh-space { padding: 1.4rem 1.5rem 1.6rem; border-radius: 8px; /* currentColor at 5%, the same tint the guide's day panels use, so this belongs to the same system and adapts to either palette unaided. */ background: color-mix(in srgb, currentColor 5%, transparent); } .ssh-space__name { margin: 0 0 0.15rem; font-size: 1.25rem; line-height: 1.2; } .ssh-space__style { display: block; margin: 0 0 0.7rem; font-size: 0.6875rem; font-weight: 700; letter-spacing: 0.1em; text-transform: uppercase; color: var(--spg-muted); } .ssh-space__copy { margin: 0; font-size: 0.9375rem; line-height: 1.55; } /* The enquiry block closes the page, so it gets air above it rather than running on from the last card. */ .ssh-enquire { max-width: 42rem; margin-top: 1rem; } /* --------------------------------------------------------------------------- Gallery --------------------------------------------------------------------------- */ .ssh-gallery { display: grid; /* auto-fit against a sensible minimum rather than a hard column count, so the same gallery works at 896px and on a phone without a breakpoint for every column choice. The shortcode's `columns` sets the minimum width that implies. */ grid-template-columns: repeat(auto-fit, minmax( clamp(11rem, calc((100% - 2rem) / var(--ssh-gallery-columns, 3)), 100%), 1fr)); gap: 0.75rem; margin: 2rem 0 3rem; padding: 0; list-style: none; } .ssh-gallery__item { margin: 0; overflow: hidden; border-radius: 6px; /* A fixed ratio so a mix of portrait and landscape shots still makes a tidy grid. The photos here are 3:2 and 4:5 in roughly equal numbers; letting each keep its own ratio gives a ragged grid with holes in it. */ aspect-ratio: 4 / 3; background: color-mix(in srgb, currentColor 6%, transparent); } .ssh-gallery__img { display: block; width: 100%; height: 100%; /* cover, so the fixed ratio crops rather than distorts. */ object-fit: cover; } /* --------------------------------------------------------------------------- Section spacing in page content --------------------------------------------------------------------------- Measured on the Contact page before this: 17px above every heading and 17px below it. A heading with equal space either side belongs to neither the thing above nor the thing below, so six distinct sections read as one continuous column of text. The fix is asymmetry, not a rule — the guide and the specials board both had their dividing lines deliberately removed, and space does the same job without drawing anything. Roughly five times more above than below, so each heading binds downward to the content it names. Excludes .spg-menu__heading and .spg-specials__heading, which the plugin positions itself. --------------------------------------------------------------------------- */ .wp-block-post-content h2:not(.spg-menu__heading):not(.spg-specials__heading) { margin-top: 3.5rem; margin-bottom: 0; } /* The first heading must NOT push away from the page title above it — UNLESS it is one of the plugin's section headings, which are set at the page-title size. Two 42px headings stacked with no gap read as one two-line title: the Food page opened "Food / Pub du Jour" looking like a single heading rather than a page name followed by its first section. */ .wp-block-post-content > h2:first-child:not(.spg-specials__heading):not(.spg-menu__heading), .wp-block-post-content > *:first-child h2:first-child:not(.spg-specials__heading):not(.spg-menu__heading) { margin-top: 0; } /* Pull whatever follows a heading up against it. */ .wp-block-post-content h2:not(.spg-menu__heading):not(.spg-specials__heading) + * { margin-top: 0.5rem; } /* --------------------------------------------------------------------------- Mobile navigation overlay --------------------------------------------------------------------------- Left alone, WordPress opens this as a WHITE panel with BLACK links — measured, not assumed — on a site that is red on near-black. The block's overlay colours are now set to the `base` and `contrast` presets in parts/header.html, which is what makes it follow the high-contrast toggle: the toggle redefines those two presets, so the overlay flips with everything else and knows nothing about it. What is left is size. The desktop nav is 15.75px, which is right for a row of links across a header and far too small for a full-screen menu you tap with a thumb. --------------------------------------------------------------------------- */ .wp-block-navigation__responsive-container.is-menu-open { /* Cover the admin bar too, or it sits on top of the close button. */ padding-top: calc(2rem + var(--wp-admin--admin-bar--height, 0px)); /* * 🔴 The alignment variables belong HERE, on the outermost element, not on the link * container. Custom properties inherit DOWNWARDS only — setting them on * .wp-block-navigation__container left the wrapper ABOVE it still reading * `--navigation-layout-align: flex-end` from `.items-justified-right.is-vertical`, so the * links were flush left within a block that was itself pushed right. */ /* Cross axis only. In a column, `align` is the HORIZONTAL edge — flex-end puts the links on the right, matching where they sit in the desktop header. `justify` stays at the start because in a column it controls the VERTICAL, and flex-end there would drop the whole menu to the bottom of the panel. */ --navigation-layout-align: flex-end; --navigation-layout-justify: flex-start; --navigation-layout-justification-setting: flex-start; } /* * The open menu is a max-width column that CENTRES itself in the panel. * * 🔴 The element doing the centring is `.wp-block-navigation__responsive-close` — measured, by * walking the ancestor chain and finding which box was 1340px wide with 144px auto margins. It * is easy to miss because the name sounds like the close BUTTON; it is actually the outer * wrapper. Targeting only the dialog and the content left the centring untouched and the menu * still floating in the middle of a full-width overlay. * * 1340px is the theme's wide size. At a real phone width the column is wider than the screen, * so it fills and the point is moot — this shows up on a tablet or a large phone in landscape. */ .wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation__responsive-close, .wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation__responsive-dialog, .wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation__responsive-container-content { align-items: flex-end; justify-content: flex-start; margin-inline: 0; width: 100%; max-width: none; } /* * 🔴 THE OVERLAY DOES NOT STACK ITS LINKS BY ITSELF. * * WordPress emits no `flex-direction` rule for the navigation anywhere — checked every inline * style block on the page — so the open menu keeps whatever direction the header row gave it, * which is a horizontal row squeezed into a full-screen panel. * * The block's own layout rule makes it worse: * .wp-container-core-navigation-is-layout- { gap: 1.5rem; justify-content: flex-end } * Right-aligned is correct for a row of links in a header. Turned into a column it means * "push everything to the BOTTOM", so the fix has to reset justify-content too, not just the * direction. */ .wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation__container { flex-direction: column; flex-wrap: nowrap; /* Top of the panel, not the bottom — see above. */ justify-content: flex-start; /* RIGHT, matching where the links sit in the desktop header. * * 🔴 Setting `align-items` alone does NOT work. WordPress drives nav alignment through * custom properties — `.items-justified-right { --navigation-layout-justify: flex-end }` * and `.items-justified-right.is-vertical { --navigation-layout-align: flex-end }` — which * the container consumes as `align-items: var(--navigation-layout-align)`. There is no * `align-items` declaration anywhere to outrank, so searching the stylesheets for one finds * nothing and the override silently loses to a variable set higher up. * * Overriding the VARIABLE is how this is meant to be steered. The direct properties below * stay as a fallback for any consumer that does not read the var. */ --navigation-layout-align: flex-end; align-items: flex-end; text-align: right; gap: 0.25rem; width: 100%; /* * Clear of the close button. It sat 14px above the first link and shared its exact right * edge, so the X read as another item in the list rather than a control over it. * * The space goes on the LIST, not on the panel's padding: WordPress sets that padding with * `clamp(1rem, var(--wp--style--root--padding-top), 20rem)` at a specificity that a plain * override loses to — measured at 14px when the theme asked for 2rem. Pushing the list down * needs no such fight. */ margin-top: 3.5rem; } /* * The long selector is not decoration. WordPress ships * .wp-block-navigation__responsive-container.is-menu-open:where(:not(.disable-default-overlay)) * .wp-block-navigation__responsive-container-content .wp-block-navigation-item__content * { padding: 0 } * at specificity 0,4,0 — the :where() contributes nothing, the four classes do. A shorter * selector at 0,3,0 loses, and loses SILENTLY: `display` applied, `padding` did not, and the * links stayed 29px tall while everything looked like it had worked. */ .wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation__responsive-container-content .wp-block-navigation-item .wp-block-navigation-item__content { display: block; /* 44px is the usual floor for a thumb. */ padding: 0.6rem 0; font-size: 1.5rem; letter-spacing: 0.04em; } /* The open and close controls inherit `currentColor`, so they follow the palette without being named. Sized to a real tap target rather than the 24px default. */ .wp-block-navigation__responsive-container-open, .wp-block-navigation__responsive-container-close { /* 0.75rem, not 0.5: with a 1.75rem icon that lands the whole control at 45px, over the 44px floor the menu links already meet. At 0.5rem it measured 39px — the one control on the overlay that was harder to hit than the things it sits beside. */ padding: 0.75rem; color: inherit; } /* A little in from the corner, so the X is not jammed against two edges at once. */ .wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation__responsive-container-close { top: 0.5rem; right: 0; } .wp-block-navigation__responsive-container-open svg, .wp-block-navigation__responsive-container-close svg { width: 1.75rem; height: 1.75rem; fill: currentColor; } /* --------------------------------------------------------------------------- Focus and tap highlight --------------------------------------------------------------------------- The box around a link on click or tap is TWO different browser defaults, and only one of them is the focus ring: 1. `-webkit-tap-highlight-color` — the grey rounded rectangle iOS and Android flash over a link the moment you touch it. Nothing to do with focus, and it looks wrong on a dark site. 2. The focus ring drawn on :focus. Chrome and Safari already limit their own ring to :focus-visible, but anything that takes focus on click can still show one. BOTH ARE REMOVED ONLY FOR POINTER INPUT. `:focus-visible` is left alone and given a deliberate ring below, because a keyboard user who cannot see where they are has no way to use the site at all. `outline: none` on its own, with nothing replacing it, is the single most common accessibility mistake on the web — this is not that. --------------------------------------------------------------------------- */ html { -webkit-tap-highlight-color: transparent; } /* Pointer input: no ring. The :not(:focus-visible) is what keeps the keyboard case working — it matches only when the browser decided a ring was unwanted. */ a:focus:not(:focus-visible), button:focus:not(:focus-visible), .wp-element-button:focus:not(:focus-visible), .wp-block-button__link:focus:not(:focus-visible), [tabindex]:focus:not(:focus-visible) { outline: none; box-shadow: none; } /* Keyboard input: a clear ring, in whatever colour the palette is currently using, so it works in both the red and the high-contrast themes unaided. */ a:focus-visible, button:focus-visible, .wp-element-button:focus-visible, .wp-block-button__link:focus-visible, [tabindex]:focus-visible { outline: 2px solid currentColor; outline-offset: 3px; border-radius: 2px; } /* --------------------------------------------------------------------------- Header on mobile: logo centred, menu button to the right --------------------------------------------------------------------------- 781px, not an arbitrary number: WordPress switches the nav to its overlay below 782px, so the logo starts centring on exactly the width where the row of links becomes a hamburger. Picking any other breakpoint leaves a gap where the layout is neither one thing nor the other. 🔴 The nav is pulled out of flow WITHOUT `transform`. A transform on an ancestor makes it the containing block for `position: fixed` descendants, and the menu overlay is fixed — centring the button with translateY would have quietly broken the full-screen menu into a small box in the corner. --------------------------------------------------------------------------- */ @media (max-width: 781px) { /* Doubled class for specificity. WordPress emits .wp-container-core-group-is-layout- { justify-content: space-between } at 0,1,0 — exactly the same as a single .ssh-header — so which one wins comes down to source order between an inline