/* ========================================================================== incuba-base.css - camada comum Incuba.Açores sobre o Design System Carregado depois de cssnovo-style.css (que não se edita) pelo Frontoffice, pelo Backoffice e pelo ecrã de login. Só contém o que serve os dois lados: 1. Tokens --gra-* (Backoffice) e --brand-* (papéis de marca) 2. Compatibilidade correções de limitações do DS, sem identidade de marca O que é exclusivo do Frontoffice vive em incuba-frontoffice.css; as regras .bo-* vivem em backoffice/assets/backoffice.css. O Backoffice NÃO carrega incuba-frontoffice.css (isolamento de CSS, 2026-11). ========================================================================== */ /* ========================================================================== 1. TOKENS ========================================================================== */ /* 1.1 Aliases --gra-*, --shadow-* e --font-family Nomes herdados do protótipo, a apontar para a rampa do DS (sem cores novas). Só o Backoffice os lê (backoffice.css e estilos inline); o Frontoffice usa --color_* ou os --brand-* de 1.2. */ :root { /* Azul */ --gra-blue-900: var(--color_blue_900); --gra-blue-800: var(--color_blue_800); --gra-blue-700: var(--color_blue_700); --gra-blue-600: var(--color_blue_600); --gra-blue-500: var(--color_blue_500); --gra-blue-300: var(--color_blue_300); --gra-blue-200: var(--color_blue_200); --gra-blue-100: var(--color_blue_100); --gra-blue-50: var(--color_blue_100); /* o DS não tem passo "50" */ /* Âmbar (rampa amarela do DS) */ --gra-amber-100: var(--color_yellow_100); --gra-amber-200: var(--color_yellow_200); --gra-amber-600: var(--color_yellow_600); --gra-amber-700: var(--color_yellow_700); --gra-amber-800: var(--color_yellow_800); /* Neutros (rampa cinzenta do DS) */ --gra-neutral-100: var(--color_gray_100); --gra-neutral-400: var(--color_gray_400); --gra-neutral-500: var(--color_gray_500); --gra-neutral-600: var(--color_gray_600); --gra-neutral-700: var(--color_gray_700); --gra-neutral-800: var(--color_gray_800); /* Feedback semântico */ --gra-error: var(--color_error_600); --gra-success-lightest: var(--color_success_200); --gra-success: var(--color_success_600); --gra-info-lightest: var(--color_info_200); --gra-info: var(--color_info_600); /* Sombras: o DS só tem a escala sm/base/lg do Bootstrap */ --shadow-xs: var(--bs-box-shadow-sm); --shadow-s: var(--bs-box-shadow-sm); /* Tipografia: o Lato é importado no topo de cssnovo-style.css */ --font-family: "Lato", -apple-system, "Segoe UI", Roboto, Helvetica, Arial, sans-serif; } /* 1.2 Tokens de marca --brand-* Um nome por papel, a apontar para a rampa do DS. As regras do tema (secções 5 a 8) usam estes nomes em vez de --color_yellow_* / --color_gray_*, por isso trocar a identidade visual é alterar só os valores abaixo. Valores = os que o tema amarelo do Frontoffice já usava em cada papel. Estão em :root porque o Backoffice também carrega este ficheiro: lê os de superfície e texto do modo escuro e, no ecrã de login, o tema completo (o resto do Backoffice usa só o DS e os tokens do backoffice.css). */ :root { /* Acento: preenchimentos e realces; texto sobre fundo escuro */ --brand-accent: var(--color_yellow_400); --brand-accent-hover: var(--color_yellow_500); /* hover de preenchimentos */ --brand-accent-active: var(--color_yellow_600); /* :active, selecionado */ --brand-accent-strong: var(--color_yellow_600); /* hover forte (acordeão, menus) */ --brand-accent-soft: var(--color_yellow_300); /* realce suave sobre escuro */ --brand-accent-pressed: var(--color_yellow_500); /* texto pressionado sobre escuro */ --brand-accent-focus: color-mix(in srgb, var(--brand-accent) 25%, transparent); /* anel de foco */ --brand-on-accent: var(--color_black); /* texto/ícone sobre o acento (14,79:1) */ /* Texto */ --brand-text-on-light: var(--color_yellow_900); /* sobre branco/tintas: único passo AA */ --brand-text-on-dark: var(--color_gray_200); /* sobre superfícies escuras */ /* Tintas claras (100/200: fundos; 300: contornos) */ --brand-tint-1: var(--color_yellow_100); --brand-tint-2: var(--color_yellow_200); --brand-tint-3: var(--color_yellow_300); /* Cromado estrutural (navbar, rodapé, painéis) em cinzento neutro */ --brand-chrome-1: var(--color_gray_800); --brand-chrome-2: var(--color_gray_900); --brand-chrome-light: var(--color_gray_200); /* faixa clara (rodapé escuro, fundo do login) */ --brand-on-chrome: var(--color_white); /* texto sobre o cromado escuro */ --brand-on-chrome-light: var(--color_black); /* texto sobre o cromado claro */ /* Superfícies e contornos */ --brand-surface-light: var(--color_white); --brand-surface-dark: var(--color_black); --brand-surface-dark-raised: var(--color_gray_900); --brand-surface-dark-hover: var(--color_gray_800); --brand-border-dark: var(--color_gray_700); } /* ========================================================================== 2. COMPATIBILIDADE COM O DS Correções de limitações do DS (cópia do template de login, ícones da navbar, contraste dos utilitários no modo escuro, hover de .gra-link). Sem identidade de marca: serviriam a qualquer equipa que use o DS. ========================================================================== */ /* area-membro.php's login screen (see its own comment at the markup site): the DS's real login template classes exist in cssnovo-style.css, but every declaration is scoped "body.templateIniciarSessao ..." - the DS's own demo puts this class on itself (a standalone page with no navbar/footer). We keep navbar/footer around this page (explicit ask), so the class sits on a wrapper
instead - which the vendor's body-qualified selectors then never match. Re-declared here verbatim (values copied 1:1 from the live matched rule, confirmed via getComputedStyle - not guessed from the minified bundle, which has burned this exact "which ancestor is this actually scoped to" mistake more than once this session already) against the unscoped class names, minus the DS-hosted stock background-image (/img/bg/image.png) we don't have locally and won't hotlink - the same var(--color_blue_400) background-color the class already falls back to stands in for it. */ /* position:absolute + top/left:50% + transform:translate(-50%,-50%) (cssnovo's own centering, still re-declared 1:1 above until this point) doesn't reserve any space for .sectionLogin in its parent's layout - an absolutely-positioned element contributes 0 to the height of a `min-height` parent that has no other in-flow children. On a short viewport (a laptop at ~700px tall, e.g.) the login card's real content height (title/subtitle + form fields) exceeds .templateIniciarSessao's 100vh, so the card overflows equally above AND below its centered point - clipped into the navbar at the top, overlapping the footer at the bottom (confirmed live, 2026-09). Flex-centering the parent instead keeps the exact same centered-card look when content fits within 100vh, but - unlike absolute+transform - lets the parent's height grow past min-height to fit a taller card when it doesn't, since the card is now a normal in-flow flex child instead of being removed from flow. padding-block on the parent is the "breathing room above/below the card on a short viewport" - the card no longer touches the very edge of the navbar/footer once it has to grow. */ .templateIniciarSessao { position: relative; background-color: var(--color_blue_400); min-height: 100vh; margin: 0; display: flex; align-items: center; justify-content: center; padding-block: 40px; } .templateIniciarSessao .sectionLogin { position: static; margin: auto; max-width: 640px; width: 100%; height: auto; padding: 64px 120px; border-radius: 16px; box-shadow: 0 4px 40px rgba(31, 95, 175, .1); background-color: var(--brand-surface-light); } .templateIniciarSessao .sectionLogin .content { text-align: center; } .templateIniciarSessao .sectionLogin .content .logo { max-width: 275px; width: 100%; object-fit: cover; margin-bottom: 44px; } .templateIniciarSessao .sectionLogin .content label { text-align: left; } /* Dark-mode pair for the two rules above (same source: the real body.templateIniciarSessao.dark-mode / body.templateIniciarSessao.dark- mode .sectionLogin values, re-scoped the same way and for the same reason - live-verified, not the DS's dark-mode stock photo). Caught live before shipping: without this, .sectionLogin stayed white while .gra-text-blue-800's own .dark-mode override (elsewhere in this file) repaints the title a light gray meant for a DARK card - light-gray-on- white, nearly invisible. */ .dark-mode .templateIniciarSessao { background-color: var(--brand-chrome-light); } .dark-mode .templateIniciarSessao .sectionLogin { background-color: var(--brand-surface-dark); } /* Navbar icon-visibility fix: the DS's own .icon/.icon-moon rules in cssnovo-style.css don't set a color for these two icons when used bare (not inside a .icon-primary/.icon-secondary button), so on our dark header-primary background they inherit near-black and become invisible. Force it white in that one context. (.arrow-right, the language-flyout chevron this rule used to also cover, was removed from navbar.php entirely when that flyout became a popup - dropped here too, dead selector otherwise.) */ .gra-desktop-header.header-primary .toggleTheme:before { color: var(--brand-on-chrome); } /* Active nav item's text-shadow "bold" effect (the same 1px-offset- shadow-matching-text-color trick :hover already uses) resolves to the wrong color on header-primary's dark background, making it effectively invisible - confirmed live via a matched-CSS-rules query (getComputedStyle alone doesn't show provenance; static reading of the minified bundle is unreliable for this file, per this project's own repeated history of misreading its near-duplicate theme-scoped rules). Two DIFFERENT vendor rules are in play, at different specificities, and they disagree: the generic (not header-primary- scoped) ".gra-desktop-header ul.menu li.menu-first-level.active" sets both color AND text-shadow to blue_800; a separate, MORE specific header-primary rule for color alone (not text-shadow) already forces white text for every nav item regardless of active state, so color renders correctly - but nothing equivalent exists for text-shadow, so the generic rule's blue_800 shadow wins by default, blending into the dark-blue header (near-invisible). The DS DOES ship a real white-shadow rule for exactly this active-state case, but it's gated behind ".theme-marca-servicos", which this site never sets on (confirmed live: zero matching rules without that gate) - so it never applies here, same root cause as this file's other .theme-marca-servicos-gated near-misses. Dark mode's own active-state rule doesn't have this problem (color and text-shadow both already resolve to the same var(--color_gray_100), self-consistent) - fix scoped to :not(.dark-mode) explicitly: this selector and ".dark-mode .gra-desktop-header ul.menu li.menu-first-level.active" tie exactly on specificity (5 classes/2 elements each), so without the guard this rule - loading after cssnovo-style.css - would win the cascade tie-break in BOTH modes and break dark mode's already- correct gray_100 shadow (caught live before shipping, not hypothetical). */ body:not(.dark-mode) .gra-desktop-header.header-primary ul.menu li.menu-first-level.active { text-shadow: 1px 0 0 var(--brand-on-chrome); } /* .gra-text-yellow-700 / .gra-text-blue-500 (team member popup role label + section headings, team-grid.php/sobre.php/reserva.php/ area-membro.php): both fail WCAG AA even in LIGHT mode against a white card (measured 2.67:1 and 4.34:1, need 4.5:1) - a genuine contrast bug in the DS's own hardcoded hex, unrelated to dark mode. Swapped for the nearest darker step on each ramp that actually passes (yellow_900 ~8.2:1, blue_600 ~5.3:1). */ .gra-text-yellow-700 { color: var(--brand-text-on-light) !important; } .gra-text-blue-500 { color: var(--color_blue_600) !important; } .dark-mode .gra-text-yellow-700 { color: var(--brand-accent) !important; } /* .gra-text-gray-400 (widely used for date/meta captions - gallery album dates, initiative dates, etc.): hardcoded #949494 fails against white in light mode (2.86:1) but - being a fixed hex not a var() - happens to pass fine against black in dark mode by accident, so only the light-mode base rule needs fixing; the dark-mode override below keeps it light so it doesn't regress against the near-black background once the base rule darkens it for light mode. */ .gra-text-gray-400 { color: var(--color_gray_500) !important; } .dark-mode .gra-text-gray-400 { color: var(--color_gray_300) !important; } /* .gra-background-blue-100 (used all over as a light-tint background: image/map placeholders, FAQ's active category pill, etc.): same hardcoded-#F5F9FB-forever pattern as every other .gra-background-* utility above. Fixing it at the source here - rather than chasing every individual "text painted for a dark bg turns invisible because THIS particular blue-100 box never actually went dark" symptom downstream - reuses the value cssnovo-style.css's own .sectionCards and .iconsContentPage .gra-background-blue-100 rules already use for this exact swap, so it stays visually consistent with what little real dark-mode coverage the DS does ship. */ .dark-mode .gra-background-blue-100 { background-color: var(--brand-surface-dark-raised) !important; } /* .gra-background-white (contactos.php's location cards, and likely elsewhere): same pattern again - a bare "#fff!important" dark-mode coverage only exists nested under ".dark-mode .templateDetailsA .contentPageText .gra-background-white" /".dark-mode .templateDetailsBackoffice", chains our markup doesn't match. Reuses the same #000 value those wrapper-gated rules already use. */ .dark-mode .gra-background-white { background-color: var(--brand-surface-dark) !important; } /* Card/tile definition in dark mode: .gra-card-informative.neutral goes pure #000 in dark mode (cssnovo-style.css's own rule), which is IDENTICAL to the page background (also #000), so every "card" - homepage news cards, espaço room cards, team cards - loses its edge entirely, no visible boundary at all. Same problem for .gra-background-white (contactos.php's location cards) and for var(--bs-box-shadow) (a fixed rgba(0,0,0,.15) shadow, invisible on a black page - used on those same location cards and on iniciativa.php's related-gallery box). A visible border fixes all of these at once, and doubles as the box-shadow's replacement since a black-on-black shadow can never read as a shadow anyway. */ .dark-mode .gra-card-informative, .dark-mode .gra-background-white { border: 1px solid var(--brand-border-dark); } .dark-mode .gra-card-informative.neutral { background-color: var(--brand-surface-dark-raised) !important; } /* The override above is !important so it also beats cssnovo-style.css's own .dark-mode .gra-card-informative.neutral:hover rule (no !important) at ALL times, including on hover - which silently killed the hover feedback on every neutral card (index.php's Últimas Notícias/Parceiros). Restores the same one-step-up shift the vendor's own hover rule used (gray_900 -> gray_800), just based off our own resting color instead of #000. */ .dark-mode .gra-card-informative.neutral:hover { background-color: var(--brand-surface-dark-hover) !important; } /* .gra-text-blue-800 heading fix: cssnovo-style.css hardcodes this utility class to a fixed #25536f (no var(), no .dark-mode override at all except inside one narrow official wrapper chain we don't use - .templateDetailsA .contentPageText .gra-text-blue-800). Site-wide, every page title/section heading uses the class bare, so on a dark background it stays permanently dark-navy-on-black (fails contrast). Reuse the same substitution value the DS's own wrapper-scoped rule already uses. */ .dark-mode .gra-text-blue-800 { color: var(--brand-text-on-dark) !important; } /* Same root cause, same fix, for the other utility classes used everywhere for subtitles/secondary text/small accent links (.gra-text-gray-500/600/700, .gra-text-blue-500): cssnovo-style.css hardcodes each to its light-mode hex with !important and never redefines it under .dark-mode, so on a dark background they render as dark-gray-on-black / dark-blue-on-black, well under WCAG AA (measured 1.5-3.7:1 with a DOM contrast audit across several pages, need 4.5:1). Swapped for light, still-muted equivalents. */ .dark-mode .gra-text-gray-500, .dark-mode .gra-text-gray-600 { color: var(--color_gray_300) !important; } .dark-mode .gra-text-gray-700 { color: var(--brand-text-on-dark) !important; } .dark-mode .gra-text-blue-500 { color: var(--color_blue_300) !important; } /* .gra-text-blue-600 (Task 6 sitewide sweep): same bug-#6 pattern, found live via a DOM contrast audit on sucesso.php/404.php's "Voltar"/quick links, which sit inside a .gra-card-informative.neutral card - #292929 in dark mode. Measured 2.73:1 (fails AA) - same fix approach as the -500 step above, one step lighter on the ramp. */ .dark-mode .gra-text-blue-600 { color: var(--color_blue_300) !important; } /* .gra-text-blue-700 (final whole-branch review): same bug-#6 pattern, missed by the Task 6 sweep. Used as foreground-only text on espaco.php, servicos.php, team-grid.php, reserva.php against backgrounds that do go dark (some via this file's own overrides, e.g. .dark-mode .gra-background-blue-100). Measured 2.26-3.27:1 (fails AA) - same fix approach as the -500/-600 steps above. */ .dark-mode .gra-text-blue-700 { color: var(--color_blue_300) !important; } /* .gra-text-success-600 (final whole-branch review): same bug-#6 pattern. Used on agenda.php/area-membro.php table cells against .dark-mode .gra-table.responsive-vertical td's #000 background. Measured 2.14:1 (fails AA). Reuses --color_success_200, the same lighter success step this file's own --gra-success-lightest mapping already points at. */ .dark-mode .gra-text-success-600 { color: var(--color_success_200) !important; } /* .gra-text-blue-900 (found as a direct consequence of the Fix 2 comment- bubble change above, area-membro.php:466): moving the bubble background off a no-dark-variant inline style onto .gra-background-blue-100/ gray-100 correctly darkens the bubble now - but the message-body text inside it uses .gra-text-blue-900, hardcoded to #173344 with no .dark-mode override anywhere. It was only ever safe because the bubble background never actually went dark before; once it does, this dark-navy-on-near-black measures 1.10:1 (blue-100 bg) / 1.59:1 (gray-100 bg) - both fail AA. Same bug-#6 pattern and same fix approach as the -500/-600/-700 steps above (ramp-lightening to -300; no official DS wrapper-scoped rule exists for -900 to match, unlike -800's gray_200 pick). */ .dark-mode .gra-text-blue-900 { color: var(--color_blue_300) !important; } /* Same-hue-badge exception to the -600/-900 overrides above: those two overrides correctly fix TEXT sitting on a page/card background that goes dark, but gra-text-success-600/gra-text-blue-900 are ALSO used as an ICON color inside a badge tinted the same hue (.gra-background-success-200, .gra-background-yellow-200/500) - and those badge backgrounds have no .dark-mode override of their own, so they stay light. The blanket override above repaints the icon lighter there too, making it near-invisible against its own still-light badge (measured ~1:1-1.5:1). Restore the original light-mode color specifically inside/on these badges, where it was already correct before either override existed. */ .dark-mode .gra-background-success-200 .gra-text-success-600, .dark-mode .gra-text-success-600.gra-background-success-200 { color: var(--color_success_600) !important; } .dark-mode .gra-background-yellow-200 .gra-text-blue-900, .dark-mode .gra-background-yellow-500 .gra-text-blue-900 { color: var(--color_blue_900) !important; } /* Same exception, for the icon-circle badges the yellow->primary-blue color sweep introduced (index.php's Serviços cards, servicos.php, ferramentas.php, contactos.php): .gra-background-blue-200 has no .dark-mode override of its own either (stays the same pale blue), but .gra-text-blue-800 does (repainted to gray_200 above, for TEXT on a page/card background that goes dark) - gray-on-pale-blue is just as invisible as the yellow-badge case this mirrors. */ .dark-mode .gra-background-blue-200 .gra-text-blue-800, .dark-mode .templateDetailsA .contentPageText .gra-background-blue-200 .gra-text-blue-800 { color: var(--color_blue_800) !important; } /* .gra-btn.btn-primary inside a .gra-table (e.g. agenda.php's "Inscrever-me" button in the Ação column): the DS's own generic dark-mode table-link rule (.dark-mode .gra-table-wrapper .gra-table tbody tr td a{color:#fff}) has higher selector specificity than .dark-mode .gra-btn.btn-primary (6 chained ancestors vs 2 classes), so it wins and paints the button's text white on its own light-gray (--color_gray_200) dark-mode background - an invisible button. !important reasserts the button component's own color regardless of which container it's placed in. */ .dark-mode .gra-btn.btn-primary { color: var(--brand-on-accent) !important; } /* .gra-background-gray-100 (area-membro.php's logged-out login-card wrapper): same hardcoded-utility-class pattern as everything else above - #F7F7F7 in both themes, no .dark-mode redefinition - so this one section never goes dark while the rest of the page does. Without this, the .gra-text-blue-800/.gra-text-gray-500 fixes above actively make things worse here (light text now painted on a background that never left this section as light gray page-background). */ .dark-mode .gra-background-gray-100 { background-color: var(--brand-surface-dark) !important; } /* .gra-link (site-wide "Saber mais →" / footer links) and "body .pageContent p a" (links inside admin rich-text content, e.g. FAQ answers, legal pages, iniciativa bodies) both resolve to var(--color_blue_800) with no .dark-mode override in cssnovo-style.css. --color_blue_800's own dark value (#3077DD) is borderline even against pure black (~4.8:1) and fails outright against the slightly lighter card grays most of this content actually sits on (measured 1.76:1 on FAQ answer links inside .gra-card-informative). */ .dark-mode .gra-link, .dark-mode .pageContent p a { color: var(--color_blue_300) !important; } /* Exception: the footer intentionally stays a light gray strip in dark mode (.dark-mode .gra-footer-opt-2{background:var(--color_gray_200); color:#000} - a real, deliberate DS rule, confirmed against .theme-marca-servicos.dark-mode being the only variant that goes black). The blanket .gra-link fix above would paint its links pale blue on that light background - reassert black here. */ .dark-mode .gra-footer-opt-2 .gra-link { color: var(--brand-on-chrome-light) !important; } /* Same exception, mirrored for the navbar: .gra-desktop-header.header-primary is always dark navy in both themes (never the near-black page body this blanket fix targets), same as the footer case above. Without this, the language flyout's "PT" .gra-link went pale blue-300 while its sibling theme-toggle icon in the same dropdown stayed white (a real DS rule, untouched) - inconsistent, and the reason to fix stayed cosmetic here rather than a contrast failure (blue-300 still reads fine on navy), but the two should match. */ .dark-mode .gra-desktop-header.header-primary .gra-link { color: var(--brand-on-chrome) !important; } /* .gra-link (the DS's generic text-link component - "Saber mais", "Ver todas as FAQs", the footer's Acessibilidade/Política/Termos, etc., used sitewide) ships with no hover/focus rule of its own in cssnovo-style.css for this site's plain theme - its only :hover rule in the bundle is scoped under .theme-marca-servicos.dark-mode, a brand variant this site never uses. Every .gra-link on the site has been silently missing hover feedback since launch. Base color is --color_blue_800 (light) / --color_gray_200 (dark, cssnovo-style.css) - shifted one step toward the page's edges (blue-600 / white) plus an underline so the change registers for anyone who can't distinguish the color shift alone. */ .gra-link:hover, .gra-link:focus-visible { color: var(--color_blue_600) !important; text-decoration: underline; } .dark-mode .gra-link:hover, .dark-mode .gra-link:focus-visible { color: #fff !important; } /* Popups (.gra-popup): correções genéricas do DS, também usadas pelo Backoffice. */ /* .popupHeader.no-border: cssnovo-style.css's REAL rule is actually `.gra-popup .popupContainer .popupHeader.no-border` (3 classes, specificity 0,3,0) - a first look at just the bare `.popupHeader.no- border{...}` declaration (2 classes, 0,2,0) undersold this, since that nested form is what's actually shipped; confirmed via the page's live computed style (paddingBottom stayed 0px until this selector was matched). It unsets BOTH border-bottom and padding-bottom together - correct when a header sits directly against a full-bleed image that already supplies its own visual gap, but espaco.php's three .popupHeader.no-border headers (sala-modal, postos-modal, "Agendar Visita") all sit above regular text content (badges/description) with no such gap, so the header text reads as flush against it. Restores just the same 16px bottom padding cssnovo-style.css's own un-modified .popupHeader already uses, keeping only the "no border line" half of .no-border's effect. Matches that same 0,3,0 specificity so this file's later load order (after cssnovo-style.css on every page) is what wins, no !important needed. Grep confirms no other page in the project pairs popupHeader with no-border, so this can't affect any popup outside espaco.php. */ .gra-popup .popupContainer .popupHeader.no-border { padding-bottom: 16px; } /* cssnovo-style.css's `.popupContainer` caps at a flat max-height:700px, with no relation to the actual viewport - fine on a normal desktop window, but on any screen shorter than ~700px (a phone in landscape, or just a short browser window) the popup - centered via position:fixed; top:50%/left:50%; transform:translate(-50%,-50%) - overflows equally above AND below the visible viewport (confirmed live via a same-origin iframe forced to innerHeight≈316px, 2026-09: the team-grid popup's header/close button ended up ~119px above the visible area, unreachable, while [data-richtext-editor]/.popupContent's own overflow-y:auto did nothing - the CONTENT fit inside its own box just fine, it's the outer box that was taller than the screen). Same symptom/fix shape as .templateIniciarSessao's own 100vh overflow comment above in this file, adapted to position:fixed+transform centering instead of flex - caps at the viewport height (minus a little breathing room) instead of a flat px value, so it can never be taller than the screen that's meant to show it. dvh (dynamic viewport height, accounts for mobile browser chrome) with a plain vh fallback for older browsers; older browsers just keep the vh line since an unsupported dvh declaration is ignored. Every `.gra-popup .popupContainer` sitewide (team-grid.php's CV modal, espaco-popup-detalhe.php, institucional.php's marco/equipa popups, FAQ's popup, etc.) shares this one shape, so fixing it here fixes all of them at once instead of one component-scoped reset per page. Layered instead of replacing cssnovo-style.css's flat 700px outright: keeps that same 700px ceiling on a normal/tall screen (unchanged look everywhere this was already fine) and only shrinks below it once the viewport itself is shorter - min() falls back to the previous declaration in a browser that doesn't support it, same reasoning as the vh/dvh pair below it. */ .gra-popup .popupContainer { max-height: 700px; max-height: min(700px, calc(100vh - 32px)); max-height: min(700px, calc(100dvh - 32px)); }