/* ==========================================================================
incuba-frontoffice.css - camada Incuba.Açores EXCLUSIVA do Frontoffice
Carregado depois de cssnovo-style.css e incuba-base.css pelo Frontoffice e
pelo ecrã de login do Backoffice (que usa o cartão de login do site). NUNCA
pelas páginas do Backoffice. Era a parte final de incuba-tokens.css, movida
sem reescrever regras e com a ordem relativa preservada.
As regras do tema excluem o Backoffice com a guarda
body:not(.templateDetailsBackoffice):not(.bo-login-body).
Nota: o login do Backoffice já não usa a classe .bo-login-body, por isso a
segunda exclusão não exclui nada. NÃO a retirar: conta como uma classe de
especificidade (0,1,0) em ~237 seletores e é ela que, por exemplo, mantém os
títulos .gra-text-blue-800 do cartão em amarelo contra a regra do DS
".dark-mode .templateDetailsA .contentPageText .gra-text-blue-800" (0,4,0).
Retirada num teste: 26 títulos de sobre.php passam de amarelo a cinzento.
Índice (numeração herdada de incuba-tokens.css)
3. Componentes cartões, listas e páginas do Frontoffice
5. Tema Incuba remapeamento amarelo do Frontoffice (5.1 a 5.4)
6. Componentes popups, hero e notificações
7. Tema estados ativos/selecionados
8. Componentes rodapé fixo, galerias, inscrições, identidades
9. Responsivo adaptação a mobile do Frontoffice (prefixo fo-)
10. Hour Picker acento do seletor de horas
11. Responsivo rodapé e Área de Membro em mobile
A ordem das regras conta: ao mover blocos, manter a ordem relativa das que
se sobrepõem.
========================================================================== */
/* ==========================================================================
3. COMPONENTES - CARTÕES, LISTAS E PÁGINAS
Regras da aplicação (Frontoffice): alturas fixas de cartões, tabelas, listas
laterais. Dependem de classes do DS e dos nomes próprios (.agenda-card-*, ...).
========================================================================== */
/* Equal-height cards site-wide: cssnovo-style.css's own .details .text
rule caps description text at max-height:168px but with
overflow-y:auto (a scrollbar inside the card, not a clean cutoff) -
titles and descriptions of different lengths still push cards in the
same row to different heights. Multi-line ellipsis clamp instead, on
both the title and the description, so every card in a
.gra-row-bs/.gra-col-bs-* grid ends up the same height regardless of
how much text the content actually has. */
.gra-card-informative .details .text,
.gra-card-text .details .text {
overflow: hidden;
text-overflow: ellipsis;
display: -webkit-box;
-webkit-line-clamp: 3;
-webkit-box-orient: vertical;
max-height: none;
}
.gra-card-informative .details .title,
.gra-card-text .details .title {
overflow: hidden;
text-overflow: ellipsis;
display: -webkit-box;
-webkit-line-clamp: 2;
-webkit-box-orient: vertical;
}
/* iniciativas.php card title: FIXED-size content slot (height, not just
max-height/line-clamp) rather than the site-wide rule above, which only
bounds the *maximum* - a short title still left the details area
shorter than a card with a full 2-line title next to it in the same row
(no real height:100% exists for a non-carousel .card-vertical - see the
ferramenta-card comment below), so rows still came out visibly uneven.
A plain height (always 2 lines' worth, 2 x cssnovo's .details .title
line-height of 28.8px) makes every card's title area identical
regardless of actual text length - a 1-line title just leaves blank
space inside its OWN fixed slot, not extra space added elsewhere to
compensate. -webkit-line-clamp is layered on top only for the "…"
glyph; the plain height + overflow:hidden is what actually guarantees
the cut lands on a line boundary even if line-clamp itself doesn't
render the ellipsis (see the agenda-card-details comment above for why
that can silently not fire in this Chrome build depending on ancestor
flex context - iniciativas.php's card is a plain block link like
ferramenta-card, not agenda.php's flex one, so verified live that clamp
DOES work here too, but the fixed height means it's not load-bearing
for consistent height either way).
The card's description was removed entirely (not just hidden) - see
iniciativas.php's card markup - so there is no .iniciativa-card-text
rule here anymore. */
.gra-card-informative.card-vertical .details .iniciativa-card-title {
height: 57.6px;
overflow: hidden;
text-overflow: ellipsis;
display: -webkit-box;
-webkit-line-clamp: 2;
-webkit-box-orient: vertical;
}
/* parceiros.php card grid: same "fixed content slot, not just a max-height
clamp" fix as .iniciativa-card-title above, applied to BOTH the title and
the description this time, so every partner card in a row ends up
exactly the same height regardless of how long the entity's name or
blurb is - a short title/description just leaves blank space in its own
fixed slot rather than shrinking the whole card.
Title: fixed 2-line slot (57.6px = 2 x cards.scss's 28.8px .details
.title line-height), overflow:hidden with no line-clamp/ellipsis at all
- explicit ask: partner names should never show a truncating "…", only
ever reserve the space for 2 lines. display/-webkit-line-clamp/
text-overflow are explicitly reset here (not just left unset) because
the site-wide `.gra-card-informative .details .title` rule above
already sets those same 3 properties - CSS cascades per-property, so a
more specific selector that stays silent on a property doesn't cancel a
less specific rule that does declare it; each one has to be named and
overridden here or the site-wide clamp/"…" would still win through.
Description: fixed 2-line slot (48px = 2 x cards.scss's 24px .details
.text line-height) WITH line-clamp for the "…" glyph, since descriptions
are free text and can genuinely run past 2 lines. The same
.partner-card-text rule is shared by servicos.php's card grid via
.servico-card-text (identical need: reserve a consistent 2-line
description slot so every service card in a row ends up the same
height) rather than duplicating the block for a second page.
display:flex + align-items:center (rather than plain block) vertically
centers shorter/smaller-font names within the fixed slot instead of
always sitting at the top, since parceirosTituloEstilo() in parceiros.php
can shrink long names well below the 57.6px slot height.
margin-top is knocked down from cards.scss's own `.card-vertical .details
.title { margin-top: 24px !important }` (needs matching !important to
win): the card's own DOM order is Imagem → Título → Descrição → rodapé
(parceiros.php's inline `style="display:block"` on the card link beats
cards.scss's `&.card-vertical { display:flex }`, so plain block-flow
stacking order is what actually renders - no flex `order` trickery
needed), .details starts right after the image with .title as its first
child, so this margin-top is the imagem→título gap. 12px keeps it close
to the base `.text { margin-top: 8px }` rule (untouched, título→
descrição) and the footer's own gra-margin-top-3xs (8px, descrição→
rodapé), so the rhythm between all three gaps reads even. */
.gra-card-informative.card-vertical .details .partner-card-title {
height: 57.6px;
overflow: hidden;
display: flex;
align-items: center;
text-overflow: clip;
-webkit-line-clamp: unset;
margin-top: 12px !important;
}
.gra-card-informative.card-vertical .details .partner-card-text,
.gra-card-informative.card-vertical .details .servico-card-text {
height: 48px;
overflow: hidden;
text-overflow: ellipsis;
display: -webkit-box;
-webkit-line-clamp: 2;
-webkit-box-orient: vertical;
}
/* Footer row ("Parceiro desde X" + tipo tag, same line, space-between):
fixed height matching .gra-tag's own natural rendered height (cards.scss:
8px vertical padding x2 + 16.8px line-height ≈ 32.8px, rounded to 33px)
so every card's footer reserves the same vertical slot even when a given
partner has no `desde` or no `tipo` (both nullable columns) and one or
both sides render empty - the row's own left/right label spans are
always in the DOM (see parceiros.php), just empty, so justify-content:
space-between still keeps whichever side IS populated pinned to its
correct edge instead of drifting to center. */
.partner-card-footer {
height: 33px;
}
/* agenda.php's card grid is 4-up (.gra-col-bs-xl-4, 25% width) instead of
the 3-up (33%) grid iniciativas.php/parceiros.php/galeria.php use, so
the shared .gra-card-informative .details .title rule above (24px font,
2-line clamp) was cutting real event titles off mid-word in these
narrower cards. Scoped down here instead of changed globally, since the
3-up pages have enough width for the DS default size already.
Title/description length is capped server-side (agendaTruncarTexto() in
agenda.php, word-boundary + "…") rather than via -webkit-line-clamp:
verified live that line-clamp silently stops truncating at all on a
descendant of a flex-grow .details spacer in this Chrome build
(getComputedStyle reports display:flow-root instead of -webkit-box) - a
plain character budget sidesteps that. The height below (not just
max-height) is what actually GUARANTEES the box never exceeds 3
lines/2 lines even in the rare case a string's real rendered width
doesn't quite match the character-count estimate: overflow:hidden still
cuts cleanly at a line boundary since the height is an exact multiple
of the line-height, independent of whether -webkit-line-clamp itself
renders anything.
.agenda-card-details no longer carries flex-grow:1 as an inline style
(agenda.php) - that was absorbing the ENTIRE row's leftover vertical
space as one gap between the description and the time/local/vagas
block, which is what made that gap look oversized once the description
stopped being long enough to fill it. Every piece of the card is now a
fixed size (image height, this title/description, the date-row/hora/
local/vagas single lines), so the card's natural content height is
already the same for every event without needing a flex spacer to
force it - EXCEPT cssnovo's own .gra-card-informative.card-vertical
.details{flex:1 0 auto} rule (a *class* rule, not inline) sets the same
flex-grow:1 regardless, so the gap didn't actually go away just by
deleting the inline style - verified live (flex-grow computed to "1"
from that class rule, gap unchanged). flex-grow:0 below overrides it.
font-size/height below need !important because cssnovo's own
same-specificity (0,0,3,0) .gra-card-informative .details .title rule
ties on specificity and otherwise wins - verified live without it. */
.agenda-card-details {
flex-grow: 0 !important;
}
.agenda-card-details .title {
font-size: 18px !important;
line-height: 24px !important;
}
.agenda-card-title {
height: 48px !important;
overflow: hidden !important;
}
.agenda-card-text {
height: 48px !important;
overflow: hidden !important;
}
/* Only the "Agendado" state tag (agendaRenderizarEstadoData()'s 'gra-tag
secondary alert' weight for agendaCalcularEstado()'s 'agendado' case) was
pushing the whole card's title/description/info block down ~16px versus
every other state ('a_decorrer'/'terminado'), even though total card
height already matched via .gra-row-bs's flex stretch - verified live
(getComputedStyle on the tag showed margin-bottom:16px for 'alert' only,
0 for 'success'/'danger'). Root cause: cssnovo-style.css also bundles
Bootstrap, whose OWN unrelated `.alert` component class sets
margin-bottom:1rem - the DS's "alert" color-weight name for tags
collides with Bootstrap's own component class name, so any
`.gra-tag...alert` picks up that stray 16px. Scoped reset here (not a
cssnovo-style.css edit, and not touching `.alert` sitewide) since this
header row only ever holds this card's estado/tipo tags.
Remaining ~4px still came from the estado tag's OWN weight: 'secondary'
(agendado/terminado) is cssnovo's outline style, 2px border added on
top of the same 8px/12px padding 'primary' (a_decorrer) uses without a
border, so the row itself was 36.8px tall (16px padding + 16.8px
line-height + 4px border) for agendado/terminado cards vs 32.8px for
a_decorrer/no-estado ones - a fixed difference by state, not by event
content, so no per-card variance could fix it. Pinning the row to the
taller value (same "reserve the real rendered size" technique as
.partner-card-footer above) and centering makes every state's row -
and therefore every title/description/info block below it - start at
the exact same position regardless of which estado tag's outline vs
filled. */
.agenda-card-tags {
min-height: 36.8px;
align-items: center !important;
}
.agenda-card-tags .gra-tag {
margin-bottom: 0 !important;
}
/* Same stray Bootstrap `.alert` margin-bottom:16px described above, hitting
the Agenda's tabela view instead of the card grid (2026-09) - the estado
tag sat visibly higher than the tipo tag in the same row (both centered
via the td's default vertical-align:middle, but the estado tag's real
layout box - margin included - was 16px taller), confirmed live via
getComputedStyle on both tags in the same row. #agenda-tabela is the
real table id (agenda-lista.php), reused as-is by parceiro.php's
compacto Eventos tab. */
#agenda-tabela .gra-tag {
margin-bottom: 0 !important;
}
/* ferramentas.php card title/description: FIXED-size content slots, same
technique and reasoning as .iniciativa-card-title/-text above. A first
attempt here used height:100% on the card itself (stretching every card
in the row to match whichever one is naturally tallest) - wrong
direction per explicit feedback: that grows the SHORT card with blank
space instead of constraining the LONG one. Giving title/description a
fixed height instead (2 lines each: 57.6px title at cssnovo's default
24px/28.8px, 48px description at its 16px/24px) makes every card's
natural content height identical up front, so no card-level stretch is
needed at all - the longer description is what gets truncated/clamped,
never the shorter card padded out. */
.gra-card-informative.card-vertical .details .ferramenta-card-title {
height: 57.6px;
overflow: hidden;
text-overflow: ellipsis;
display: -webkit-box;
-webkit-line-clamp: 2;
-webkit-box-orient: vertical;
}
.gra-card-informative.card-vertical .details .ferramenta-card-text {
height: 48px !important;
max-height: 48px !important;
overflow: hidden !important;
text-overflow: ellipsis;
display: -webkit-box !important;
-webkit-line-clamp: 2 !important;
-webkit-box-orient: vertical !important;
}
/* galeria.php card title: same fixed 2-line slot technique as
.iniciativa-card-title, so a 1-line album title and a 2-line one still
leave every card in the row the same height (no card-level stretch). */
.gra-card-informative.card-vertical .details .galeria-card-title {
height: 57.6px;
overflow: hidden;
text-overflow: ellipsis;
display: -webkit-box;
-webkit-line-clamp: 2;
-webkit-box-orient: vertical;
}
/* agenda.php's table pushes the whole page wider than the viewport:
.contentPageText sizes itself with max-width:fit-content, and even
though .gra-table-wrapper has its own overflow-x:auto, its intrinsic
(max-content) width still counts toward the fit-content calculation
on its ancestor - so the card, and the whole page, stretch to fit
the table's natural width instead of the table scrolling inside a
normally-sized card. Forcing an explicit width stops it contributing
an oversized intrinsic size upward. */
/* cssnovo-style.css sets .gra-table-wrapper's overflow-x:auto alone, with
no overflow-y of its own - per the CSS overflow spec, a non-visible
overflow-x with overflow-y left at its 'visible' default forces
overflow-y to compute as 'auto' too (the two can't be visible/
non-visible on different axes), turning this into an unintended
vertical scroll box wherever page layout gives it less height than its
content needs. Only horizontal scrolling for an over-wide table is
ever wanted here - reasserted explicitly so content is never clipped
vertically (e.g. espaco.php's Salas & Gabinetes table). */
.gra-table-wrapper {
width: 100%;
overflow-y: visible;
}
/* .contentPageText sizes itself with max-width:fit-content - it shrinks
or grows to hug whatever content happens to be inside it. That's
fine (even desired - the legal/text pages read as a narrower centered
column on purpose, via their own inline max-width:900/700px on the
.gra-container inside), EXCEPT on pages whose entire body is a
dynamic grid/table with no long free-text paragraph to dominate the
fit-content calculation - a sparse result (FAQ with no matches for a
category, the one-tool Ferramentas page, a Galeria album with 1-2
photos, a Serviços tag filtered to a single result) then collapses
the whole card to a tiny box floating mid-page instead of staying
the grid's normal width. Scoped to just those pages via
.contentPageText-wide (currently: parceiros, faq, ferramentas,
agenda, galeria, galeria-album, servicos' list view, iniciativas,
espaco - its own Espaços Disponíveis table has the same fit-content
leak, worse now that it flips between a table and a card grid on
?vista= too) -
iniciativas specifically also flips between its own card grid and a
table on ?vista= same as agenda, so without this the whole page's
width visibly jumped every time that toggle was clicked. Do not widen
this to every page, that would blow out the legal pages' intentionally
narrower reading column into a lot of dead padding down one side.
Capped at 1472px (not max-width:none) to match exactly what the
normal fit-content pages settle at on their own (measured live:
.gra-container's own 1360px cap + the card's 2x56px padding) - a
first attempt at width:100%/max-width:none fixed the "collapses too
small" bug but on a wide monitor made these pages stretch edge to
edge with no side gutter, unlike every other page. */
.contentPageText-wide {
max-width: 1472px !important;
width: 100%;
}
/* Sidebar link lists inside a .gra-card-informative (servicos.php's "Outros
Serviços", iniciativa.php's "Outras notícias"): plain rows with a
bottom-border separator, no feedback at all on hover/focus so a visitor
can't tell which row they're about to click. The card's own background is
already blue-100, so a hover of blue-200 (one ramp step, the card's own
:hover shade) reads as barely-there against it - blue-300 is the smallest
jump that's actually visible at this scale, paired with a small slide so
the row change registers even for anyone who can't tell the two blues
apart. */
.gra-sidebar-list-link {
border-radius: 8px;
transition: background-color .15s ease, transform .15s ease;
}
.gra-sidebar-list-link:hover,
.gra-sidebar-list-link:focus-visible {
background-color: var(--color_blue_300);
transform: translateX(4px);
}
.dark-mode .gra-sidebar-list-link:hover,
.dark-mode .gra-sidebar-list-link:focus-visible {
background-color: var(--color_gray_700);
}
/* Footer compliance logos (PRR/GRA/RP/UE/C19): gra-design-system.mjs ships
its OWN dark/light logo-swap for anything classed .gra-logo-gov/-prr/
-c19/-rp/-ue/-incuba - on every page load and theme toggle it force-sets
these images' src to hardcoded paths under /img/logos/(darkmode/)... that
don't exist in this project (this site's real logos live under
assets/images/logo/, a different asset set entirely), silently
overwriting whatever src footer.php had just set and leaving the image
broken. footer.php renames these to footerLogo* instead of matching
the vendor's class names, so its own light/dark pair is left
alone - only .footerLogoGov needs a replacement for the sizing
.gra-logo-gov used to carry (the other four already size correctly via
the generic .gra-logos img/.logosLeft img wrapper rules, untouched by
this rename). */
.footerLogoGov {
max-width: 132px;
width: auto;
margin-right: 12px;
height: 32px;
}
/* ==========================================================================
5. TEMA INCUBA - ACENTO AMARELO DO FRONTOFFICE
5.1 a 5.4: cabeçalhos, ligações, botões, painéis, componentes e polimento.
Todas as regras levam a guarda do Frontoffice; lêem os tokens --brand-*.
========================================================================== */
/* ============================================================
5.1 INCUBA THEME — Frontoffice yellow accent (live default)
============================================================
Approved 2026-08-31 after visual review via incuba-theme-preview.php —
see docs/superpowers/specs/2026-08-31-frontoffice-incuba-yellow-theme-
design.md. The temporary `.incuba-theme` preview gate has been removed;
every rule below now applies to every Frontoffice body by default. Only
exclusion of the two Backoffice body classes remains,
`.templateDetailsBackoffice` / `.bo-login-body` (já sem uso; ver nota no topo) (confirmed exhaustive via
grep across backoffice/** — no third variant exists), so the Backoffice
can never match any rule below.
Role-based remap, not a blue->yellow search/replace: measured live,
text-on-white can only use yellow-900 and still clear WCAG AA (4.5:1) —
every lighter yellow step fails on a white background (yellow-800 is
3.78:1) — so light-mode headings and light-mode secondary/link text
intentionally share that one step. Dark-mode text has real headroom
(multiple steps clear AA on near-black/gray-900), so headings
(yellow-300, softer/lighter for large display text) and interactive
accents (yellow-400 — the closest official step to the #FFD304 brand
reference — for links/buttons/active-state) get their own distinct
steps there. ============================================================ */
/* Headings + secondary/accent text — LIGHT (Incuba Light). `.gra-text-blue-
900` added in the completion pass: sobre.php's timeline star icon and
area-membro.php both use it, and it was missing from this group even
though its dark-mode counterpart already covers it a few rules below -
an oversight in the original rollout, not a deliberate exclusion.
Bumped from yellow_900 to yellow_400 per explicit request: reuse the
exact same step as the Área de Membro nav active state (see navbar.php's
`.userBorderLeft.active .credentials.job` rule) instead of the AA-safe
yellow_900 this group used before. yellow_400 fails WCAG AA on a white
background (measured, see the "Frontoffice yellow accent" header comment
above for the original AA rationale) - the request was made with that
contrast tradeoff acknowledged, so !important here is a deliberate
accessibility regression, not an oversight. */
body:not(.templateDetailsBackoffice):not(.bo-login-body):not(.dark-mode) .gra-text-blue-800,
body:not(.templateDetailsBackoffice):not(.bo-login-body):not(.dark-mode) .gra-text-blue-700,
body:not(.templateDetailsBackoffice):not(.bo-login-body):not(.dark-mode) .gra-text-blue-500,
body:not(.templateDetailsBackoffice):not(.bo-login-body):not(.dark-mode) .gra-text-blue-600,
body:not(.templateDetailsBackoffice):not(.bo-login-body):not(.dark-mode) .gra-text-blue-900 {
color: var(--brand-accent) !important;
}
/* Headings + secondary/accent text — DARK (Incuba Dark, default). blue-500/
600/900 were already on yellow_400; blue-800/700 bumped up from yellow_300
to match, same "reuse Área de Membro active state's exact step" request
as the LIGHT block above - one shared step for the whole group now
instead of two. */
body:not(.templateDetailsBackoffice):not(.bo-login-body).dark-mode .gra-text-blue-800,
body:not(.templateDetailsBackoffice):not(.bo-login-body).dark-mode .gra-text-blue-700,
body:not(.templateDetailsBackoffice):not(.bo-login-body).dark-mode .gra-text-blue-500,
body:not(.templateDetailsBackoffice):not(.bo-login-body).dark-mode .gra-text-blue-600,
body:not(.templateDetailsBackoffice):not(.bo-login-body).dark-mode .gra-text-blue-900 {
color: var(--brand-accent) !important;
}
/* Links — LIGHT. `.pageContent p a` (admin rich-text content links - FAQ
answers, legal pages, iniciativa/evento bodies) added in the completion
pass: the DARK-mode pair for this selector already existed below
(`.pageContent p a{color:yellow_400}` under Links — DARK), but light
mode was never given the equivalent fix - only the classed `.gra-link`
was, leaving these bare content links on blue_800 in light mode
(live-verified on faq.php's accordion answers). */
body:not(.templateDetailsBackoffice):not(.bo-login-body):not(.dark-mode) .gra-link,
body:not(.templateDetailsBackoffice):not(.bo-login-body):not(.dark-mode) .pageContent p a {
color: var(--brand-text-on-light) !important;
}
body:not(.templateDetailsBackoffice):not(.bo-login-body):not(.dark-mode) .gra-link:hover,
body:not(.templateDetailsBackoffice):not(.bo-login-body):not(.dark-mode) .gra-link:focus-visible {
color: var(--brand-text-on-light) !important;
text-decoration: underline;
}
/* Links — DARK */
body:not(.templateDetailsBackoffice):not(.bo-login-body).dark-mode .gra-link,
body:not(.templateDetailsBackoffice):not(.bo-login-body).dark-mode .pageContent p a {
color: var(--brand-accent) !important;
}
body:not(.templateDetailsBackoffice):not(.bo-login-body).dark-mode .gra-link:hover,
body:not(.templateDetailsBackoffice):not(.bo-login-body).dark-mode .gra-link:focus-visible {
color: var(--brand-accent-soft) !important;
text-decoration: underline;
}
/* Chrome exceptions: the footer strip and the navbar both have their own
fixed text color regardless of theme (footer stays black-on-neutral in
dark mode — untouched here on purpose, see below; navbar stays legible
against its own chrome background — see below). The general .gra-link
rules above have a longer selector chain than cssnovo-style.css's own
footer/navbar link rules, so without re-asserting these under the same
Incuba guard, the general rule would win and repaint them the wrong
color. Re-declared in both modes for symmetry/safety even though only
the dark-mode pair is known today to need it (mirrors this file's own
pre-existing .dark-mode .gra-footer-opt-2 .gra-link / .dark-mode
.header-primary .gra-link exceptions above — same pattern, Backoffice-
excluded). */
body:not(.templateDetailsBackoffice):not(.bo-login-body):not(.dark-mode) .gra-footer-opt-2 .gra-link {
color: var(--brand-on-chrome) !important;
}
body:not(.templateDetailsBackoffice):not(.bo-login-body).dark-mode .gra-footer-opt-2 .gra-link {
color: var(--brand-on-chrome-light) !important;
}
body:not(.templateDetailsBackoffice):not(.bo-login-body):not(.dark-mode) .gra-desktop-header.header-primary .gra-link {
color: var(--brand-on-chrome) !important;
}
body:not(.templateDetailsBackoffice):not(.bo-login-body).dark-mode .gra-desktop-header.header-primary .gra-link {
color: var(--brand-on-chrome) !important;
}
/* Primary button — LIGHT. Contrast (#000 text): yellow-400 14.79:1,
yellow-500 ~11:1, yellow-600 9.92:1 — all clear AA (4.5:1) by a wide
margin. */
body:not(.templateDetailsBackoffice):not(.bo-login-body):not(.dark-mode) .gra-btn.btn-primary {
background-color: var(--brand-accent) !important;
border-color: var(--brand-accent) !important;
color: var(--brand-on-accent) !important;
}
body:not(.templateDetailsBackoffice):not(.bo-login-body):not(.dark-mode) .gra-btn.btn-primary:hover {
background-color: var(--brand-accent-hover) !important;
border-color: var(--brand-accent-hover) !important;
color: var(--brand-on-accent) !important;
}
body:not(.templateDetailsBackoffice):not(.bo-login-body):not(.dark-mode) .gra-btn.btn-primary:active {
background-color: var(--brand-accent-active) !important;
border-color: var(--brand-accent-active) !important;
color: var(--brand-on-accent) !important;
}
/* Primary button — DARK. cssnovo-style.css's own non-theme-marca-servicos
dark-mode variant is gray_200 base / gray_400 hover / blue_300 active —
none of it is the Incuba accent, so every state is remapped here, not
just the one existing blue hit. */
body:not(.templateDetailsBackoffice):not(.bo-login-body).dark-mode .gra-btn.btn-primary {
background-color: var(--brand-accent) !important;
border-color: var(--brand-accent) !important;
color: var(--brand-on-accent) !important;
}
body:not(.templateDetailsBackoffice):not(.bo-login-body).dark-mode .gra-btn.btn-primary:hover {
background-color: var(--brand-accent-hover) !important;
border-color: var(--brand-accent-hover) !important;
color: var(--brand-on-accent) !important;
}
body:not(.templateDetailsBackoffice):not(.bo-login-body).dark-mode .gra-btn.btn-primary:active {
background-color: var(--brand-accent-active) !important;
border-color: var(--brand-accent-active) !important;
color: var(--brand-on-accent) !important;
}
/* Form input focus ring — cssnovo-style.css hardcodes this to raw Bootstrap
blue (#86b7fe / #0d6efd40), not a DS token, so it needs its own override.
rgba(255,212,81,.25) is yellow-400 (#FFD451) with alpha appended the same
way the vendor rule appends alpha to its own blue — same technique,
Incuba's token instead, not a new color. */
body:not(.templateDetailsBackoffice):not(.bo-login-body) .form-control:focus {
border-color: var(--brand-accent) !important;
box-shadow: 0 0 0 .25rem var(--brand-accent-focus) !important;
}
/* Agenda "De"/"Até" date filter icon — .gra-daterangepicker-container::before
(the calendar glyph) renders in DS blue (blue_800 light / blue_300 dark,
per gra-design-system-master's datePicker.scss) — needs the same yellow
accent as the rest of this page's inputs, not the DS default. */
body:not(.templateDetailsBackoffice):not(.bo-login-body) .gra-daterangepicker-container:before {
color: var(--brand-accent) !important;
}
/* Agenda "De"/"Até" date filter input — hover/open state. The sitewide
.form-control:focus rule right above gives every other text input a
yellow border + glow box-shadow, but the page's own Select2 dropdowns
(.select2 .select2-selection:hover / .select2-container--open above)
use a plain border-color swap with NO glow — this input needs to match
THAT pattern (it sits right next to those dropdowns in the same filter
row), not the glow. Also overrides the vendor's own JS-set `.focus`
class (assets/js/gra-design-system.mjs's `show.daterangepicker` handler
adds it to daterangepickerInput on open, separately from :focus, with
border-color:blue_500/300 from gra-design-system-master's datePicker.scss)
which the box-shadow rule's selector never touched anyway. Same
yellow_400 token in both themes, same as the Select2 rules above. */
body:not(.templateDetailsBackoffice):not(.bo-login-body) .daterangepickerInput:hover,
body:not(.templateDetailsBackoffice):not(.bo-login-body) .daterangepickerInput.focus,
body:not(.templateDetailsBackoffice):not(.bo-login-body) .daterangepickerInput:focus {
border-color: var(--brand-accent) !important;
box-shadow: none !important;
}
/* Light decorative tint backgrounds — LIGHT mode only. Dark mode's existing
.dark-mode .gra-background-blue-100 { background-color: var(--color_gray_900) }
rule (earlier in this file) is deliberately left alone — it's already a
neutral structural treatment, not a blue accent, so there's nothing to
remap there. The explicit :not(.dark-mode) below guarantees these two
rules can never apply in dark mode even though this guard chain is more
specific than that existing dark-mode rule. */
body:not(.templateDetailsBackoffice):not(.bo-login-body):not(.dark-mode) .gra-background-blue-100 {
background-color: var(--brand-tint-1) !important;
}
body:not(.templateDetailsBackoffice):not(.bo-login-body):not(.dark-mode) .gra-background-blue-200 {
background-color: var(--brand-tint-2) !important;
}
/* Navbar chrome — approved 2026-08-31: background moves from blue (blue_800
light / blue_900 dark) to a neutral dark, since the navbar is structural
chrome, not the accent itself. The active nav-item's color/text-shadow
trick (see this file's own comment above on why the text-shadow half
exists) moves from plain white to the yellow-400 accent — measured
7.08:1 on gray_800, comfortably clears AA.
Anchor-targeting fix: the rule below originally set `color` only on
`li.menu-first-level.active` itself. That never painted the visible
label, because cssnovo-style.css's own real rule for this exact label,
".header-primary .menus_desktop ul.menu li.menu-first-level:not(.gra-
flex-row) a{color:#fff}", sets `color` directly on the the text
actually lives in - an element's own explicit color always wins over
whatever its ancestor resolves to, !important or not, since inheritance
only ever fills in a property no rule set directly on that element.
Confirmed live: the