/* ========================================================================== Dvigrad Telekom — targeted fixes Loaded AFTER the main stylesheet, so equal-specificity rules win on order. Nothing here is global: every rule is scoped to one element. The hero enlargement is behind @media (min-width:1920px); the partner fade is behind 1330px, because that is the width at which its bug actually starts, not 1920. Tailwind v4 breakpoints used below: lg = 64rem (1024px) xl = 80rem (1280px) 2xl = 96rem (1536px) ========================================================================== */ /* -------------------------------------------------------------------------- A. Navbar — repair the stripped `xl:` prefixes. The bundle contains these class strings: max-w-[1600px] max-w-[1800px] 2max-w-[2000px] mx-auto px-6 lg:px-20 px-24 2px-32 py-4 py-5 2py-6 An `xl:` prefix was stripped everywhere, which did two things at once: `xl:max-w-[1800px]`, `xl:px-24` and `xl:py-5` lost their prefix and now apply at EVERY width (px-24 = 96px of padding on a 375px phone), and the `2xl:` ones became `2max-w-[2000px]`, `2px-32`, `2py-6` — tokens Tailwind never generated, so they do nothing. Those dead tokens are still in the class attribute though, which makes them precise, collision-proof hooks. Restoring the intended cascade here avoids editing the JS bundle at all. -------------------------------------------------------------------------- */ /* nav inner container — HORIZONTAL only. The vertical half of this repair (py-4 / xl:py-5 / 2xl:py-6) is left OUT on purpose. Restoring it made the navbar 8px taller from 1536px up, and every page's hero clears the navbar by a hand-tuned amount rather than a shared variable. /novosti uses pt-40 = 160px against a 156px navbar — 4px of margin — so those 8px pushed the "BLOG" badge under the bar. Padding-left/right and max-width cannot change the navbar's height, so they are safe. The navbar therefore stays exactly as tall as it is today at every width, and no page's clearance moves. */ [class*="2max-w-[2000px]"] { max-width: 1600px; padding-left: 1.5rem; /* px-6 */ padding-right: 1.5rem; } @media (min-width: 64rem) { [class*="2max-w-[2000px]"] { padding-left: 5rem; /* lg:px-20 */ padding-right: 5rem; } } @media (min-width: 80rem) { [class*="2max-w-[2000px]"] { max-width: 1800px; /* xl:max-w-[1800px] */ padding-left: 6rem; /* xl:px-24 */ padding-right: 6rem; } } @media (min-width: 96rem) { [class*="2max-w-[2000px]"] { max-width: 2000px; /* 2xl:max-w-[2000px] */ padding-left: 8rem; /* 2xl:px-32 */ padding-right: 8rem; } } /* The mobile control group (language + hamburger) is the third child of a `justify-between` row whose first two children are `hidden lg:*`. With both siblings display:none, justify-between leaves the single remaining child at flex-start, so the controls sit hard against the left edge. Until now the erroneous 96px padding hid that by pushing them inward; restoring px-6 without this would park them in the corner. `ml-auto` is what the sibling nav row already uses for the same purpose (`ml-auto lg:ml-0`), so this matches the intent rather than inventing one. */ @media (max-width: 63.999rem) { [class*="lg:hidden"][class*="items-center"][class*="gap-3"] { margin-left: auto; } } /* nav link row: gap-8 / xl:gap-10 / 2xl:gap-12 */ [class*="2gap-12"] { gap: 2rem; } @media (min-width: 80rem) { [class*="2gap-12"] { gap: 2.5rem; } } @media (min-width: 96rem) { [class*="2gap-12"] { gap: 3rem; } } /* nav link text: text-lg / 2xl:text-xl */ [class*="2text-xl"] { font-size: 1.125rem; line-height: 1.75rem; } @media (min-width: 96rem) { [class*="2text-xl"] { font-size: 1.25rem; line-height: 1.75rem; } } /* NOT FIXED HERE — deliberately. A fourth class string has the same damage, in the projects section: relative py-24 md:py-16 py-32 2py-40 overflow-hidden Repairing it to py-24 / md:py-16 / xl:py-32 / 2xl:py-40 was measured and then removed again, because it is not part of the navigation and it moves things at sizes that were supposed to stay still: 375px section padding 128px -> 96px (page 64px shorter) 768px no change 1366px section padding 64px -> 128px (page 128px taller) 1440px same as 1366 That is a real bug and worth fixing in the source, but it is a visible layout change on phone and laptop, so it is left alone here. */ /* -------------------------------------------------------------------------- B. Article breadcrumb — the root cause, not a nudge. The breadcrumb is rendered, opaque and animated to opacity 1. It is simply underneath the navigation: the navbar is position:fixed and, from lg up, contains a w-28 h-28 (112px) logo, making it ~156px tall. The article's own top padding is lg:pt-36 = 144px. The breadcrumb line is 18px tall and starts at exactly 144px, so 12 of its 18px sit behind an opaque white bar (the navbar is bg-white/95 on every page that is not the homepage). Below lg the logo is hidden, the navbar is ~80px, and pt-24/md:pt-32 already clear it — so those sizes are deliberately left alone. Fixing it means giving the article enough room to clear the fixed header. ------------------------------------------------------------------------- */ @media (min-width: 64rem) { article[class*="lg:pt-36"] { padding-top: 11rem; } /* 176px vs 156px nav */ } /* -------------------------------------------------------------------------- C. Homepage hero — large desktop only (>= 1920px). The hero sits in a max-w-[1600px] container, so on a 1920 or 2560 screen it stays boxed in the left portion of the display while the heading is capped at lg:text-8xl (96px). The heading cannot simply be enlarged — the container has to grow first, and how much it can grow is set by the longest line in any language. Measured natural width per 100px of font-size, bold: hr 1057 / 1309 / 1301 en 1092 / 1165 / 1555 <- "in hospitality environments" is the cap it 1110 / 1225 / 1407 Against the 1440px of content the 1600px container gives, that English line needs 1493px at today's 96px — so it already wraps to two lines at every width, including 1920. Widening to 1800px (1640px of content) and going to 100px keeps it on ONE line with 5.2% headroom, which is both a larger heading AND one rendered line fewer in English than today. Bigger was tested and rejected: 104px leaves only 1.4% headroom, and 108px wraps again. The hero section is h-screen with overflow-hidden, so a wrapped English line pushes the stats row past the clip on a 1080-tall screen. Vertical cost matters as much as width here. ------------------------------------------------------------------------- */ @media (min-width: 1920px) { /* hero container: 1600 -> 1800, giving 1640px of content width */ [class*="max-w-[1600px]"][class*="lg:pt-48"] { max-width: 1800px; } /* 96px -> 100px, with line-height trimmed 1.1 -> 1.05 to offset the extra height. Margins are deliberately left alone. */ [class*="lg:text-8xl"][class*="block"] { font-size: 6.25rem; line-height: 1.05; } } /* -------------------------------------------------------------------------- D. Partner / client logo fades — any width where the bug exists. The marquee section is full-bleed with overflow-hidden, but the two fade overlays are absolutely positioned inside the max-w-7xl (1280px) container. Up to about 1330px those coincide with the viewport edges, which is why it looks right on laptops. At 1920 the container spans 320..1600, so the fades land at 320 and 1472 while logos run edge to edge — the gradient stops in the middle of the logo strip and the cutoff shows. Anchoring them to the viewport edge and widening them to span the gutter plus the original 8rem keeps a single smooth fade at any width. The overshoot from 100vw including the scrollbar is harmless: the section clips it. Note the breakpoint: 1330px, not 1920px. The container stops tracking the viewport as soon as it hits its 1280px cap, which happens at 1328px wide — so the gap between the fade and the real screen edge opens up from there and simply keeps growing. Gating this at 1920 left every window between 1330 and 1919 with the bug still visible. `100%` inside the calc resolves against the containing block, which IS the 1280px wrapper, so this needs no hard-coded width and is correct at 1366, 1512, 1920, 2560 and anything else. ------------------------------------------------------------------------- */ @media (min-width: 1330px) { [class*="bg-gradient-to-r"][class*="from-white"][class*="pointer-events-none"] { left: calc((100vw - 100%) / -2); width: calc((100vw - 100%) / 2 + 8rem); } [class*="bg-gradient-to-l"][class*="from-white"][class*="pointer-events-none"] { right: calc((100vw - 100%) / -2); width: calc((100vw - 100%) / 2 + 8rem); } } /* -------------------------------------------------------------------------- E. Blog hero — vertical balance under the fixed navbar. The /novosti banner is `pt-40 pb-20` = 160px above, 80px below. But 156px of that top padding is hidden behind the fixed navbar, so what you actually see inside the orange band is 4px of space above the BLOG badge and 96px below the subtitle. That is what reads as "not centred". Raising the top padding to 252px (156 navbar + 96) makes the visible margins match at 96px top and bottom. Only applied from lg up, because below that the navbar is 88px tall and the band is already balanced (72px above, 96px below). ------------------------------------------------------------------------- */ @media (min-width: 64rem) { [class*="bg-[#fa4616]"][class*="pt-40"][class*="overflow-hidden"] { padding-top: 15.75rem; /* 252px */ } } /* -------------------------------------------------------------------------- F. Homepage hero — make the height follow the content. Root cause of the hidden CTA, the "next section overlaps the hero" and the "content does not fit vertically" reports. The hero is:
That is a FIXED height (height:100vh, or 70vh between 768 and 1023) plus overflow:hidden. When the content needs more room than the viewport is tall, the surplus is simply clipped — and because the next section starts immediately after a box that is exactly 100vh, it looks like that section is sitting on top of the hero. Nothing actually overlaps and no z-index is wrong; the content is cut off. Measured clipping before this rule (content bottom vs section bottom): 320x568 303px clipped CTA not visible 375x667 139px clipped CTA not visible 768x1024 174px clipped 1024x768 450px clipped CTA not visible 1366x768 258px clipped CTA not visible 1440x900 30px clipped 1920x1080 fits 2560x1440 fits Fix: height:auto with min-height carrying the old value. On a tall screen the section is still exactly 100vh and nothing moves; on a short one it grows to fit and the next section starts below it. No fixed heights, no change to the decorative layers, and overflow:hidden stays — it is what keeps the -left-32 decoration from causing a horizontal scrollbar, and it no longer clips anything that matters once the box can grow. The inner container's h-full (height:100%) is overridden to auto rather than left to resolve against an auto-height parent, because browsers have historically disagreed about percentage heights against a parent that has min-height but auto height. Being explicit removes that difference — it is the Safari/Firefox-vs-Chrome case behind the cross-browser report. ------------------------------------------------------------------------- */ /* SELECTOR SCOPE — read before touching this. The homepage hero is one of EIGHTEEN sections whose class list contains h-screen + w-full + overflow-hidden. Matching on those three caught all of them, including every subpage hero and (because [class*="h-screen"] also substring-matches "min-h-screen") one more besides. That mattered because the subpage heroes are built differently. They use:
i.e. they have NO top padding — the content is vertically centred inside a fixed-height box, and that centring is the only thing holding the heading clear of the fixed navbar. Turn the parent into auto-height and h-full (height:100%) collapses, justify-center has nothing left to distribute, and the content jumps to the top of the section, straight under the navbar. The homepage hero is the only one that positions its content with top padding (pt-24 md:pt-40 lg:pt-48) instead of centring, which is what makes auto-height safe there and unsafe everywhere else. So the selector below keys on `xl:h-screen` AND `md:h-[70vh]` — each occurs exactly once in the bundle, and only on the homepage hero. */ section[class*="xl:h-screen"][class*="md:h-[70vh]"] { height: auto; min-height: 100vh; } @media (min-width: 48rem) and (max-width: 63.999rem) { section[class*="xl:h-screen"][class*="md:h-[70vh]"] { min-height: 70vh; } } /* Content column: stop height:100% from fighting the auto-height parent, and give the content room to breathe once the section grows past the fold. Safe here precisely because this column is top-padded, not centred. */ section[class*="xl:h-screen"][class*="md:h-[70vh]"] > [class*="max-w-[1600px]"][class*="lg:pt-48"] { height: auto; padding-bottom: 4rem; } /* -------------------------------------------------------------------------- G. Industry hero — back link colliding with the category badge. Reported in Opera at FHD; reproduced here at 1560x715, which is what a 1920x872 window looks like at ~120% zoom (the navbar measures ~190px in the report against 156px at 100%, which is the giveaway). The two elements are positioned by completely different systems:
<- back link
<- content The back link is pinned at a FIXED 160px from the top of the section. The badge lives inside a vertically CENTRED column, so its position is a function of viewport height. Shorten the viewport and the centred block climbs until it reaches the pinned link. Measured badge top vs the link's 160..184 band: 1920x872 249 65px clear 1440x760 193 9px clear 1366x768 197 13px clear 1560x715 171 OVERLAP 13px <- the reported case 1600x700 163 OVERLAP 20px 1520x690 158 OVERLAP 18px 375x667 155 OVERLAP 15px <- also broken on phones Centred content crosses the safe line at about 820px of viewport height, so everything below is height-scoped: taller viewports are untouched. Below that the column stops centring and starts below the link instead, and the section is allowed to grow so the bottom is not clipped — the same fix as the homepage hero, applied only where and when it is needed. `className="mt-24"` occurs exactly 5 times in the bundle, always on these heroes, which is what makes :has() safe to scope with here. ------------------------------------------------------------------------- */ @media (max-height: 820px) { section[class*="h-screen"]:has(> [class*="top-40"]) { height: auto; min-height: 100vh; } [class*="justify-center"][class*="h-full"]:has(> [class~="mt-24"]) { height: auto; min-height: 100vh; justify-content: flex-start; padding-top: 10rem; /* 160px -> badge lands at 224, a 40px gap under the link */ padding-bottom: 4rem; } /* The wrapper's own 96px top margin would stack on that padding. */ [class*="justify-center"][class*="h-full"]:has(> [class~="mt-24"]) > [class~="mt-24"] { margin-top: 0; } }