/*
 * Force the root font-size to the browser default (16px) on AeroIDX-rendered
 * pages only. The `components.js` widget bundle sizes its internals in `rem`,
 * so a theme that has changed the root font-size will misrender the widget.
 *
 * Selector escalation: started as plain `html` (lost to themes using `:root`),
 * then `html, :root !important` (lost to Bricks injecting inline CSS in <head>
 * AFTER our stylesheet — same specificity, later cascade wins). Settled on
 * `html[lang]` because:
 *   - specificity 0,0,1,1 beats `:root !important` (0,0,1,0) regardless of
 *     cascade order, so we win even if Bricks injects later in <head>;
 *   - WordPress sets the `lang` attribute on every <html> via `language_attributes()`
 *     in the theme's get_header(), so the selector always matches.
 *
 * This file is only enqueued on AeroIDX pages (see Widgets\WidgetLoader), so
 * the blast radius is scoped — the rest of the site is untouched.
 */
html[lang] {
    font-size: 16px !important;
}

/*
 * Full-width IDX pages: clear a fixed/sticky theme header. The offset value is
 * measured at runtime by assets/js/page-layout.js and published as
 * --aeroidx-header-offset on <body>. Defaults to 0 so this is inert when the
 * script is absent (e.g. /details/).
 *
 * HOW AN AUTHOR OVERRIDES THIS, and why the old advice here was wrong.
 *
 * This comment used to say admins could override padding-top from "the Theme
 * Integration Custom CSS box, which loads after this stylesheet". That box was
 * removed — the plugin no longer stores or outputs custom CSS — so the
 * load-order guarantee it relied on went with it. An author's rule now lives in
 * their theme or in WordPress' Additional CSS, and whether it beats this
 * declaration depends on enqueue order nobody promises.
 *
 * So point them at the value instead of the property: setting
 * --aeroidx-header-offset overrides the number this rule reads, at any
 * specificity, with no cascade race. The Appearance screen and README.md both
 * say so, and Settings\ThemePanelMarkupTest pins that they keep saying it.
 */
body.aeroidx-page {
    padding-top: var(--aeroidx-header-offset, 0px);
}

/**
 * The server-rendered listing heading, description and photos
 * (Seo\ListingSeoBody).
 *
 * Clipped, NOT `display: none` and NOT `visibility: hidden`. The block exists so
 * that something reading the raw HTML — an SEO audit tool, a crawler that does
 * not execute JavaScript — finds an h1, the property description and real <img>
 * tags, all three of which the widget otherwise draws only after its bundle
 * boots. Hiding it outright is the one thing that would defeat that, because
 * several of those readers skip content they can tell is not rendered.
 *
 * It is hidden at all because the widget draws the same three things again,
 * visibly and with the theme's own styling. Without this rule the client's page
 * would show its headline, description and photos twice.
 *
 * This is the standard visually-hidden recipe: a 1px clipped box, out of flow
 * for layout purposes but still rendered — which is what keeps it readable to a
 * crawler. NOT in the accessibility tree, though: Seo\ListingSeoBody marks the
 * wrapper aria-hidden, deliberately, so a screen reader running on top of a
 * browser that executed the bundle does not announce the address, the whole
 * description and every photo a second time. The usual visually-hidden recipe
 * keeps that content announced; this one is the exception, and the aria-hidden
 * is the reason.
 */
.aeroidx-listing-seo {
    position: absolute;
    width: 1px;
    height: 1px;
    margin: -1px;
    padding: 0;
    overflow: hidden;
    clip: rect(0, 0, 0, 0);
    clip-path: inset(50%);
    white-space: nowrap;
    border: 0;
}