/** * restyle.css - LandboUngdom site-specific overrides * * Handle: egovt-child-restyle. Third and last of the child theme's sheets: * * tokens.css names - Kit colour/type aliases + geometry tokens * design-system.css reusable lu-* components, geometry and type only * restyle.css <- we are here * * WHAT BELONGS HERE, AND WHAT DOES NOT * * This file is for things that are true of THIS SITE and cannot be expressed as * a reusable component: the global header and footer documents, and the handful * of places where a plugin's own CSS has to be argued with. * * A rule that would be just as correct on another page belongs in * design-system.css. A colour belongs in the Elementor Kit. * * HOUSE RULES * * - No !important unless a conflict has actually been measured, and every use * names what it beats. Four of the five !important rules this file used to * carry are gone, because the stale Cabin typography they were fighting has * been cleared at source in the Elementor editor - which was always the real * fix (HANDOFF section 5). * - Beat Elementor by matching its specificity, never by force. The client * edits this site in Elementor and must not be locked out of it. * - Colour comes from the Kit via var(--lu-*). No hex in this file. * * WHERE THIS FILE SITS IN THE CASCADE (verified against the rendered ) * * egovt-theme parent theme.css, 194 KB * style-elementor.css ova-framework plugin CSS (priority 10) * egovt-style + inline ~28 KB of Ovatheme Customizer CSS * elementor-frontend + inline .elementor-kit-4 (palette + type scale) * tokens -> ds -> THIS FILE <- we are here (priority 20) * widget-heading, widget-counter, ... Elementor per-widget CSS * inline .elementor-post-NNNN Elementor per-document CSS * wp-custom-css Additional CSS, post 9002 * * Two consequences worth internalising: * * 1. Elementor's per-widget sheets load AFTER us, and its per-document CSS * prints INSIDE , later than any stylesheet. Rules here therefore * carry one extra notch of specificity - typically a leading `body` - which * beats a plugin's .elementor-widget-x .y (0,3,3) while still losing to * Elementor's per-element .elementor-NNNN .elementor-element-xxxxx (0,5,3). * That gap is the point: the client's own Elementor edits keep winning. * * 2. Additional CSS (post 9002) prints on wp_head priority 101 and always wins. * See docs/additional-css-9002.css for what is in it. Do not try to out-rank * it from here - the fix is editing the Customizer, a manual prod step. */ /* ========================================================================== 1. @font-face ========================================================================== */ /** * Intentionally empty. * * The GT Era @font-face declarations live in assets/css/gt-era-fonts.css under * their own handle (gt-era-fonts, registered in inc/elementor-fonts.php). They * are kept separate because that sheet is also enqueued into the Elementor * editor panel via elementor/editor/after_enqueue_styles, where this file is * not loaded - the font picker needs the faces, but the editor chrome must not * inherit the site's re-style. * * NOTE: GT Era is currently installed TWICE on this site. This theme ships one * copy; the WP Font Library holds another (wp_font_family / wp_font_face posts * 35590-35599, files in wp-content/uploads/fonts/) which emits its own inline * @font-face and --wp--preset--font-family-* tokens. Neither the posts nor the * uploads directory travel with this theme. See HANDOFF section 1a. */ /* ========================================================================== 2. Element defaults ========================================================================== FONT FAMILY ONLY, and a safety net rather than the mechanism. The Elementor Kit already sets GT Era on body, links and h1-h6 at .elementor-kit-4 (0,1,0), and the Kit is the source of truth. These rules sit below that and never fight it - they exist for the case where the Kit is exported, re-imported or re-keyed, which HANDOFF section 2 flags as a real risk, and for markup the Kit's selectors do not reach. The old design used two faces and the re-style maps them one for one, so the existing typographic hierarchy survives unchanged: Nunito Sans (old body face) -> --lu-font-body GT Era Text Cabin (old display face) -> --lu-font-display GT Era Display None of these need !important. The Ovatheme Customizer's competing declarations are attached to the egovt-style handle and print earlier than this file at the same specificity, so we win on order alone - which is the whole reason the enqueue depends on egovt-style. See tools/font-audit-report.json for the measurements. ========================================================================== */ body { font-family: var(--lu-font-body); /** * THE `!important` IS LOAD-BEARING, and what it beats is an inline style. * * ova-framework dims the page for the mobile drawer by writing the BODY's * background: `$('body').css('background-color', 'rgba(0,0,0,0.4)')` on * open, and `'transparent'` on close (script-elementor.js:12 and :20). It * does not restore what was there - it hardcodes transparent - so the first * time the drawer was opened and closed, the page ground was gone and the * white canvas showed through for the rest of the visit. Reported as "the * background turns white after using the menu". * * An element's inline style beats every stylesheet, so this is the one * declaration that cannot be won on specificity or order. Two knock-on * effects, both wanted: * * - The 40% black dim is cancelled too, which returns the open state to * the design: `.ova_closeCanvas` is the scrim, and it is the page's own * colour at 75% (section 3), not a grey wash with black behind it. * - The ground cannot be painted on instead - the --lu-* tokens are * declared on `body`, deliberately, because Elementor's Kit class lives * there (tokens.css). On the var would not resolve. */ background-color: var(--lu-page-bg) !important; /* Companion to .lu-bleed in design-system.css section 15: a full-bleed * section is 100vw wide, which includes the scrollbar, so without this the * page gains a horizontal scrollbar. `clip` rather than `hidden` - hidden * would make body a scroll container and break the sticky header. */ overflow-x: clip; } h1, h2, h3, h4, h5, h6, .nav_comment_text { font-family: var(--lu-font-display); } /** * Form controls do not inherit font-family from body - the UA stylesheet gives * them the operating system's UI font - so neither the Kit nor the rules above * can reach them. Nothing else competes here. */ button, input, optgroup, select, textarea { font-family: var(--lu-font-body); } /** * Ovatheme's "second font" utility. Beats `.cal1, .second_font { Cabin }` from * the Customizer on source order at equal (0,1,0) specificity. * Measured on: front page, the "28. August 2026" post date. */ .cal1, .second_font { font-family: var(--lu-font-display); } /** * Mobile heading scale. * * The Kit sets h1-h4 once, for desktop, at .elementor-kit-4 h2 (0,1,1) - it has * no responsive control for the type scale. So the step down has to happen here. * * `body[class*="elementor-kit-"]` rather than `.elementor-kit-4` on purpose: * (0,1,2) clears the Kit's (0,1,1) without hard-coding the Kit's post id, which * changes if the Kit is re-imported (HANDOFF section 2). * * Only h1 and h2 move. h3 and h4 are already right at both widths, and the * stat figure stays at 81 because it reads --lu-type-h1-* rather than these. */ @media (max-width: 767px) { body[class*="elementor-kit-"] h1 { font-size: var(--lu-type-h1-page-size); line-height: var(--lu-type-h1-page-lh); } body[class*="elementor-kit-"] h2 { font-size: var(--lu-type-h2-size); line-height: var(--lu-type-h2-lh); } /** * lu-page-head--long: a page title that is a sentence rather than a name * steps once more on a phone (wave 3, D16). See tokens.css for why this is * a modifier and not a change to --lu-type-h1-page-size. * * Matched at (0,2,1) so it beats the h1 rule above, which is (0,1,2). */ body[class*="elementor-kit-"] .lu-page-head--long h1, body[class*="elementor-kit-"] h1.lu-page-head--long { font-size: var(--lu-type-h1-page-long-size); line-height: var(--lu-type-h1-page-long-lh); } } /* ========================================================================== 2b. Content width ========================================================================== The design's content column is 1320px - 1440 less a 60px gutter each side. Three things cap it at 1270 and they have to be answered separately: theme.css:414 .wrap_site { max-width: 1270px } the page wrapper theme.css:423 .container, body .elementor-section .elementor-section-boxed > .elementor-container { max-width: 1270px !important } "Fix Layout to 1270px" Elementor Kit Content Width, now 1320 already done The second is the only !important in this file besides Slider Revolution, and it is unavoidable: theme.css declares !important at exactly this specificity, so nothing but a matching !important can pass it. We load later, so equal specificity resolves our way. The wrapper is sized so its CONTENT box is exactly --lu-container, and its padding is --lu-pad rather than the theme's flat 10px. That keeps the gutter at 60px at 1440 (36px of centring plus 24px of padding) and stops it collapsing to 10px at every width in between - which is what let text run into the viewport edge from about 1024 down. A section nested inside a column loses another 20px to that column's default padding. Rather than cancelling it with a negative margin here - which would be wrong the moment a column had different padding - the columns this affects have their padding set to zero in Elementor. See HANDOFF section 6. ========================================================================== */ .wrap_site { max-width: calc(var(--lu-container) + 2 * var(--lu-pad)); padding-inline: var(--lu-pad); } /** * The !important is unavoidable - theme.css declares one at exactly this * specificity - but the VALUE is a variable, which is what lets a full-bleed * section opt out without a second !important fight. `.lu-hero` and the footer's * advert strip raise --lu-container-max on themselves; it inherits down to the * container, and this rule reads it. See design-system.css section 13b. */ body .elementor-section.elementor-section-boxed > .elementor-container { max-width: var(--lu-container-max, var(--lu-container)) !important; } /* ========================================================================== 3. Site chrome - the global header ========================================================================== Header document 5460 "Header primary", live as `global_header`, `single_header`, `blog_header` and both `sev` headers - so this is every page on the site except the four Konference 2026 pages, which use document 2737. The Elementor side of this has already been done: the Cabin typography and the #AAAD00 literals are cleared, `bg_dark` is off the masthead, and the two bars are bound to Kit globals (a53ee87 "Pink bjaelke", 1fa1664 "Sidebaggrund"). What is left here is geometry and the plugin's own defaults. The nav rules below are deliberately NOT scoped to document 5460. Any header document gets the design; a document that still carries its own per-element Elementor settings - 2737 does - keeps them, because those print later and more specifically. That is the correct behaviour in both directions. ========================================================================== */ /* --- The sticky nav ------------------------------------------------------ * The nav bar stays pinned to the top of the viewport for the length of the * page; the pink bar scrolls away and does not come back. Neither bar moves at * rest - desktop still draws pink above nav, mobile still draws nav above pink * - so this is a scroll behaviour, not a re-layout. * * Three things had to be true for `position: sticky` to do it on its own, with * no scroll listener and no JS in this theme: * * 1. NOTHING BETWEEN THE NAV AND THE VIEWPORT MAY SCROLL. `body` is * `overflow-x: clip` rather than `hidden` for exactly this reason (section * 2): `clip` does not make a scroll container, `hidden` would, and a sticky * element inside one sticks to that box instead of to the viewport. * * 2. THE CONTAINING BLOCK MUST BE THE PAGE, NOT THE HEADER. A sticky element * never travels outside its containing block, and the header document's own * wrapper is only as tall as the two bars it holds - 93px, measured - so a * nav pinned inside it would come unstuck 41px into the scroll. * `display: contents` drops that wrapper's box without touching the DOM: * the two bars become boxes of `.ova-wrapp`, which spans the whole * document, and the nav can stay pinned all the way to the footer. Safe * because the wrapper paints nothing of its own - no background, border or * padding, measured in the browser, not assumed - and selectors still match * the DOM, so Elementor's own `.elementor-5460 .elementor-element-*` rules * are unaffected. * * 3. THE PINK BAR MUST BE OUTSIDE THE STICKY BOX. On desktop it already is: an * earlier sibling, so it scrolls off on its own. Mobile draws it below the * nav, and is handled in the 1024px block near the end of this file. * * Scoped with `:has(> .lu-masthead)` rather than to document 5460, for the * reason in the section header: any header document carrying the design gets * the behaviour. Document 2737 (Konference) carries neither class and keeps * its static header. * * Switched off inside the Elementor editor: a document wrapper with no box is * not something the editor's drag-and-drop should have to reason about. * `elementor-editor-active` sits on the preview iframe's own body while the * panel is open and is swapped for `elementor-editor-preview` when it is * hidden - so the client's own preview still shows the real behaviour. */ body:not(.elementor-editor-active) .elementor:has(> .lu-masthead) { display: contents; } /** * No z-index here: the masthead already carries 99 from its own Elementor * Z-Index control, which prints later and at (0,4,0). That is what keeps the * pink bar - and the page - passing behind the pinned bar rather than through * it. The bar's opaque ground comes from the same place (Kit global * "Sidebaggrund"), so there is nothing to paint here either. * * Beats `.elementor-section { position: relative }` from elementor frontend.css * (0,1,0, earlier in the cascade) on the leading `body`, per the house rule. */ body .lu-masthead { position: sticky; top: 0; } /** * The logged-in toolbar is fixed over the top of the page at 601px and up, so * the nav pins below it rather than under it. WordPress publishes the * toolbar's own height (32px, 46px below 783px) on , so this follows it * without restating either number. Below 601px the toolbar scrolls away with * the page and the nav goes back to the top of the viewport. * Editors only - `admin-bar` is never on a visitor's body. */ body.admin-bar .lu-masthead { top: var(--wp-admin--admin-bar--height, 32px); } @media (max-width: 600px) { body.admin-bar .lu-masthead { top: 0; } } /** * In-page anchors, and the browser's own find-on-page and focus scrolling, * would otherwise land the target underneath the pinned bar. The theme already * sets `scroll-behavior: smooth` on ; this is its companion. */ html { scroll-padding-top: var(--lu-header-bar-h); } /* --- The pinned nav's glass ---------------------------------------------- * The bar transmits a little of whatever is behind it and blurs it. Nothing * about this is tied to the scroll: at rest there is nothing behind the bar * but the page's own ground, which is the colour the bar already is, so it * looks exactly as it always has - and the moment content passes underneath, * the glass shows. "Only when it is stuck" comes out of the physics rather * than out of a state we have to detect. * * That is the second reason for doing it this way. The first was a shadow, and * it was tied to a scroll-driven animation - a 2023 feature that Safari did not * ship until 26, so on an older browser it could never appear at all. * `backdrop-filter` is a decade old and prefixed back to Safari 9. * * WHY A PSEUDO-ELEMENT AND NOT THE SECTION ITSELF. `backdrop-filter` makes its * element a containing block for every `position: fixed` descendant, and the * mobile drawer - `.ova_nav`, fixed, full height - is a descendant of this * section. On the section, the drawer would be positioned against a 52px bar * instead of the viewport and the menu would be unusable. A pseudo-element has * no descendants to capture, so the effect lands and nothing moves. * * `z-index: -1` puts the layer behind the bar's own contents but in front of * the section's background, which is the paint order a stacking context gives * a negative-z child of an element that establishes one (the masthead does, * via its Elementor z-index of 99). */ /** * THE BAR'S GROUND MOVES OUT OF ELEMENTOR AND INTO HERE, and that is a real * trade to be aware of rather than a detail. * * `backdrop-filter` blurs everything painted behind its element - including the * section's own background. While that background is opaque there is nothing * behind it to see, so the glass has to be the only ground the bar has. * * Which means beating Elementor's own background rule for this section, * `.elementor-5460 .elementor-element.elementor-element-5bd9d18:not(...)` at * (0,4,0) - the first rule in this file that deliberately out-ranks a client * setting instead of deferring to it. (0,4,1) does it, on the element selector * rather than an !important. * * The colour still follows the Kit: --lu-nav-glass is mixed from --lu-page-bg, * the global the section is bound to, so Site Settings -> Global Colors -> * Sidebaggrund still repaints the bar. What no longer works is changing THIS * SECTION's background in the Elementor editor - that control is now inert, * and the value to edit is --lu-nav-glass in tokens.css. Recorded in HANDOFF * section 5. */ body .elementor .lu-masthead.elementor-section.elementor-top-section { background-color: transparent; } .lu-masthead::before { content: ""; position: absolute; inset: 0; z-index: -1; /* The bar as it has always been. A browser with no `backdrop-filter` stops * here and gets an opaque bar rather than an unreadable transparent one. */ background-color: var(--lu-page-bg); pointer-events: none; } @supports ((backdrop-filter: blur(1px)) or (-webkit-backdrop-filter: blur(1px))) { .lu-masthead::before { background-color: var(--lu-nav-glass); -webkit-backdrop-filter: var(--lu-nav-glass-filter); backdrop-filter: var(--lu-nav-glass-filter); } } /* --- The pinned bar's shadow --------------------------------------------- * Drawn only while the bar is pinned, which is a state CSS cannot read: there * is no `:stuck` selector in any browser. `assets/nav-stuck.js` answers it by * watching a 1px sentinel with an IntersectionObserver and putting * `lu-nav-stuck` on ; its header carries the reasoning, including why * this is not the `animation-timeline: scroll()` version it replaces. * * The sentinel sits at the pink bar's height down the page. That single number * is the right trigger at both widths for two different reasons - on desktop it * is where the bar pins, on mobile it is where the pink bar finishes passing * behind it - so the shadow never falls across pink, which was the ask. * * Positioned against the initial containing block, which is anchored to the * document rather than to the viewport, so `top` here is a page coordinate. * `.ova-wrapp` is `position: relative` below 1025px (the pink bar hangs off it) * and static above, and the sentinel lands in the same place either way - * both containing blocks start at the top of the document. */ .lu-nav-sentinel { position: absolute; top: var(--lu-utility-bar-h); inset-inline-start: 0; width: 1px; height: 1px; pointer-events: none; visibility: hidden; } .lu-masthead::after { content: ""; position: absolute; inset-inline: 0; top: 100%; height: var(--lu-nav-shadow-h); background: var(--lu-nav-shadow); /* The resting state, and the whole answer for a browser with no * IntersectionObserver or no JS: no shadow, and a bar that is still glass. */ opacity: 0; transition: opacity 160ms linear; pointer-events: none; } body.lu-nav-stuck .lu-masthead::after { opacity: 1; } /* A fade is not movement, but the design system asks every transition to have * an answer here, and the honest one is to arrive without the fade. */ @media (prefers-reduced-motion: reduce) { .lu-masthead::after { transition: none; } } /** * THE PARENT THEME HAS A STICKY HEADER OF ITS OWN, and it has to be switched * off or the two fight. * * The masthead carries the class `ovamenu_shrink_mobile`, which is the * ova-framework opt-in for it (script-elementor.js:55-80). Below desktop, once * the page has scrolled past the header's height + 150px, its scroll handler * adds `active_fixed` - theme.css:1222 then takes the bar out of flow with * `position: fixed` and a box-shadow - and inserts a spacer div after it whose * height it sets to the bar's own. * * Three things are wrong with that, and all three are measured on this site: * * - It does not start until 202px of scroll, so the bar is gone from the * screen for most of a phone's first swipe and then appears out of nowhere. * - The spacer replaces a 52px bar, but a bar leaving the flow here takes its * 41px reservation for the pink bar with it - so the page jumped 41px up at * the moment the class landed. * - It brings its own box-shadow, which snaps on at 202px, below desktop * only, and is not the design's. The design's is above: tinted from the * palette, at both widths, from the moment the bar is actually pinned. * * Rather than let the class arrive and fix it up, this cancels what it does. * The JS still runs; it just has nothing left to change. Equal specificity to * theme.css's (0,2,1) and later in the cascade, per the house rule - no * `!important` is needed. * * The tidier fix is one editor change: clear `ovamenu_shrink_mobile` from the * masthead's CSS Classes in Elementor and the handler never binds at all. That * is a manual production step (HANDOFF section 5), and these two rules are what * make the theme correct on its own either way - including if the class is * added back later. `.show_mask_header` is the desktop spacer, the same * mechanism behind `ovamenu_shrink`; nothing on this site sets that class * today, and the rule costs one selector. */ body .lu-masthead.active_fixed { position: sticky; box-shadow: none; } .show_mask_header, .show_mask_header_mobile { display: none; } /* --- The pink utility bar ------------------------------------------------ */ /** * Both header bars are --lu-header-bar-h tall, from the same token, so they * cannot drift apart. The pink bar's own padding has been removed in Elementor * (it was 10/11, giving 62px against the nav's 53) and its height now comes * from here. * * Width and gutter are NOT set here - design-system.css section 13b puts every * section of both chrome documents on the same line as the page content. */ .lu-masthead > .elementor-container { min-height: var(--lu-header-bar-h); align-items: center; } /* The utility strip is deliberately shallower than the nav bar - 41 against 52 * on the frame. */ .lu-utility-bar > .elementor-container { min-height: var(--lu-utility-bar-h); align-items: center; } /* `.elementor-element-populated` is in the selector on purpose: the bar has two * columns, one of them empty, and only the populated one carries the links. * Without it the rule lands on the empty column's wrap and does nothing * visible, which is exactly how the mobile split failed the first time. */ .lu-utility-bar .elementor-widget-wrap.elementor-element-populated { align-items: center; /** * `gap`, not a margin on the first link. The 30px used to live on * `9a50d2e`'s _margin, which Elementor puts on the widget's inner container * - so it also pushed the LAST link 30px off the right line. A gap spaces * the pair without touching either outer edge, and stays correct whether the * bar is left-aligned, right-aligned or split. */ gap: 30px; } .lu-utility-bar .elementor-button { padding: 0; background: none; border: 0; } /* --- The masthead -------------------------------------------------------- */ .lu-masthead .elementor-widget-wrap { align-items: center; } /** * The design puts a clear gap between the last nav item and the search control, * rather than running everything hard against the right edge. `auto` on the * search widget's inline-start margin is what opens it; the nav then settles * where the design has it, just right of the logo. */ .lu-masthead .elementor-widget-ova_search_popup { margin-inline-start: auto; } .lu-masthead .elementor-widget-button .elementor-button { background: none; border: 0; padding: 0; } /** * The Kontakt link needs breathing room from "Soeg" without a margin control * being retyped per breakpoint. */ .lu-masthead .elementor-widget-button { margin-inline-start: 28px; } /* --- The nav itself ------------------------------------------------------ * Leading `body` throughout, for the reason in the file header: it clears the * ova-framework plugin sheet at (0,3,3) without ever reaching Elementor's own * per-element rules at (0,5,3). * * What each rule beats: * type style-elementor.css:103 .ova_nav ul.menu > li > a * { font-size:14px; font-weight:500; * text-transform:uppercase } * colour style-elementor.css:41 .elementor-widget-ova_menu .ova_nav * ul.menu > li > a { color:#202B5D } */ body .elementor-widget-ova_menu .ova_nav ul.menu > li > a { /* flex, not the plugin's inline-block: an inline-block carries a baseline * descender gap, which made the nav bar 53px against the pink bar's 52 and * left the two visibly out of step. */ display: flex; align-items: center; /* Separates a parent item from its chevron. Items without one have a single * flex item, so this costs them nothing. */ gap: 3px; font-family: var(--lu-font-body); font-size: var(--lu-type-menu-size); font-weight: 700; line-height: var(--lu-type-menu-lh); text-transform: none; color: var(--lu-primary); padding-block: calc((var(--lu-header-bar-h) - var(--lu-type-menu-lh)) / 2); padding-inline: 12px; } /** * THE CURRENT PAGE IS NOT MARKED IN THE NAV. * * Hover is the only state the bar has. An item sits at --lu-primary whether or * not you are on the page it points to - which is a design decision, not a * simplification: with hover and "you are here" sharing one colour, a hovered * item and the current item were indistinguishable, and the bar appeared to * have a permanently hovered item in it. * * NEUTRALISING IS NOT THE SAME AS NOT STYLING. Dropping `.active` from the * hover rule below is not enough, because the Ovatheme Customizer paints the * same state from theme_mods primary_color (#BABC0E, an old-palette green in no * palette) in three places, all of which out-rank the resting rule above: * * (0,4,3) ul.menu > li.active > a color * (0,4,3) ul.menu > li.current-menu-parent > a color * (0,5,3) ul.menu .dropdown-menu li.active > a background-color * * ...and the plugin adds `.dropdown-menu li.active > a { color: #fff }` at * (0,5,3) of its own. So the current item has to be told what it is, at one * notch above each. The leading `body` is what supplies that notch. * * A fourth rule, `.dropdown-menu li.active { border-bottom-color: #BABC0E * !important }`, is left alone deliberately. Measured on a submenu page * (/ploejning/, whose item sits under Aktiviteter): border-bottom-width is 0px * on active and inactive items alike, so the colour never draws. Answering an * !important takes an !important, and there is nothing here to answer - so this * adds none. * * `:is()` keeps the pair on one line and takes its specificity from its most * specific argument, so the count above still holds. */ body .elementor-widget-ova_menu .ova_nav ul.menu > li:is(.active, .current-menu-parent) > a { color: var(--lu-primary); } /** * Hover. Beats the Ovatheme Customizer's * `.elementor-widget-ova_menu .ova_nav ul.menu > li > a:hover` (0,4,2), which * still carries theme_mods primary_color #baba0f. HANDOFF section 4 tracks * changing that value at source. * * The second selector is not redundant, and it is not there to match anything * the first does not - an active `li` is still an `li`. It is there to WIN: * the first is (0,4,4) and so is the rule above it, which would leave the * current item's hover to source order. At (0,5,4) it cannot drift. */ body .elementor-widget-ova_menu .ova_nav ul.menu > li > a:hover, body .elementor-widget-ova_menu .ova_nav ul.menu > li:is(.active, .current-menu-parent) > a:hover { color: var(--lu-secondary); } /* The animated underline pseudo (style-elementor.css:59-66) has no colour of * its own; the Customizer paints it. Point it at the palette. */ body .elementor-widget-ova_menu .ova_nav ul.menu > li > a:after { background-color: var(--lu-secondary); } /* Submenus. */ body .elementor-widget-ova_menu .ova_nav ul.menu .dropdown-menu { background-color: var(--lu-page-bg); border-radius: 0 0 var(--lu-radius-btn) var(--lu-radius-btn); padding: 8px 0; } /** * …AND ON DESKTOP THE PANEL IS GLASS, like the bar it hangs from. * * Same recipe, same tokens: 10% of what is behind it, blurred. A submenu is a * panel floating over the page in exactly the way the pinned bar is, so it * should sit in the page the same way - and the two are on screen together, * which is what makes a difference between them read as an accident. * * Desktop only. Below 1025px a "submenu" is a block inside the off-canvas * drawer with the page scrimmed behind it, not a floating panel, and there is * nothing there for a blur to do. * * TWO THINGS THIS BEATS, and the first one is a client setting: * * 1. The ground. Elementor prints * `.elementor-5460 .elementor-element.elementor-element-c4c6626 .ova_nav * ul.menu .dropdown-menu` (0,5,3) INSIDE , later than this file, so an * equal-specificity rule loses the tie. (0,6,3) takes it. As with the * masthead's ground in this section, that makes the widget's own Submenu * Background control inert - HANDOFF section 5 records both. * 2. The shadow. The plugin gives the panel `rgba(6, 22, 58, .1) 0 10px 40px`, * a blue one carried over from the theme demo. The geometry is right for a * panel this size and is kept; only the colour changes, to the black the * design settled on for the bar. A blue shadow and a black one on screen at * the same moment is the kind of thing nobody names and everybody sees. */ @media (min-width: 1025px) { body .lu-masthead .elementor-element.elementor-widget-ova_menu .ova_nav ul.menu li .dropdown-menu { background-color: var(--lu-page-bg); box-shadow: 0 10px 40px color-mix(in srgb, black 10%, transparent); } @supports ((backdrop-filter: blur(1px)) or (-webkit-backdrop-filter: blur(1px))) { body .lu-masthead .elementor-element.elementor-widget-ova_menu .ova_nav ul.menu li .dropdown-menu { background-color: var(--lu-nav-glass); -webkit-backdrop-filter: var(--lu-nav-glass-filter); backdrop-filter: var(--lu-nav-glass-filter); } } } body .elementor-widget-ova_menu .ova_nav ul.menu .dropdown-menu li > a { font-family: var(--lu-font-body); font-size: var(--lu-type-body-size); font-weight: 700; line-height: var(--lu-type-body-lh); text-transform: none; color: var(--lu-primary); padding: 10px 20px; } /* Submenus follow the same pair: primary at rest, secondary on hover, and no * ground behind either state - and, like the bar above, they do not mark the * current page. * * The background has to be stated even though the colour is now the resting * one: the Customizer paints `.dropdown-menu li.active > a` from its long * `background-color` selector list, which is what would otherwise put a lime * block behind the current item in an open panel. */ body .elementor-widget-ova_menu .ova_nav ul.menu .dropdown-menu li.active > a { color: var(--lu-primary); background-color: transparent; } body .elementor-widget-ova_menu .ova_nav ul.menu .dropdown-menu li > a:hover, body .elementor-widget-ova_menu .ova_nav ul.menu .dropdown-menu li.active > a:hover { color: var(--lu-secondary); background-color: transparent; } body .elementor-widget-ova_menu .ova_nav ul.menu .dropdown-menu li a:after { background-color: transparent; } /* --- The submenu chevron ------------------------------------------------- * Drawn from --lu-icon-chevron rather than set in ElegantIcons. The token * carries the full reasoning; the short version is that the walker emits * `` and the icon font addresses that glyph as the * literal character "3", so every frame the font is not yet painting, the nav * reads "Aktiviteter 3" - and FlyingPress's font-display:swap guarantees there * are such frames. * * Sized in em so the widget's own icon size still drives it, filled with * `currentColor` so it keeps following the nav's colour pair (--lu-primary at * rest, --lu-secondary on hover) with no second rule. * * One selector covers both layouts: the desktop bar renders the inside the * link, the mobile drawer inside `button.dropdown-toggle`. */ body .elementor-widget-ova_menu i.arrow_carrot-down { display: inline-block; width: 1em; height: 1em; flex: none; } body .elementor-widget-ova_menu i.arrow_carrot-down::before { content: ""; display: block; width: 100%; height: 100%; background-color: currentColor; -webkit-mask: var(--lu-icon-chevron) center / contain no-repeat; mask: var(--lu-icon-chevron) center / contain no-repeat; } /* --- The search control ------------------------------------------------- * The design pairs a small, heavy magnifier with the word "Soeg", both in the * Menu role. The widget renders only `` - an ElegantIcons * glyph - and offers no label setting, so both come from here. * * The click handler is bound to `.ova_wrap_search_popup i` * (script-elementor.js:167), so the label is a ::after on the icon itself * rather than a sibling: a pseudo-element is part of its element's hit area, * which keeps the whole "search Soeg" pair clickable. */ body .elementor-widget-ova_search_popup .icon_search { display: inline-flex; align-items: center; gap: 8px; color: var(--lu-primary); cursor: pointer; /* style-elementor.css flips this element with `rotateY(180deg)` because the * ElegantIcons magnifier points the other way. We draw our own, so the flip * has to go - it was mirroring both the mark and the "Soeg" label. */ transform: none; } /* The glyph goes; the mark is drawn from --lu-icon-search so its stroke weight * is a value we control. Sized in em, so the widget's "Size" control still * drives it. */ body .elementor-widget-ova_search_popup .icon_search::before { content: ""; width: 1em; height: 1em; flex: none; background-color: currentColor; -webkit-mask: var(--lu-icon-search) center / contain no-repeat; mask: var(--lu-icon-search) center / contain no-repeat; } body .elementor-widget-ova_search_popup .icon_search::after { content: "Søg"; font-family: var(--lu-font-body); font-size: var(--lu-type-menu-size); font-weight: 700; line-height: var(--lu-type-menu-lh); font-style: normal; letter-spacing: normal; } body .elementor-widget-ova_search_popup .icon_search:hover { color: var(--lu-secondary); } /* --- The search popup itself -------------------------------------------- * The overlay the mark opens. Nothing here was designed: the widget exposes * controls for the ICON only (colour, size, border, margin, padding, align - * ova_search_popup.php:38-220) and none at all for the panel, so the field and * the button were arriving with the browser's own form styling, theme.css's * `input { border: 1px solid #343434 }`, and a scrim of flat * `rgba(0, 0, 0, .96)` (style-elementor.css:1343) - the only pure black on a * site whose darkest colour is a green. * * The type was already GT Era, but only by accident: it falls out of the * `button, input, ... { font-family: var(--lu-font-body) }` safety net in * section 2, at the UA's size and theme.css's 23px leading rather than at any * role in the scale. So this puts it on the Menu role - the same role the mark * and the word "Soeg" that open the panel already carry. * * The plugin's own rules are (0,4,0) and print later than this file, so each * selector below clears them by one class plus the leading `body`, and stays * well under Elementor's per-element (0,5,3). * * The placeholder and the button label are English because they are plugin * strings (`esc_html_e( 'Search ...', 'ova-framework' )`) with no Danish * translation loaded. That is a Loco Translate job, not a CSS one - HANDOFF * section 7. */ /* The scrim, from the palette rather than from black. */ body .elementor-widget-ova_search_popup .ova_search_popup { background: color-mix(in srgb, var(--lu-primary) 96%, transparent); } /** * The radius goes on the FORM, not on the two controls. They sit flush against * each other, so rounding each one would put a seam down the middle; clipping * the pair gives the button geometry of section 7 across the whole control. */ body .elementor-widget-ova_search_popup .ova_search_popup .search-form { border-radius: var(--lu-radius-btn); overflow: hidden; } body .elementor-widget-ova_search_popup .ova_search_popup .search-form .search-field, body .elementor-widget-ova_search_popup .ova_search_popup .search-form .search-submit { font-family: var(--lu-font-body); font-size: var(--lu-type-menu-size); line-height: var(--lu-type-menu-lh); border: 0; /* theme.css:237 gives every input a #343434 hairline */ padding-block: 0; } body .elementor-widget-ova_search_popup .ova_search_popup .search-form .search-field { background-color: var(--lu-page-bg); color: var(--lu-primary); font-weight: 400; padding-inline: var(--lu-pad); } /* Placeholder text is a hint, not content - the same colour at less weight. */ body .elementor-widget-ova_search_popup .ova_search_popup .search-form .search-field::placeholder { color: color-mix(in srgb, currentColor 55%, transparent); opacity: 1; /* Firefox ships a 0.54 default that would compound the mix */ } /** * The submit takes the page's primary button pairing - lime ground, primary * label - because there is no widget control to take it from. Bold, because * this is the Menu role and the Menu role is GT Era Text 700. */ body .elementor-widget-ova_search_popup .ova_search_popup .search-form .search-submit { background-color: var(--lu-secondary); color: var(--lu-primary); font-weight: 700; padding-inline: 40px; } /* --- The narrow desktop: 1025 to 1200 ------------------------------------ * THE WINDOW WHERE THE BAR USED TO BREAK, and it is a window rather than a * point: the drawer does not arrive until 1024, so everything between there * and the width the row stops fitting was broken. * * WHAT BROKE, MEASURED. The row is logo | nav | search | Kontakt, and at 1140px * it is exactly full - the nav ends at 913 and the search starts at 918. One * step narrower and the search and Kontakt wrap to a second line, which takes * the bar from 52px to 73px and pushes the logo down with it. Every width from * 1135 down to 1025 was drawn that way. * * WHAT IT TAKES TO FIT AT 1025. The row has to lose 92px, and it is made up * from four places rather than one, because no single one of them is enough * without turning into a different design: * * the "Søg" label 35px the mark carries the meaning on its own at * this width, and the label comes back at 1201 * the logo's column ~39px it is 19.685% wide and the logo is 153px, so * it has been holding ~40px of nothing * Kontakt's margin 12px 28 -> 16, still a clear gap from the search * item padding 32px 12 -> 8 a side, which is not a visible change * * Measured after: it now holds to 1025 with 23px still spare, so a longer menu * item or a font that loads differently does not put it straight back. * * The alternative was moving the drawer's breakpoint up to ~1150. It was * rejected: the 1024 breakpoint is hardcoded in ova-framework's own stylesheet * (style-elementor.css:240 and a few hundred lines below it), the widget has no * control for it, and moving it in CSS would mean re-declaring the whole * off-canvas drawer at a second width and keeping the two in step forever. */ @media (min-width: 1025px) and (max-width: 1200px) { /** * The mark stays, the word goes. Both are painted by the same `` - see * the search control above - so the label is simply emptied. */ body .elementor-widget-ova_search_popup .icon_search { position: relative; } /** * …and the emptied ::after is then reused as the hit area. The mark alone is * 28px where the pair was 63, which is a small target for a pointer; this * takes it back to ~48 WITHOUT taking any width in the row, because it is * positioned rather than laid out. Same trick as the drawer's close cross. */ body .elementor-widget-ova_search_popup .icon_search::after { content: ""; position: absolute; inset: -10px; } /** * The logo's column is a percentage (19.685%, an Elementor setting) and the * logo is a fixed 153px, so the column carries ~40px of empty space that the * nav could be using. Sizing it to its contents hands that straight over. * * Keyed to what the column CONTAINS rather than to its element hash, so a * rebuild in the editor cannot silently unhook it. (0,5,1) against * Elementor's (0,4,0) - the width is a client setting, and this is the one * range where it has to give way. */ body .elementor .lu-masthead .elementor-column:has(> .elementor-widget-wrap > .elementor-widget-ova_logo) { width: auto; flex: 0 0 auto; } body .elementor .lu-masthead .elementor-column:has(> .elementor-widget-wrap > .elementor-widget-ova_menu) { width: auto; flex: 1 1 auto; } /** * …AND THE FREED SPACE IS SPLIT, not handed to one side. * * The search already carries `margin-inline-start: auto` (above), which is * what opens the gap before it. On its own that collects ALL the spare room * on the right and parks the nav hard against the logo - measured at 10px * from the logo to the first item's text, where the design has 96. * * A second auto margin makes the two share it: flexbox distributes free * space equally between auto margins, so the nav keeps a gap on each side * and both close evenly as the window narrows, instead of one of them * closing first. Measured across the range - logo to text / nav to search: * * 1250 96 / 93 (the design's own proportions, above this range) * 1200 115 / 107 * 1100 65 / 57 * 1025 27 / 19 tight, but still a gap on both sides * * It also means the step at 1201 is small and in the right direction: the * nav moves out from the logo rather than snapping toward it. */ body .lu-masthead .elementor-widget-ova_menu { margin-inline-start: auto; } /* 28 -> 16. Kontakt still reads as separate from the search mark. */ .lu-masthead .elementor-widget-button { margin-inline-start: 16px; } /* 12 -> 8 a side, the least visible of the four, and the one that buys the * headroom: it is what keeps a gap on both sides of the nav at 1025 rather * than 11px on one of them. */ body .elementor-widget-ova_menu .ova_nav ul.menu > li > a { padding-inline: 8px; } } /* --- Mobile: the drawer -------------------------------------------------- */ @media (max-width: 1024px) { /** * `.ova_nav` is a fixed-position off-canvas drawer below 1025px, not a * container. JS toggles .show / .hide on it and inline-styles a width on * `.ova_closeCanvas`. * * 250px is a magic number in style-elementor.css:412 with no Elementor * control behind it. The design's panel is 324 of 402 - 80.6% - so it is * expressed as that proportion and nothing else. * * It used to be capped at 324px as well, which meant the panel only hit the * design's proportion at exactly 402px wide and shrank away from it at every * width above: 75% at 430, 42% at 768, 32% at the top of this breakpoint. * A drawer that narrows as the screen widens is the wrong way round. */ body .elementor-widget-ova_menu .ova_nav.show { width: 80vw; } /** * `canvas_bg_gray` hardcodes #343434 with white links at * style-elementor.css:394-400. The design's drawer is the page background * with primary links. Matched at (0,3,1)+body rather than forced. */ /** * `padding-top` is measured off the frame rather than left at the plugin's * value: the first item's text sits at y 59 on node 1:313, and the item * carries 14px of padding above it (below), so the list starts at 45. * The close mark does not take part in this - it is lifted out of the flow * below so it can sit on the masthead bar's centre line. */ body .elementor-widget-ova_menu .ova_nav.canvas_bg_gray { background-color: var(--lu-page-bg); padding-top: 45px; } body .elementor-widget-ova_menu .ova_nav.canvas_bg_gray ul.menu li a, body .elementor-widget-ova_menu .ova_nav .ova_closeNav { color: var(--lu-primary); } /** * The toggle gets its own line, and it needs one. * * style-elementor.css:394-400 paints the link and the toggle white in one * rule, but the two halves of that selector are NOT the same specificity: * * .ova_nav.canvas_bg_gray ul.menu li a (0,3,3) * .ova_nav.canvas_bg_gray ul.menu li .dropdown-toggle (0,4,2) * * A single answer at (0,4,1) clears the first and loses to the second, which * is why the drawer's links have been primary and its arrows white. Matching * the toggle's own shape puts this at (0,4,3) - past the plugin, still under * Elementor's per-element (0,5,3). */ body .elementor-widget-ova_menu .ova_nav.canvas_bg_gray ul.menu li .dropdown-toggle { color: var(--lu-primary); } /* Drawer items are H4 24/27 with a rule under each. */ body .elementor-widget-ova_menu .ova_nav ul.menu > li > a { font-family: var(--lu-font-display); font-size: var(--lu-type-h4-size); font-weight: 500; line-height: var(--lu-type-h4-lh); padding: 14px 0; } /** * `width: auto` and `align-items: stretch` are both load-bearing. * * style-elementor.css:303 gives every `li` `width: 100%` at this breakpoint, * and Elementor emits `align-items: flex-end` on the menu for the desktop * row layout. In a column flex container that aligns the cross axis to the * RIGHT - so a 100%-wide item plus 20px of margin each side is 40px too wide * and overflows off the LEFT edge, clipping the first two characters of * every label; with `width: auto` it instead right-aligns every item and * shrinks the rules to the text. * * The !important is the third in this file and, like the other two, names * what it beats: Elementor's per-document rule * .elementor-5460 .elementor-element.elementor-element-c4c6626 * .ova_nav ul.menu { align-items: flex-end } * at (0,5,2), printed inside . That value exists only for the desktop * row and is simply wrong in a vertical drawer - style-elementor.css:418 * already overrides `flex-direction` on the same element for the same * reason, so this follows an established precedent rather than setting one. * Scoped to <=1024px, where the drawer is the only layout. */ body .elementor-widget-ova_menu .ova_nav ul.menu { align-items: stretch !important; text-align: start; } /** * The rule belongs to the ITEM'S ROW, not to the item. On the `li` it sits * below the whole element - so opening an accordion pushed it beneath the * submenu and left the open item with no rule of its own. On the link it * stays under the label it separates, open or closed. * * `> a` is load bearing: it reaches top-level links and no others, which is * the whole point - the widget's own border setting could not make that * distinction and is now cleared (HANDOFF section 6). * * The margin insets the rules by --lu-pad each side, which is also where * the close mark ends, so the two share one right line. */ body .elementor-widget-ova_menu .ova_nav ul.menu > li { margin-inline: var(--lu-pad); width: auto; } body .elementor-widget-ova_menu .ova_nav ul.menu > li > a { border-bottom: 1px solid var(--lu-primary); } body .elementor-widget-ova_menu .ova_nav ul.menu > li > a:after { content: none; /* the desktop underline pseudo has no place here */ } /* --- The submenu arrow --------------------------------------------------- * The drawer marks a submenu with a DOWN ARROW, not the chevron the desktop * bar uses - node 1:355, at the H4 size the menu items are set in, on the * same right line as the rules and the cross. * * The walker already emits `button.dropdown-toggle > i.arrow_carrot-down`, * so this only swaps the mask the base rule in section 3 put there and * fixes the geometry the plugin left behind. * * The plugin's own `right: 10px` (style-elementor.css:319) matches at the * same specificity and prints later, so this needs one more class and one * more element to clear it - (0,4,4) against its (0,3,3), still under * Elementor's per-element (0,5,3). */ body .elementor-widget-ova_menu .ova_nav ul.menu li button.dropdown-toggle { position: absolute; /* Aligned to the item's FIRST line, not to its box: "Vaerktoejskasse * for frivillige" wraps to two lines, and an arrow centred on the box * would sit between them. 14px is the item's own padding-top. */ top: 14px; right: 0; margin: 0; padding: 0; width: var(--lu-type-h4-size); height: var(--lu-type-h4-lh); font-size: var(--lu-type-h4-size); display: flex; align-items: center; justify-content: center; } body .elementor-widget-ova_menu .ova_nav button.dropdown-toggle i.arrow_carrot-down::before { -webkit-mask-image: var(--lu-icon-arrow-down); mask-image: var(--lu-icon-arrow-down); } /** * ...and it turns over when the item is open. * * There is no state class to hang this on. The plugin's accordion is one * line of jQuery - `$(this).parent().find('.dropdown-menu').first() * .toggle('fast')` (script-elementor.js:24-26) - which writes an inline * `display` on the submenu and adds no class to anything. (The plugin's own * stylesheet expects an `.active_sub` class at style-elementor.css:327 that * nothing in this code path ever sets.) * * So the open state is read off the inline style jQuery leaves behind. That * is exact rather than approximate: `.toggle()` on a `ul` only ever writes * `display: block` or `display: none`, and it writes `block` at the START of * the opening animation, so the arrow turns with the panel rather than after * it. Verified against the rendered attribute, not assumed. */ body .elementor-widget-ova_menu .ova_nav button.dropdown-toggle i.arrow_carrot-down { transition: rotate 0.2s ease; } body .elementor-widget-ova_menu .ova_nav li:has(> ul.dropdown-menu[style*="display: block"]) > button.dropdown-toggle i.arrow_carrot-down { rotate: 180deg; } /* The rotation is the state, so reduced motion keeps the end position and * drops only the travel - the answer DESIGN.md asks for. */ @media (prefers-reduced-motion: reduce) { body .elementor-widget-ova_menu .ova_nav button.dropdown-toggle i.arrow_carrot-down { transition: none; } } /* --- The accordion ------------------------------------------------------ * Open, a submenu is a plain indented list on the page background. The * desktop submenu is a floating panel and section 3 gives it a rounded * bottom for that; inside the drawer it is neither floating nor a panel. * * The RULES between its items are not drawn here at all - they came from * the nav widget's own "Show Border" setting in Elementor, which paints * `.ova_nav li a` and so could not tell a top-level item from a submenu * one. Cleared at source; see HANDOFF section 6. The rules you see now are * only the `ul.menu > li` border below, which reaches top-level items only. */ body .elementor-widget-ova_menu .ova_nav ul.menu .dropdown-menu { border-radius: 0; } /** * The hamburger sits on the page's right line like everything else. Its * 15px margin is cleared in Elementor; this makes the plugin's wrapper fill * the widget so the button can actually reach the edge - `.ova_wrap_nav` is * narrower than its parent, which left the icon 9px short. * * `align-items: center` is what puts the bars on the bar's centre line, and * is the other half of the cross's alignment below. */ body .elementor-widget-ova_menu .ova_wrap_nav { display: flex; justify-content: flex-end; align-items: center; } /* --- The two marks, drawn ------------------------------------------------ * The plugin renders both from Font Awesome - `