/* ========================================================================== NIVAD PHARMED SALAMAT — Forced mobile view -------------------------------------------------------------------------- Every rule is scoped to html[data-view="mobile"]. The script switches this file's media attribute to "all" only in the mobile view, so it costs nothing in the other two — and even if it were always applied, none of it could match. WHY IT EXISTS. The phone layout does not live in mobile.css. It lives in style.css's @media (max-width: 1024px / 768px / 560px) blocks, and those cannot fire in a 1600px window. mobile.css is a POLISH layer that assumes the width breakpoints have already collapsed the page; enabled on its own at desktop width it produces a hybrid — most visibly a hamburger button that opens nothing, because .mobile-nav's display:block lives in the 768px block while mobile.css only ever sets its top, height and padding. WHAT IS AND IS NOT COPIED. Only the declarations mobile.css does not already cover. Re-stating a rule mobile.css owns would be actively harmful: these selectors carry an extra attribute (0,2,x), so they out-specify it and would undo the phone layout. .facilities-grid is the trap — style.css's 1024px block puts it at two columns, mobile.css puts it at one, and copying the two-column rule here would win. LOAD ORDER. Must stay the last stylesheet. Several rules below sit exactly one class above style.css and rely on source order for the ties. ========================================================================== */ /* ========================================================================== SIMULATED-PHONE SHELL (only above the mobile.css breakpoint) -------------------------------------------------------------------------- Sections 1 and 2 exist to make a wide window LOOK like a phone. Below 901px there is nothing to simulate — the window already is phone-sized, mobile.css is doing its normal job, and capping the page at 480px there would letterbox real phones and tablets that never had a letterbox before. The layout rules from section 3 onward are NOT gated: they are needed at every width in the mobile view, and they close a pre-existing gap between 769px and 900px where mobile.css hides the desktop nav but style.css has not yet shown the drawer, leaving no navigation at all. ========================================================================== */ @media (min-width: 901px) { /* ========================================================================== 1. PAGE SHELL — a centred phone-width column on a neutral backdrop -------------------------------------------------------------------------- The alternative — letting the phone layout stretch to full width — is not less work and reads worse. mobile.css hard-codes absolute magnitudes that cannot scale with the window: 14px grid gaps, 18px card padding, 44-52px touch targets. They are only right against a ~390-480px measure. 480px sits above the 380px small-phone refinement and below every other breakpoint, so it renders the mainstream phone case unambiguously. ========================================================================== */ html[data-view="mobile"] { --mf-w: 480px; /* A percentage in a fixed element's inset resolves against the initial containing block, which EXCLUDES the scrollbar. 50vw would include it and push every piece of fixed chrome a scrollbar's width off-centre. */ --mf-gutter: max(0px, calc(50% - (var(--mf-w) / 2))); background: #070f14; } html[data-view="mobile"]:not([data-theme="dark"]) { background: #dde5e9; } html[data-view="mobile"] body { max-width: var(--mf-w); margin-inline: auto; overflow-x: hidden; box-shadow: 0 0 0 1px rgba(0, 0, 0, .30), 0 0 90px rgba(0, 0, 0, .45); /* Never add transform, filter, perspective, backdrop-filter, will-change or contain here. Any of them makes the containing block for every position:fixed descendant, and the header would scroll away with the page. This is the classic trap for exactly this feature. */ } /* ========================================================================== 2. FIXED CHROME — re-inset into the column position:fixed resolves against the viewport, never against , so the column cap cannot reach any of these. There is no position:sticky anywhere in style.css, landing.css or mobile.css. ========================================================================== */ /* body::before is the fixed page grain, inset:0 — otherwise it bleeds across the whole backdrop. */ html[data-view="mobile"] body::before { left: var(--mf-gutter); right: var(--mf-gutter); } html[data-view="mobile"] .progress, html[data-view="mobile"] .header, html[data-view="mobile"] .mobile-nav, html[data-view="mobile"] .preloader { inset-inline: var(--mf-gutter); } html[data-view="mobile"] .assist-widget { inset-inline-end: calc(var(--mf-gutter) + 14px); } html[data-view="mobile"] .scroll-top { inset-inline-start: calc(var(--mf-gutter) + 14px); inset-inline-end: auto; } /* .assist-panel is absolute inside the fixed widget, so it follows — but both style.css and mobile.css cap its width with calc(100vw - 28px), which is the desktop viewport. `bottom` is the one declaration from style.css's 560px block that mobile.css never carried over: the button shrinks to 52px there but the panel keeps the 82px offset meant for a 66px button. */ html[data-view="mobile"] .assist-panel { max-height: min(70dvh, 560px); } /* The section-guide rail is already hidden by mobile.css; repeated so this file is correct on its own. */ html[data-view="mobile"] .section-guide { display: none !important; } /* The view menu is fixed to the header on mobile, so it needs the gutter too. */ html[data-view="mobile"] .view-menu { inset-inline-end: calc(var(--mf-gutter) + 14px); max-width: calc(var(--mf-w) - 28px); } } /* The assistant panel's offset is a plain fix, not part of the simulation, so it is not gated. style.css only supplies bottom:68px below 560px, while mobile.css shrinks the button to 52px at 900px — leaving a ~30px gap between button and panel across the whole 561-900px band. */ html[data-view="mobile"] .assist-panel { bottom: 68px; } /* ========================================================================== 3. LAYOUT COLLAPSE — replicated from style.css's breakpoint blocks ========================================================================== */ /* --- from @media (max-width: 768px) ------------------------------------- */ /* THE critical one. style.css's base rule is display:none and mobile.css only ever sets top/height/padding/overflow/background. Without this the drawer never appears and the site has no navigation in the forced mobile view. */ html[data-view="mobile"] .mobile-nav { display: block; } /* Defensive: mobile.css only gets this incidentally, via the display: inline-flex in its .tool-btn/.menu-toggle sizing rule. */ html[data-view="mobile"] .menu-toggle { display: inline-flex; } /* With .nav hidden and no auto margin in the base rule, the tools and the hamburger collapse against the logo. */ html[data-view="mobile"] .header-tools { margin-inline-start: auto; } /* mobile.css covers plain .product-row but cannot beat .product-row.reverse, and never resets `direction`. */ html[data-view="mobile"] .product-row.reverse { grid-template-columns: 1fr; gap: 20px; direction: rtl; } html[lang="en"][data-view="mobile"] .product-row, html[lang="en"][data-view="mobile"] .product-row.reverse { direction: ltr; } /* The wide-band veil would otherwise stay at its desktop gradient. */ html[data-view="mobile"] .innovation .veil { background: linear-gradient(to top, rgba(4, 18, 26, .96), rgba(7, 38, 50, .72)); } /* --- from @media (max-width: 1024px) ------------------------------------ */ /* .about-two-col is live on the about page, its base is two equal columns, and mobile.css never touches it — so without this the about page renders two columns inside a 444px measure. The gap is tightened from the 50px tablet value to the phone rhythm. */ html[data-view="mobile"] .split, html[data-view="mobile"] .about-two-col { grid-template-columns: 1fr; gap: 28px; } /* 560px is a tablet cap; inside the column it has to be the full width. */ html[data-view="mobile"] .media-frame { max-width: 100%; width: 100%; margin: 0 auto; } /* Cancels the decorative card stagger. Future-proofing — .prod-grid--art is in no page today. */ html[data-view="mobile"] .prod-grid--art .prod-card:nth-child(even), html[data-view="mobile"] .prod-grid--art .prod-card:nth-child(odd) { transform: none; } /* --- from @media (max-width: 560px) ------------------------------------- */ /* .assist-quick is deliberately NOT forced to one column here. style.css does that below 560px, but one column makes the panel taller than its own max-height and pushes the questions past the clip line — mobile.css sets two columns for exactly that reason, and this file must not out-specify it. */ /* Dead classes today; one line of insurance each. */ html[data-view="mobile"] .bento { grid-template-columns: 1fr; } html[data-view="mobile"] .b-feature { grid-column: auto; } /* DELIBERATELY NOT REPLICATED — each would out-specify mobile.css and undo it: .hub-ring width 94vw is 1504px here; mobile.css already gives the correct width:100% tile grid. .facilities-grid 2-col mobile.css puts it at one column on purpose. .hub-node-label 10.5px mobile.css sets 13.5px for the tile layout. --header-h: 68px mobile.css sets 62px. .section-guide re-layout the rail is hidden outright. */ /* ========================================================================== 4. MEDIA QUERIES THAT CANNOT FIRE ON A DESKTOP POINTER A desktop has a fine pointer, so neither style.css's (hover:none) and (pointer:coarse) block nor mobile.css's (hover:none) block matches — leaving hover-only decoration alive under a layout built without it. main.js gates the matching scripts on the resolved view for the same reason. ========================================================================== */ html[data-view="mobile"] .hero-photo-glow { display: none; } html[data-view="mobile"] .hero-photo-base { filter: grayscale(.06) brightness(.34) saturate(1.1) contrast(1.04); } html[data-view="mobile"] .prod-card::after, html[data-view="mobile"] .contact-card::after, html[data-view="mobile"] .news-card::after, html[data-view="mobile"] .b-card::after { display: none; } html[data-view="mobile"] .hub-node-label { opacity: 1; visibility: visible; transform: none; } /* ========================================================================== 5. SNAP RELEASE -------------------------------------------------------------------------- There is deliberately no "undo the snap deck" block here. It would be dead code: data-view only changes across a reload, and on the far side of that reload landing.js declines to add .fullpage-active in the mobile view, so html[data-view="mobile"].fullpage-active can never be true. The deck is prevented, not reversed. ========================================================================== */ html[data-view="mobile"].home-snap { scroll-snap-type: none; } /* ========================================================================== 6. vw NEUTRALISATION (simulated column only) -------------------------------------------------------------------------- vw is viewport-relative, so the 480px column cap cannot reach it: in a 1600px window these rules still resolve against 1600px and render at their DESKTOP ceiling inside a 444px measure. Each selector is a class+element pair, which out-specifies mobile.css's bare-element type scale, so mobile.css cannot correct them either. The values are what the same rule produces on a real ~390px phone. Gated at 901px because that is the only place they are needed. Below it the clamps are already at their minimum and these rules would either do nothing or — for the four that do differ on a phone — override a value that was chosen for phones on purpose. Measured on a 390px viewport, ungating this block would take .about-two-col img from 320px to 220px, .careers-cols h3 from 22px to 20px, .jobvision-cta padding from 28px to 20px, and .page-hero-content h1 from 30px to 29.64px. None of those are improvements on hardware the original values were designed for. ========================================================================== */ @media (min-width: 901px) { html[data-view="mobile"] .hero-inner { padding-inline: 24px; } html[data-view="mobile"] .innovation-text h2 { font-size: 26px; } html[data-view="mobile"] .page-hero-content h1 { font-size: clamp(27px, 7.6vw, 32px); } html[data-view="mobile"] .about-text-block h2, html[data-view="mobile"] .about-text h2 { font-size: 24px; } html[data-view="mobile"] .cta-band h2 { font-size: 24px; } html[data-view="mobile"] .product-text h2 { font-size: 26px; } html[data-view="mobile"] .careers-cols h3 { font-size: 20px; } html[data-view="mobile"] .fac-num { font-size: 34px; } html[data-view="mobile"] .jobvision-cta__title { font-size: 22px; } html[data-view="mobile"] .jobvision-cta { padding: 40px 20px; } html[data-view="mobile"] .about-two-col .about-img img { height: 220px; } } /* Section rhythm. This one stays ungated on purpose — it is a fix, not a simulation. mobile.css sets `section { padding-block: 52px }` for phones, but every block-level rule below out-specifies it and keeps its own clamp(64px, 8vw, 100px): 100px in a wide window, and still 64px on a real phone. Applying 52px everywhere in the mobile view is what mobile.css asked for and never got. */ html[data-view="mobile"] .about-main, html[data-view="mobile"] .facilities, html[data-view="mobile"] .facilities-band, html[data-view="mobile"] .services, html[data-view="mobile"] .services-section, html[data-view="mobile"] .cta-band, html[data-view="mobile"] .product-section, html[data-view="mobile"] .product-block { padding-block: 52px; }