/* Sticky header base */
.has-sticky-header .site-header {
    position: sticky;
    top: 0;
    z-index: 999;
    transition: background-color 0.3s ease, padding 0.3s ease, box-shadow 0.3s ease;
}

/* Admin bar offset */
.admin-bar.has-sticky-header .site-header {
    top: 32px;
}
@media screen and (max-width: 782px) {
    .admin-bar.has-sticky-header .site-header {
        top: 46px;
    }
}

/* Sticky state: shrink, and lift off the content with a shadow.
 *
 * Deliberately no background-color here. The header template part carries
 * whatever background was chosen for it in the editor, and a rule here would
 * silently beat that choice — making the block's own colour control appear
 * broken to anyone who used it. The same applies to the link colour that used
 * to be forced to white: it assumed a dark header, and turned invisible the
 * moment a site used a light one. Both now come from the block. */
.site-header.is-sticky {
    box-shadow: 0 2px 10px rgba(0, 0, 0, 0.3);
}
.site-header.is-shrunk {
    padding-top: 8px !important;
    padding-bottom: 8px !important;
}

/* Transparent header — stays in flow; the hero is pulled up underneath it.
 *
 * This used to be `position: absolute !important`, which caused two problems.
 * A header built as more than one row put every row at top: 0, stacked on top
 * of each other. And because the header was out of flow on EVERY page it was
 * enabled for, a page whose first block was not a hero simply had its opening
 * content hidden behind the header, with nothing to warn anyone.
 *
 * Inverting it fixes both. The header keeps its natural height, so any number
 * of rows works and the height is whatever it actually is. The overlap is then
 * opt-in: assets/js/sticky-header.js measures the header, publishes it as
 * --ld-header-height, and adds .ld-hero-overlay only when the first block is a
 * cover or a full-height section — something designed to be sat on top of. On
 * any other page the header renders transparently in normal flow and nothing is
 * ever hidden.
 *
 * Transparency stays scoped to :not(.is-sticky) so that scrolling stops
 * suppressing the header's own background rather than swapping in a second
 * colour defined here. Whatever the header block is set to in the editor is
 * what appears once the page moves. */
.has-transparent-header .site-header:not(.is-sticky),
.has-transparent-header.has-sticky-header .site-header:not(.is-sticky),
body.has-transparent-header .site-header.wp-block-group:not(.is-sticky) {
    position: relative;
    z-index: 999;
    background: transparent !important;
}

/* Pull the hero up under the header. Only applied where JS has confirmed the
   first block is something meant to be overlaid. */
.has-transparent-header.ld-hero-overlay .wp-site-blocks > header.wp-block-template-part {
    position: relative;
    z-index: 999;
}
.has-transparent-header.ld-hero-overlay .wp-site-blocks > header.wp-block-template-part + * {
    margin-block-start: calc( -1 * var( --ld-header-height, 0px ) ) !important;
}

/* Without JS the custom property never lands, the calc resolves to 0, and the
   page degrades to a solid header above the content — readable, just not
   overlaid. */

.has-transparent-header .site-header.is-sticky,
.has-transparent-header.has-sticky-header .site-header.is-sticky {
    position: fixed !important;
    top: 0;
    left: 0;
    width: 100%;
}
.admin-bar.has-transparent-header .site-header.is-sticky {
    top: 32px;
}
@media screen and (max-width: 782px) {
    .admin-bar.has-transparent-header .site-header.is-sticky {
        top: 46px;
    }
}
/* Hover on a transparent header, without naming a colour.
 *
 * This used to force var(--wp--preset--color--light) !important, which is a
 * near-white — correct over a dark hero and invisible over a pale one. Fading
 * the inherited colour works on any header, and keeps hover feedback for a
 * client whose hero is a light photograph. */
.has-transparent-header .site-header .wp-block-navigation a:hover {
    opacity: .72;
}

/* The section after the header otherwise picks up the default block gap and
   renders as a strip of page background above the hero — measured at 24px on
   the homepage. Only relevant where the two are meant to touch. */
.has-transparent-header.ld-hero-overlay .wp-site-blocks > header.wp-block-template-part {
    margin-block-end: 0;
}

/* Header content follows the header's own text colour.
 *
 * These rules used to force white. That is Loved Digital's decision about its
 * own dark hero, baked into the product: a client whose hero is a pale
 * photograph gets white icons on white and no way to change it, because
 * !important beats the block's colour control. The same defect as the sticky
 * header background, in a place it was easier to miss.
 *
 * `inherit` is what actually wants to happen. Social icons and the text-link
 * button take the colour set on the header block in the editor, so a light
 * header gets dark icons without anyone writing CSS — and on this site, whose
 * header is set to white text, nothing changes at all.
 *
 * Still needed rather than deletable: both elements otherwise resolve to the
 * page text colour rather than their container's, which is what rendered the
 * footer icons dark-on-dark. */
.has-transparent-header .site-header .wp-social-link,
.has-transparent-header .site-header .wp-block-social-link,
.site-header.is-sticky .wp-social-link,
.site-header.is-sticky .wp-block-social-link {
    color: inherit;
}
.has-transparent-header .site-header .is-style-text-link .wp-block-button__link {
    color: inherit;
}
.has-transparent-header .site-header .is-style-text-link .wp-block-button__link:hover {
    color: inherit;
    opacity: .72;
}