/* ------------------------------------------------------------------
   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;
}

/* The white-text rules above use `>` combinators that only reach TOP-LEVEL
   items, so the home page's submenu links are left alone and take the same
   #484848 / green treatment as everywhere else (see §8). That is deliberate:
   the panel is white on every page, so white submenu text would be invisible.

   Do not scope a colour to `body.itemid-109 … .sp-dropdown … a` to "finish the
   set" — at specificity 0,4,3 it would outrank the 0,4,2 hover and active
   rules in §8 and freeze the home page's submenu on one colour. */


/* 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;
}


/* 8. 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;
}

/* Submenu colours, measured off the live old site:
       rest    #484848   (Floox's own template.css default)
       hover   #5fb157   (preset2, which won over the old site's generic
                          `.sp-menu-item a:hover { color:#484848 }` because
                          that rule was 0,2,1 against preset2's 0,4,2)
       active  #5fb157   — same green, so an active item that is also hovered
                          simply stays green, as it did before.
   Backgrounds stay transparent in every state; the old site never filled the
   row. (Floox's preset did give the TOP-LEVEL active item a green background,
   but the old site's Custom CSS killed it with `li.active a{background:none}`.)

   Helix keeps these three colours in template parameters instead
   (menu_dropdown_text_color / _hover_ / _active_), currently #909090, #484848
   and #484848 — the greys of the top-level bar, with no green anywhere. They
   are overridden here rather than changed in the admin UI because the params
   are SCSS variables: they are compiled into css/presets/default.css, so a
   parameter edit only reaches the page after the template style is re-saved,
   and the result lands in a generated file that is rewritten on every save.
   This file loads after that one, so identical selectors are enough to win —
   no !important and no specificity inflation needed. */

.sp-megamenu-parent .sp-dropdown li.sp-menu-item > a,
.sp-megamenu-parent .sp-dropdown li.sp-menu-item > span {
	color: #484848;
}

.sp-megamenu-parent .sp-dropdown li.sp-menu-item > a:hover {
	color: #5fb157;
}

.sp-megamenu-parent .sp-dropdown li.sp-menu-item.active > a {
	color: #5fb157;
}

/* 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;
}


/* 9. Body copy leading in the content area
   ----------------------------------------
   Floox set `body { line-height: 28px }` globally, so every subpage paragraph
   inherited 28px at the 16px body size. Helix has no equivalent rule, so the
   inherited value falls through to Bootstrap's --bs-body-line-height (1.5),
   which lands on 24px — measurably tighter than the old site.

   Applied to the content container rather than to `body`, because Floox's
   global version also fed the header, offcanvas and footer, whose spacing is
   already matched here through their own rules.

   Nothing inside the content area is disturbed by the inherited change:
   SP Page Builder emits explicit line-heights on addon titles (90px, 33px,
   … on the migrated pages) and Helix/Bootstrap do the same for form controls
   and buttons — verified against the live old site, where those elements sit
   at their own values despite the 28px on body.

   Scoped to the subpages (home is itemid-109) as requested. The old site did
   run 28px on the home page too, but its content there is slider and promo
   blocks that carry their own leading, so extending this would change little
   beyond the contact form's surroundings. */

body:not(.itemid-109) #sp-component {
	line-height: 28px;
}