/* Theme Name: BobNiemeyer Theme URI: https://example.com Author: Denis G Author URI: contact@denisgo.com Description: Campaign site theme for Bob Niemeyer. Version: 0.1.69 Requires at least: 6.4 Requires PHP: 8.0 License: GNU General Public License v2 or later License URI: LICENSE Text Domain: bobniemeyer */ /* ========================================================================== Layout Fix: WordPress's default root spacing (a 24px margin-block-start between the header/main/footer template parts) left a strip of the page's white background showing between the header and whatever full-bleed color starts the page content, breaking the seamless edge-to-edge transition the original site has. That core rule uses :where(), which carries zero specificity, so a plain selector here is enough to override it. ========================================================================== */ .wp-site-blocks > * { margin-block-start: 0; } /* Sticky footer: on short pages (e.g. the stub Articles/Phoenix Project pages),
grows to fill any leftover space below the content so the footer always sits at the bottom of the viewport instead of floating up right under a couple of lines of text. On tall pages,
is already taller than the leftover space has room for, so this has no effect — the footer just follows normally at the true end of the content, and the page scrolls as usual. dvh (falls back to vh where unsupported) accounts for mobile browser chrome showing/hiding as the user scrolls, which vh alone doesn't. */ .wp-site-blocks { display: flex; flex-direction: column; min-height: 100vh; min-height: 100dvh; } .wp-site-blocks > main { flex: 1 0 auto; } /* For logged-in admins, already has margin-top:32px (46px on narrow viewports) added by core for the toolbar — 100vh doesn't know about that, so without this the sticky-footer math is off by exactly that amount and the page gets a few pixels of pointless scroll. Same breakpoint core itself uses for the toolbar's responsive height. */ .admin-bar .wp-site-blocks { min-height: calc(100vh - 32px); min-height: calc(100dvh - 32px); } @media (max-width: 782px) { .admin-bar .wp-site-blocks { min-height: calc(100vh - 46px); min-height: calc(100dvh - 46px); } } /* Always reserve space for the vertical scrollbar, even on short pages (e.g. the stub Articles/Phoenix Project pages) that don't need to scroll. Without this, the page is centered slightly differently depending on whether a given page happens to be tall enough to scroll, causing a small horizontal shift/jump when navigating between pages. overflow-x:hidden guards against horizontal scroll/whitespace from anything that's off-screen but still technically laid out — the Phoenix Project dropdown was the offender (see its own fix further down: it's fixed-width and hidden until hover, but that hidden box still counted toward the page's scrollable width at any viewport narrower than its parent nav item's position plus its own width). overflow-x is only set on html, not body: body also picking up an explicit overflow value (even just on this one axis) breaks the header's position:sticky in Chrome — the moment body has *any* declared overflow, Chrome starts treating it as the sticky element's containing block instead of the viewport, and a sticky element with no scrollable ancestor of its own just scrolls away with the page. */ html { overflow-x: hidden; overflow-y: scroll; } /* ========================================================================== Editor-only: Title field label Now that the page-title-bar block mirrors the post title visually, the block editor shows the real title text twice in a row: the plain native Title field (WordPress's own always-present field for editing post_title, normally styled as a large heading), then the styled green title bar block right below it. Rather than adding a *third*, separate read-only copy, the native field itself is restyled down to a compact "Page Title: " row — same field, same cursor, still the one and only place you type the title, just visually smaller and labeled. The label is a ::before on the wrapper (a plain static string, fine to stay uppercase); the input's own text keeps its typed casing — only the label should shout, not the user's actual title. Both are flex items sharing one row so they sit side by side above the underline. Never touches the front end (these classes don't exist outside the block editor's iframe). ========================================================================== */ .edit-post-visual-editor__post-title-wrapper { display: flex; flex-wrap: wrap; align-items: baseline; gap: 0.4em; max-width: var(--wp--style--global--content-size); margin-left: auto; margin-right: auto; padding-bottom: 0.5rem; border-bottom: 1px solid #ddd; } .edit-post-visual-editor__post-title-wrapper::before { content: "Page Title:"; flex: 0 0 auto; font-size: 0.75rem; font-weight: 700; letter-spacing: 0.08em; text-transform: uppercase; color: #757575; } .edit-post-visual-editor__post-title-wrapper .editor-post-title__input { flex: 1 1 auto; min-width: 0; margin: 0 !important; padding: 0 !important; font-size: 0.75rem !important; font-weight: 700 !important; letter-spacing: 0.08em !important; text-transform: none !important; color: var(--wp--preset--color--dark-green) !important; } /* ========================================================================== Header Fix: the original site painted the header with a fixed-width raster image (background-size:auto; no-repeat; centered) that only covered ~1900px. Any viewport wider than that showed a hard seam where the image ended. A CSS gradient has no fixed width, so it always covers the full header with no seam, at any viewport size or zoom level. ========================================================================== */ /* * Mobile/desktop split at 480px: wide enough to cover every current * mainstream phone in portrait — iPhone SE/12–16 (375–430px CSS width) * and Samsung Galaxy S/A-series (360–480px) — while a rotated phone in * landscape (~650px+) or a tablet gets the desktop header, which has * plenty of room for the nav either way. */ /* The template-part block wraps header.html in its own
, sized to exactly the header's own content height. Sticky positioning is bounded by an element's containing block, so putting it on .site-header (nested one level inside that wrapper) only holds up to the wrapper's own height — past that it detaches and scrolls away. Putting it on the wrapper itself works because the wrapper's parent (.wp-site-blocks) spans the whole page. */ /* The header's own height shrinks as --header-progress animates on scroll. Left on, the browser's scroll-anchoring feature tries to compensate for that layout shift by nudging the scroll position back to keep the page visually stable — which fights small scroll movements (e.g. a single wheel tick) right as the animation starts. Disabling it document-wide is the reliable fix; scoping overflow-anchor to just the header isn't enough, since the anchor node the browser picks to compensate around can be any element below it whose position shifted. */ html { overflow-anchor: none; } header.wp-block-template-part { position: sticky; top: 0; z-index: 100; } /* WordPress pushes the whole page down by the admin toolbar's height for logged-in users (32px, 46px on narrow viewports) so it doesn't cover the top of the page — but that only affects normal document flow. Our sticky header still pins to the literal top of the viewport, which is underneath the toolbar (it's fixed, with a very high z-index), so once scrolled the compact header's top ~32px ends up hidden behind it. Pin below the toolbar instead, matching the same breakpoint WordPress uses for its own responsive toolbar height. */ .admin-bar header.wp-block-template-part { top: 32px; } /* At this same breakpoint, though, WordPress core itself switches #wpadminbar from position:fixed to position:absolute — it stops tracking the viewport and scrolls away with the page like any other content. Reserving 46px for it here (as if it were still pinned) left a 46px gap above the sticky header once scrolled past that point, since by then the toolbar has already scrolled out of view and nothing actually occupies that space any more. Below 782px the toolbar can never be onscreen at the same time as a scrolled sticky header, so there's nothing to clear — same top:0 as the no-admin-bar case. */ @media (max-width: 782px) { .admin-bar header.wp-block-template-part { top: 0; } } /* A soft gradient fade under the header at all times — including at the very top of the page, before any scroll — so the header always reads as a distinct layer above the content rather than blending into whatever color starts the page below it (most noticeably the home hero, which uses this same green). Scrolling adds a firmer box-shadow on top of this once the header goes compact (see .site-header below). */ header.wp-block-template-part::after { content: ""; position: absolute; left: 0; right: 0; bottom: -100px; height: 100px; background: linear-gradient(to bottom, rgba(0, 0, 0, 0.18), transparent); pointer-events: none; } .site-header { --header-progress: 0; background: var(--wp--preset--gradient--header-green); box-shadow: 0 2px 10px rgba(0, 0, 0, calc(var(--header-progress) * 0.25)); } /* WP core duplicates some of the