/* ------------------------------------------------------------------
   Heyrnarstöðin — visual parity with the previous Floox / Helix3 site.

   Loaded last by templates/shaper_helixultimate/index.php via
   $theme->add_css('custom.css'), so it overrides template.css without
   touching any vendor file.
   ------------------------------------------------------------------ */


/* 1. Transparent overlay header
   -----------------------------
   Floox rendered #sp-header as:
       position: absolute; top: 50px; background: transparent; z-index: 99
   with the old site's own custom CSS forcing  top: 0; height: 80px.
   The logo/menu row therefore sat ON TOP of the slider.

   Helix Ultimate ships  #sp-header { position: relative }  which keeps the
   header in normal flow and pushes the slider down instead. */

#sp-header {
	position: absolute;
	top: 0;
	left: 0;
	width: 100%;
	background: transparent;
	box-shadow: none;
}

/* Helix's sticky state would otherwise inherit the transparent background.
   The old site used #576067 for the fixed header, so keep that available
   if sticky_header is ever switched back on. */
#sp-header.header-sticky,
#sp-header.menu-fixed {
	position: fixed;
	background: #576067;
}


/* 2. Header content colour over the slider
   ----------------------------------------
   On the old site the home page (itemid-543) drew its menu, toggler and
   contact icons in white over the dark slider, while every other page used
   the muted grey. Home on this site is itemid-109. */

body.itemid-109 .sp-megamenu-parent > li > a,
body.itemid-109 .sp-megamenu-parent > li > span {
	color: #fff;
}

body.itemid-109 .sp-megamenu-parent > li:hover > a,
body.itemid-109 .sp-megamenu-parent > li:focus > a {
	color: #fff;
	opacity: .8;
}

body.itemid-109 #offcanvas-toggler .burger-icon span {
	background-color: #fff;
}

/* Logo: black is the site-wide default (legible over the light hero images on
   every subpage); the home page sits over the dark slider, so swap in the white
   wordmark there. The old site achieved this via a retina srcset trick, which
   showed a white-on-white logo on non-retina screens — this is density-agnostic. */
body.itemid-109 #sp-logo .logo-image,
body.itemid-109 #sp-logo .logo-image-phone {
	content: url("../../../images/2023/heyrnarst_logo_hvitt_web.png");
}

body.itemid-109 .sp-contact-info,
body.itemid-109 .sp-contact-info a,
body.itemid-109 .icon-top-wrapper i {
	color: #fff;
}

/* No dropdown colour override is needed here: the white-text rules above use
   `>` combinators that only reach TOP-LEVEL items, so submenu links already
   take menu_dropdown_text_color (#484848) and the green hover. An override at
   this depth would be specificity 0,4,3 and would beat Helix's own 0,4,2 hover
   rule, killing the green highlight on the home page. */


/* 3. Menu alignment
   -----------------
   Floox floated the menu hard right against the container edge. Helix applies
   `justify-content: space-between` to the wrapper whenever the header carries
   the .header-with-social class, which pulls the menu left — and that class is
   present even with the social icons switched off. */

#sp-menu .sp-megamenu-wrapper,
#sp-menu.menu-with-social .sp-megamenu-wrapper {
	justify-content: flex-end;
}

/* Social icons are switched off, but Helix still renders an empty .social-wrap
   whose 60px padding-left pushes the menu off the right edge. The element also
   carries Bootstrap's .d-flex (display:flex !important), so `display:none`
   would not win — zeroing the padding is what collapses it. Scoped to the
   empty case so enabling the icons later restores the original spacing. */
#sp-menu .social-wrap:not(:has(*)) {
	padding-left: 0;
}


/* 4. Menu typography
   ------------------
   Floox rendered top-level items semibold and in sentence case rather than
   Helix's uppercase default, with 3px of breathing room either side. */

.sp-megamenu-parent > li > a,
.sp-megamenu-parent > li > span {
	text-transform: none;
	font-weight: 600;
}

.sp-megamenu-parent > li > a {
	letter-spacing: 1.35px;
}

.sp-megamenu-parent > li {
	margin: 0 3px;
}


/* 5. Form controls
   ----------------
   Browsers do not inherit font on form elements, so the contact fields fell
   back to the UA font at 400 weight (textarea at 12px). The old site set these
   explicitly and measured Raleway 16px/600 on both inputs and textareas.
   Font only — the old rounded grey field styling is not reproduced here. */

input,
textarea,
select,
.sppb-form-control {
	font-family: inherit;
	font-size: 16px;
	font-weight: 600;
}

/* The footer copyright rendered at 400 on the old site; here it would otherwise
   inherit the body weight of 500. The link inside it stays at 700 either way. */
#sp-footer .sp-copyright {
	font-weight: 400;
}


/* 6. Contact form — the bits SP Page Builder has no setting for
   -------------------------------------------------------------
   Colours, radius, field heights and the button are set on the addon itself
   (see _migration/fix-contact-form-styling.php). Field width and the inner
   padding have no corresponding setting, and the old site forced them with
   bare `input { … !important }` rules that hit every input on the site —
   including search and login. Scoped to the contact addon instead. */

/* Field width has no addon setting, and SPPB's own rules are ID-scoped, so
   these need !important to win.

   The .sppb-form-group in the middle of the selector is load-bearing: Helix's
   template.css carries
       input[type="text"]:not(.form-control) { padding: .5rem !important }
   at specificity 0,2,1. A plain `.sppb-addon-ajax-contact .sppb-form-control`
   is 0,2,0, so even with !important it LOST and the inputs kept an 8px inset
   while the textarea (matched by a separate element-qualified rule) got 20px.
   Going through .sppb-form-group makes this 0,3,0 and wins outright. */
.sppb-addon-ajax-contact .sppb-form-group .sppb-form-control {
	width: 275px !important;
	max-width: 100%;
	padding: 0 0 0 20px !important;
}

/* The per-page CSS migrated from the old site sets
   `.sppb-form-group:last-child textarea { min-height: 100px }`. On the old site
   the template's Custom CSS overrode that back to 60px; without it the textarea
   renders two-thirds taller than it used to. */
.sppb-addon-ajax-contact .sppb-form-group textarea.sppb-form-control {
	height: 60px !important;
	min-height: 60px !important;
	max-height: 60px !important;
	padding: 15px 0 0 20px !important;
	line-height: 1;
}

/* Breathing room under the form's heading. */
.sppb-addon-ajax-contact .sppb-addon-title {
	margin-bottom: 15px;
}

/* SPPB 6 puts a 15px gutter on grid columns; SPPB 3 did not. On the HOME page
   the form sits in a narrow col-md-3, and that gutter shrinks it from 285px to
   255px — so the 275px fields get clamped by max-width and the whole form sits
   15px right of where it used to. Cancelling the gutter there restores both.

   Scoped to home deliberately: the subpage forms sit in a much wider column
   that never hits the clamp, and removing their gutter pushes them ~20px left
   of where the old site had them. */
body.itemid-109 [class*="sppb-col-"]:has(.sppb-addon-ajax-contact) {
	padding-left: 0;
	padding-right: 0;
}

/* The old button was a fixed 180px pill rather than sized to its label —
   except on the home page, where it was 120px. */
.sppb-addon-ajax-contact .sppb-btn {
	width: 180px;
}

body.itemid-109 .sppb-addon-ajax-contact .sppb-btn {
	width: 120px;
}

/* The old site disabled the resize grip. Chrome draws that grip over the
   bottom-right corner, which is what squares off the textarea's 22px radius. */
.sppb-addon-ajax-contact textarea.sppb-form-control {
	resize: none;
}


/* Vertical offsets carried over from the old template's Custom CSS. These are
   what lined the form up with the promo images beside it on the home page:
   the form block was pulled up 47px, and every addon's content by a further
   19px above 800px wide. Both rules were global on the old site. */

.sppb-addon-ajax-contact {
	position: relative;
	top: -47px;
}

@media (min-width: 800px) {
	.sppb-addon-content {
		margin-top: -19px;
	}
}


/* 7. Home slider — text position inside the slides
   ------------------------------------------------
   Two things placed the slide text on the old site, and neither survived:

   a) The content box. Floox's template Custom CSS gave it a 30px left inset and
      capped it at 1200px centred, so the copy lined up with the rest of the
      page instead of hugging the viewport edge. That CSS was not migrated.

   b) The wrap width. SPPB 3 emitted 100% / 85% / 990px-and-below 95% for this
      slider. SPPB 6 only emits the base (xl) value from
      content_container_width, so the narrower widths below 992px were lost.

   The base 100% comes from SPPB's own ID-scoped rule, which outranks any
   class selector — hence !important on the two responsive overrides below.
   Keeping them on the generic class (rather than the addon id) means they
   survive the slider being rebuilt in the builder.

   Note .sppb-addon-sp-slider and .sp-slider are the SAME element, so they must
   not be chained as a descendant pair. */

@media (min-width: 800px) {
	.sp-slider-content-align-left,
	.sp-slider-image-align-left {
		padding-left: 50px;
		max-width: 1200px;
		margin-left: auto;
		margin-right: auto;
	}
}

@media (max-width: 600px) {
	.sp-slider-content-align-left,
	.sp-slider-image-align-left {
		padding-left: 10px;
	}
}

@media (min-width: 768px) and (max-width: 991px) {
	.sp-slider .sp-slider-content-wrap {
		width: 85% !important;
		margin: 0 auto;
	}
}

@media (max-width: 767px) {
	.sp-slider .sp-slider-content-wrap {
		width: 95% !important;
		margin: 0 auto;
	}
}

.sp-megamenu-parent .sp-dropdown li.sp-menu-item > a,
.sp-megamenu-parent .sp-dropdown li.sp-menu-item > span {
	font-weight: 600;
}

/* Floox showed no caret on parent items. Helix draws one as a Font Awesome
   glyph in ::after, so hide the pseudo-element outright — overriding `content`
   alone loses to Helix's more specific selector. */
#sp-header .sp-megamenu-parent > li.sp-has-child > a::after,
#sp-header .sp-megamenu-parent > li.sp-has-child > span::after {
	display: none;
}


/* Submenu popup — matched to the old site, measured on the live version:
       panel   10px radius, 7px 0 inner padding (Helix ships 0 radius / 20px)
       links   block, 5px 20px padding, 28px line-height
                 (Helix ships inline-block, 8px 0, 14px line-height)
   Panel width (240px), white background and the drop shadow already match. */

.sp-megamenu-parent .sp-dropdown .sp-dropdown-inner {
	border-radius: 10px;
	padding: 7px 0;
}

.sp-megamenu-parent .sp-dropdown li.sp-menu-item > a,
.sp-megamenu-parent .sp-dropdown li.sp-menu-item > span {
	display: block;
	padding: 5px 20px;
	line-height: 28px;
}

/* Dropdowns open from the LEFT edge of their menu item (left:0; right:auto),
   which pushes the last item's panel off the right of the screen — "Tenglar"
   overflowed by ~80px at 1280px wide. The old site had exactly the same bug,
   so this is a fix rather than a parity change.

   Anchoring the last item's panel to its RIGHT edge keeps it on screen at any
   width, because the menu itself is flush right. Applied to the last item only
   so the other panels keep opening left-to-right as before; if it ever ends up
   on an item without children the rule simply matches nothing.

   Helix anchors these with
       body.ltr .sp-megamenu-parent .sp-dropdown.sp-dropdown-main.sp-menu-right
   at specificity 0,5,1, so the selector below deliberately mirrors that shape
   to land at 0,5,2 and win on specificity rather than !important. (With both
   left and right set, `left` wins for a fixed-width box — so overriding only
   `right` does nothing.) */

body.ltr .sp-megamenu-parent > li:last-child > .sp-dropdown.sp-dropdown-main {
	left: auto;
	right: 0;
}