/* ---------------------------------------------------------------------------
 * stiftelsen-haugesund.no — staging parity fixes after
 * WP 6.9.7→7.0.4 / Enfold 6.0.6→7.1.6 / Booking Calendar 10.14.8→11.5
 *
 * Deploy as: wp-content/themes/enfold-projectname/css/np-fixes.css
 * enqueued by the child theme (see fix-child-theme-functions.php).
 *
 * gulp only ever writes the child theme's style.css (from scss/style.scss), so
 * this file is safe from the build. Mirror the same rules into
 * scss/layout/_common.scss if you want the compiled stylesheet to carry them too.
 *
 * Findings 1 and 2 win on specificity alone (a leading #top), so it does not
 * matter that the child theme's CSS is enqueued before Enfold's per-module
 * stylesheets and the Booking Calendar plugin CSS. Finding 4 additionally needs
 * !important — see the note in that block.
 *
 * Covers report findings 1, 2 and 4. Finding 3 (missing <label>/id) cannot be
 * done in CSS — see fix-child-theme-functions.php. Finding 5 (sitemap) needs
 * no fix; it is the staging "Discourage search engines" setting.
 *
 * Status 2026-08-19 round 2: findings 1 and 2 verified live on staging and
 * unchanged below. Only the finding-4 block changed — the first attempt had no
 * effect on the button's colours; this version was measured against production.
 * ------------------------------------------------------------------------- */

/* --- Finding 1: comment-form labels sit beside the input, not above ------- */
/* Enfold 7.1.6 moved its per-module CSS AFTER the child theme + Quick CSS, so
   comments.css `#commentform label{position:absolute;left:245px}` now beats the
   child theme's equal-specificity `#commentform label{position:relative}`.
   `#top ` (2 ids) out-specifies it and is therefore order-proof.
   VERIFIED live on 8 of 8 commentable posts: label back to position:relative,
   833px wide, stacked above its input, rows 96.5/96.5/95.5px, #commentform
   511.5px — identical to production, and all 8 page heights now match. */
#top #commentform label {
	position: relative;
	left: 0;
	top: auto;
	padding-bottom: 5px;
}

/* --- Finding 2: booking form fields narrowed 440px → 340px ---------------- */
/* Booking Calendar 11.5 dropped the `input-xlarge` class and sizes controls
   from `.wpdev-form-control-wrap{width:340px}` instead. Restore 440px only
   above the plugin's 782px breakpoint, so its mobile `width:100%` still wins.
   VERIFIED live on both booking pages: all four text inputs 440×43px and the
   textarea 440×76.5px, matching production; re-checked at a ~500px viewport,
   where fields stay fluid (404px) and the page has no horizontal overflow. */
@media only screen and (min-width: 783px) {
	/* Scoped to the field wrappers, so the captcha row (which also carries
	   .wpdev-form-control-wrap and a narrow .captachinput) is left alone. */
	#top .wpbc_container_booking_form .wpbc_wrap_text,
	#top .wpbc_container_booking_form .wpbc_wrap_textarea {
		width: 440px;
	}

	#top .wpbc_container_booking_form .wpbc_wrap_text > input,
	#top .wpbc_container_booking_form .wpbc_wrap_textarea > textarea {
		width: 440px;
		max-width: 100%;
	}
}

/* --- Finding 4: "Send" button is solid blue instead of pale outlined ------ */
/* WHY THIS IS NOT DONE THROUGH THE PLUGIN'S CSS VARIABLES.
   Booking Calendar 11.5 writes the form's appearance theme as an INLINE style
   attribute on .wpbc_container_booking_form:
     style="--wpbc_form-button-background-color:#066aab;
            --wpbc_form-button-border-color:#066aab;
            --wpbc_form-button-border-size:1px;
            --wpbc_form-button-border-radius:3px;
            --wpbc_form-button-primary-border-style:none; …"
   An inline declaration outranks any normal stylesheet declaration at any
   specificity, so redefining those variables here does nothing. Measured on
   staging 2026-08-19: of seven variables set that way, only the two the inline
   attribute omits (--wpbc_form-button-size-height, -size-font-size) applied.
   Adding !important to the variables gets the radius through but the colours
   arrive blended (rgb(228,238,245) instead of #fdfdfd), because the plugin
   derives button colours from them.
   So set the button's own properties directly, with !important to beat the
   inline attribute.

   MEASURED against production, every property equal:
     background  rgb(253,253,253)                       ✓
     color       rgba(68,68,68,.88)                     ✓
     border      2px solid rgba(238,238,238,.71)        ✓
     radius      5.48438px                              ✓
     box-shadow  rgba(255,255,255,.33) 0 2px 10px 2px   ✓
     font        14.625px / weight 400                  ✓
     size        102.47 × 44px  (production 102.5 × 44) ✓ (0.03px rounding)
   The padding and min-width below are what close the width gap: without them
   the button renders 100px wide against production's 102.5px, because the
   plugin sets min-width:100px and 15px side padding on its own button.

   SAFE: the selector matches exactly ONE element on the page (the Send button);
   page-wide there is a single .btn and it is that button. It is also a no-op on
   production, whose <button class="wpbc_button_light"> matches none of these
   selectors — so this block can ship to production ahead of the plugin update.

   Delete this whole block if the client prefers 11.5's new solid-blue button. */
#top .wpbc_container_booking_form input.wpbc_button,
#top .wpbc_container_booking_form button.wpbc_button,
#top .wpbc_container_booking_form input[type="button"].btn {
	background: #fdfdfd !important;
	background-image: none !important;
	color: rgba(68, 68, 68, .88) !important;
	border: 2px solid rgba(238, 238, 238, .71) !important;
	border-radius: 5.48438px !important;
	box-shadow: 0 2px 10px 2px rgba(255, 255, 255, .33) !important;
	font-size: 14.625px !important;
	font-weight: 400 !important;
	height: 44px !important;
	min-width: 0 !important;
	padding: 0 32.175px !important;
	text-shadow: none !important;
}

/* --- OPTIONAL, DISABLED: booking pages are 116px shorter than production --
 * Not a defect and not enabled. The form fields are pixel-identical to
 * production; the deficit is Booking Calendar 11.5's tighter whitespace around
 * the calendar — its block starts 28.4px higher and the gap between the
 * availability legend and the first field is 101.5px against production's
 * 177.6px. Nothing is missing or misaligned.
 *
 * Uncomment ONLY if pixel parity with the old plugin is wanted. Measured on
 * staging: page height 2078px → 2186px (production 2194px, i.e. 8px short —
 * the last 8px is production's taller field labels, 29.9px vs 17px) and the
 * legend→field gap 101.5px → 182px (production 177.6px).
 *
#top .wpbc_container_booking_form .wpbc_structure_calendar {
	padding-top: 28px;
	padding-bottom: 70.5px;
}
 *
 * A gentler alternative, if the gap merely looks too tight rather than needing
 * to match: padding-bottom: 40px on its own → page height 2128px, gap 151.5px.
 * ------------------------------------------------------------------------- */