/* Ghost/plain button system overrides, Lexxy rich-content editor styling, heading permalinks.
   Split out of theme.css (original lines 2034-2396) — 2026-08-18,
   CSS @layer restructuring step 2 (Basecamp "Fra Fizzy-gjennomgang:
   CSS-arkitektur"). Numeric filename prefix controls load order (see
   app/helpers/application_helper.rb#theme_stylesheet_link_tag) —
   files are concatenated in this exact original order, so no cascade
   tie-break changes. */
@layer overrides {
/* This look — no border, no fill at rest, a soft grey hover fill, rounded
   rectangle rather than a pill — started 2026-08-08 as a toolbar-only
   "ghost" exception alongside .ui-button's own pill default. Torleiv
   corrected that same day: it's now .ui-button's ONE default appearance,
   used everywhere including primary actions/form submission (Lagre,
   Bekreft, Opprett), not just toolbar context — see the .ui-button
   override below. `class: "ghost"` stays as a standalone utility for
   hand-written <button>/<a> elements that never had .ui-button applied
   in the first place (bare markup, no ui_button/ui_link_button helper).
   .document-page-header__action/.page-title-header__action (Endre,
   Avbryt, Lagre, the …-trigger) are this same look under their existing
   names, so every current caller gets it for free either way. */
.ghost,
.document-page-header__action,
.page-title-header__action {
    display: inline-flex;
    align-items: center;
    justify-content: center;
    background: none;
    border: none;
    color: color-mix(in srgb, var(--text-900) 65%, transparent);
    font: inherit;
    /* .ui-button's own base styling (when .ghost is combined with it, e.g.
       via ui_button icon_name: ..., class: "ghost") sets letter-spacing:1px
       for its pill look — `font: inherit` above doesn't touch that, it's
       a separate property, so it needs its own explicit reset. */
    letter-spacing: normal;
    text-decoration: none;
    cursor: pointer;
    /* Fixed height (rather than relying on padding + content) so all of
       these hover-highlight at exactly the same height regardless of their
       different content. Width stays snug to the content plus this
       padding — nothing stretches it. */
    height: 2.75rem;
    padding: 0 var(--space-4);
    border-radius: var(--radius-md);
    transition: background 0.15s ease;
}

/* .ghost's own height/font above (font:inherit — the shorthand, so it
   resets font-size too, not just family/weight) are unlayered, which by
   CSS layer rules always beats sand_ui's OWN, layered .size-sm rule
   (buttons.css/sizes.css, both under @layer components) — REGARDLESS OF
   SELECTOR SPECIFICITY, since layer priority is checked before
   specificity at all. A button combining .ghost with .size-sm (Lagre/
   Avbryt pairs on Control/Risk/Deviation/Document's edit-in-place forms,
   the version-history "Godkjenn" button) silently ignored size-sm
   entirely — rendering at .ghost's own 44px/inherited-font-size instead
   of size-sm's real 28px/11px, next to a SEPARATE button (Lagre, no
   .ghost) that WAS getting size-sm correctly, since nothing unlayered
   competed with it. Reported: Lagre/Avbryt visibly different heights on
   the document metadata form (Torleiv, 2026-08-10) — this is systemic,
   not specific to that one pair. Explicit override restores the real
   sand_ui size-sm values for this exact combination: var(--height-sm)/
   var(--bt-spacing) are sand_ui's own tokens (still cascading normally —
   only the PROPERTIES .ghost sets unlayered are immune to sand_ui's
   layer, not custom properties sand_ui itself already assigned onto
   the element), font-size is sand_ui's own hardcoded size-sm value
   (sizes.css has no reusable var for it, so hardcoded here for a
   provable match, not because there is a "magic number"). */
/* 16.09.2026 (#10309537047, Torleiv: «ikke røde lenker...!»): the danger
   rule below was inserted between this selector and its own declarations
   on 15.09, which joined the two into one selector list. The size fix
   here was replaced by `color: var(--danger-color)`, so EVERY small ghost
   button in the app turned red — «Ny mappe», «Last opp fil», «Lagre og
   send til godkjenning» — and none of them got their 28px size either.
   Two separate rules again, and the size-sm declarations restored. */
.ghost.size-sm {
    height: var(--height-sm, 1.75rem);
    padding: 0 var(--bt-spacing, 9px);
    font-size: 11px;
}

/* 15.09.2026 (UX review, #10306663962): the draft header's Forkast /
   Avbryt / Lagre / Godkjenn og publiser all wore the same ghost look.
   Two modifiers carry the consequence without a pill: danger for the
   destructive one, emphasis for the one that publishes to every reader.
   Hover keeps the shared grey box; only the ink differs. */
.document-page-header__action--danger {
    color: var(--danger-color);
}

.document-page-header__action--emphasis {
    color: var(--signal-color);
    font-weight: 600;
}

.document-page-header__action.size-sm,
.page-title-header__action.size-sm {
    height: var(--height-sm, 1.75rem);
    padding: 0 var(--bt-spacing, 9px);
    font-size: 11px;
}

/* #10281061392 (mobilgjennomgang runde 2, Torleiv: «kjør ferdig»). En
   size-sm-knapp er 28px høy — den størrelsen desktop-layouten er bygget
   rundt, og som ikke skal endres. På en berøringsskjerm er det godt under
   de ~44px både Apple og Google anbefaler, så TRYKKFLATEN vokser mens
   knappen tegnes likt: et usynlig ::after med negative innsett, samme
   teknikk .people-role-menu__trigger allerede bruker.

   ±8px loddrett gir 44px totalt. Vannrett bare ±3px, med vilje: disse
   knappene står ofte parvis (Avbryt/Godkjenn i dialogene, handlingsrader
   i lister), og korteste avstand mellom dem er --space-2 = 8px — en
   bredere flate ville begynt å stjele trykk fra naboen, som er verre enn
   en litt liten knapp. Bare der ingenting kan hovere: en smal
   nettleservindu på desktop har mus og trenger ikke dette. */
@media (hover: none) and (pointer: coarse) {
    .ui-button.size-sm {
        position: relative;
    }

    .ui-button.size-sm::after {
        content: "";
        position: absolute;
        inset: -8px -3px;
    }
}

.ghost:hover,
.document-page-header__action:hover,
.page-title-header__action:hover {
    background: color-mix(in srgb, var(--text-900) 8%, transparent);
}

/* Basecamp #10273056977 (dark mode): see .my-tasks-panel__toggle:hover's
   own comment (03_workspace_dashboard_and_sidefelt.css) — same
   --signal-color-flips-to-Bein issue, same var(--solid-text-color) fix. */
.ghost.solid {
    background: var(--signal-color);
    color: var(--solid-text-color);
}

.ghost.solid:hover {
    background: var(--signal-dark);
}

/* Torleiv, 2026-08-08: supersedes the "two deliberate variants" plan above
   — sand_ui's own pill/bordered/filled .ui-button default is replaced
   app-wide with the ghost look (rounded rectangle, no border, no fill at
   rest, soft grey hover). .solid keeps its filled color for the
   primary/CTA variant, just no longer a pill either. --radius-pill stays
   in use elsewhere (badges, person-mentions) — just not on buttons.
   Unlayered, so — like the .ui-input override above — this wins over
   sand_ui's own @layer components rule regardless of source order. */
.ui-button {
    border: none;
    border-radius: var(--radius-md);
    background-color: transparent;
    color: color-mix(in srgb, var(--text-900) 65%, transparent);
}

.ui-button:hover {
    background-color: color-mix(in srgb, var(--text-900) 8%, transparent);
}

/* Re-asserted rather than left to sand_ui's own .solid rule: the base
   override above would otherwise win (unlayered beats layered) and flatten
   every filled button back to transparent/grey text. --bt-background and
   --text-color are still whatever sand_ui's .solid/.ui-NNN modifiers set,
   so the actual fill/text colors are untouched — only the shape changes. */
.ui-button.solid {
    border-radius: var(--radius-md);
    background-color: var(--bt-background);
    color: var(--text-color);
}

.ui-button.solid:hover {
    filter: brightness(0.92);
}

/* The ONE emphasized action on a screen — Lagre/Opprett/Bekreft when it's
   the actual thing the user came to do, as opposed to a merely-solid
   neighbor (e.g. a muted .ui-50/.ui-100 toolbar button) sitting next to
   it. Same --signal-color/--signal-dark already used for links/accents
   elsewhere and for hand-written .ghost.solid buttons (e.g.
   shared/_confirm_dialog.html.erb's "Bekreft") — one accent color, not
   two, even though the selector paths differ (ui_button-helper output vs
   raw <button> markup that never gets a .ui-button class). Not the same
   as bare .solid (--ui-800 charcoal, see above) — apply this explicitly,
   don't assume every .solid is automatically the preferred one. */
/* Basecamp #10273056977 (dark mode): same --signal-color/var(--solid-text-color)
   fix as .ghost.solid above. */
.ui-button.solid.preferred {
    background-color: var(--signal-color);
    color: var(--solid-text-color);
}

.ui-button.solid.preferred:hover {
    background-color: var(--signal-dark);
    filter: none;
}

/* .circle (sand_ui) only sets aspect-ratio, relying on .ui-button's own
   pill radius to render round — now that the base default above is a
   rounded rectangle, every icon-only round button in the app (search,
   close-X, avatar-adjacent triggers, dropdown triggers) needs this
   explicit full-round radius or it renders as a rounded square instead. */
.ui-button.circle {
    border-radius: 50%;
}

/* .ui-button-group (sand_ui) merges adjacent buttons into one bordered
   pill — square inner corners plus a -1px margin to collapse the shared
   border. Now that .ui-button has no border by default, that illusion is
   invisible at rest but leaves a stray square-corner/overlap artifact on
   hover. Torleiv: drop the merged-segment look entirely — plain ghost
   buttons with normal spacing reads better now that pills are gone
   everywhere else too (agenda_items/show.html.erb's case pager,
   documents/index.html.erb's arrows and grid/list toggle). */
.ui-button-group {
    gap: var(--space-1);
}

.ui-button-group > * {
    border-radius: var(--radius-md);
}

.ui-button-group .ui-button + .ui-button {
    margin-left: 0;
}

/* Endre/Avbryt/Lagre/the …-trigger keep their tighter horizontal padding —
   .ghost's own default (--space-4) suits a single word with room to
   breathe, these sit closer together in a row. */
.document-page-header__action,
.page-title-header__action {
    padding: 0 var(--space-2);
}

/* The "…" overflow menu (Historikk/Slett) — Basecamp-style: Endre stays
   inline, everything else tucks behind this, reusing the header avatar's
   own dropdown component/behavior (.header-user-menu, header-menu
   controller) with different labels. Plain bullet characters instead of
   the "…" character — that glyph sits on the text baseline like
   punctuation dots, noticeably lower than a vertically-centered
   kebab/ellipsis should sit. Repeats the padding here (both classes, to
   outrank .header-user-menu__trigger's own padding: 0 later in this file)
   so it always matches Endre's. */
.document-page-header__menu-trigger.document-page-header__action {
    padding: 0 var(--space-2);
}

/* Kept raw, not a --text-size-* token: this sizes a glyph ("•••"), not
   body/UI text — same reasoning as .workspace-hero__link-arrow and
   .workspace-shortcut__arrow's own 1.1rem below. */
.document-page-header__menu-dots {
    font-size: 1.1rem;
    font-weight: 700;
    letter-spacing: -0.05em;
    color: color-mix(in srgb, var(--text-900) 70%, transparent);
}

.document-page-header__menu-panel {
    text-align: left;
    font-size: var(--text-size-base);
}

/* Inside the sheet, the document's own rich-content editor shouldn't repeat
   the sheet's white background or padding — the sheet already provides it.
   Company's own rich-text sections (.company-section) get the
   same treatment — they sit inside a .ui-box, not a .document-sheet, but
   want the identical editor typography, not a smaller one-off scale. */
.document-sheet .ui-document-rich-content-editor,
.company-section .ui-document-rich-content-editor {
    border: none;
    padding: 0;
}

/* A wide table (e.g. IS-SOA-01's 93-row Annex A statement-of-applicability
   table, imported tonight from Basecamp) is wider than the 900px document
   column — table { display: block } turns the table element itself into
   its own horizontal-scroll container, so it scrolls in place instead of
   spilling past the edge of the document-sheet card onto the page
   background underneath. No wrapper div needed, so this works on already-
   stored content without a migration. */
.ui-document-rich-content table,
.ui-document-rich-content-editor lexxy-editor table {
    display: block;
    max-width: 100%;
    overflow-x: auto;
}

/* Hover-revealed show/hide toggle for an attachment's caption (see
   lexxy_caption_visibility_extension.js) — hidden until the attachment is
   hovered, then a plain icon button in the corner. data-caption-hidden is
   set by that extension and, since it's just an HTML attribute, hides the
   caption identically here in the editor and in the read-only
   ui-document-rich-content view below. */
.ui-document-rich-content-editor lexxy-editor .attachment,
.ui-document-rich-content .attachment {
    position: relative;
}

.lexxy-caption-toggle {
    position: absolute;
    top: 0.3ch;
    right: 0.3ch;
    display: flex;
    align-items: center;
    justify-content: center;
    width: 1.8rem;
    height: 1.8rem;
    padding: 0;
    background: rgba(255, 255, 255, 0.85);
    border: 1px solid color-mix(in srgb, var(--text-900) 12%, transparent);
    border-radius: 50%;
    color: color-mix(in srgb, var(--text-900) 60%, transparent);
    cursor: pointer;
    opacity: 0;
    transition: opacity 0.15s ease;
}

.attachment:hover .lexxy-caption-toggle,
.lexxy-caption-toggle:focus-visible {
    opacity: 1;
}

[data-caption-hidden] > figcaption,
[data-caption-hidden] .attachment__caption {
    display: none;
}

/* Basecamp-style typography for headings written inside the body text —
   bold sans, matching the page title, instead of the app's serif accent. */
.document-sheet .ui-document-rich-content h1,
.document-sheet .ui-document-rich-content h2,
.document-sheet .ui-document-rich-content h3,
.document-sheet .ui-document-rich-content-editor lexxy-editor h1,
.document-sheet .ui-document-rich-content-editor lexxy-editor h2,
.document-sheet .ui-document-rich-content-editor lexxy-editor h3,
.company-section .ui-document-rich-content h1,
.company-section .ui-document-rich-content h2,
.company-section .ui-document-rich-content h3,
.company-section .ui-document-rich-content-editor lexxy-editor h1,
.company-section .ui-document-rich-content-editor lexxy-editor h2,
.company-section .ui-document-rich-content-editor lexxy-editor h3 {
    font-family: var(--font-sans);
    font-weight: 800;
    letter-spacing: -0.01em;
    font-style: normal;
    /* A #heading-N link (TOC sub-items, document.rb#headings, the nav gear's
       heading list) would otherwise land the heading flush against the top
       of the viewport, hidden behind the sticky .page-header AND, now,
       the also-sticky .document-page-header right below it — clear both
       real (measured, not guessed) heights, see sticky_offset_controller.js. */
    scroll-margin-top: calc(var(--page-header-height, 60px) + var(--document-header-height, 0px) + var(--space-4));
    position: relative;
}

/* Copy-a-direct-link button appended inside each heading (see
   Document#body_with_heading_anchors) — hover-only, same convention as
   .system-settings__trigger, so headings don't clutter the page at rest.
   font-size below (and on .heading-permalink--copied::after further down)
   is deliberately `em`, not a --text-size-* token: it needs to scale with
   whichever heading it's attached to (h1 vs h2 vs h3), not sit at one
   fixed size regardless of context. */
.heading-permalink {
    position: relative;
    display: inline-flex;
    align-items: center;
    justify-content: center;
    margin-left: var(--space-2);
    padding: 0.15em;
    background: none;
    border: none;
    color: color-mix(in srgb, var(--text-900) 35%, transparent);
    font-size: 0.7em;
    vertical-align: middle;
    cursor: pointer;
    opacity: 0;
    transition: opacity 0.15s ease;
}

.document-sheet .ui-document-rich-content h1:hover .heading-permalink,
.document-sheet .ui-document-rich-content h2:hover .heading-permalink,
.document-sheet .ui-document-rich-content h3:hover .heading-permalink,
.company-section .ui-document-rich-content h1:hover .heading-permalink,
.company-section .ui-document-rich-content h2:hover .heading-permalink,
.company-section .ui-document-rich-content h3:hover .heading-permalink,
.heading-permalink:focus-visible {
    opacity: 1;
}

.heading-permalink--copied {
    opacity: 1;
    color: var(--success-color);
}

.heading-permalink--copied::after {
    content: "Lenke kopiert";
    position: absolute;
    top: -1.8em;
    left: 50%;
    transform: translateX(-50%);
    padding: 0.2em 0.6em;
    border-radius: var(--radius-md);
    background: rgba(28, 25, 20, 0.85);
    color: #fff;
    font-size: 0.55em;
    font-weight: 600;
    letter-spacing: normal;
    white-space: nowrap;
}

/* Basecamp #10270911501 ("Fiks at mention-velger forsvinner bak tekst"):
   the @/# prompt picker (lexxy's own .lexxy-prompt-menu, rendered by
   lexxy.js as a DIRECT CHILD OF <lexxy-editor> itself — confirmed live
   via DOM inspection, NOT nested inside .lexxy-editor__content) already
   carries a very high z-index from the gem's own lexxy.css
   (var(--lexxy-z-popup): 1000, comfortably above every z-index this app
   itself uses, max 200 on the auth dialogs) — so in a browser that
   already treats <lexxy-editor>'s bare `position: relative` (lexxy.css,
   no z-index of its own) as establishing its own stacking context, the
   picker already paints on top of this editor's own text with no
   override needed here (confirmed via a Capybara/headless-Chrome system
   test, including a forced worst case: the picker's own rect physically
   overlapping .document-page-header's sticky area). But
   position:relative with z-index left at its default `auto` does NOT
   unambiguously create a stacking context per spec — the exact same
   "doesn't reliably scope a positioned child above it in every engine"
   gap already hit and fixed for .document-toc-sidebar above (see that
   rule's own comment) applies here too, just one level deeper.

   The FIRST fix for that was `z-index: var(--lexxy-z-popup, 1000)`, and
   its own reasoning contained the bug: 1000 is "comfortably above every
   z-index this app itself uses". Being above everything is exactly what
   broke — it also put the editor above the app's own sticky
   .page-header (z-index 120, no stacking context in between), so an
   open editor's text scrolled OVER the top bar instead of under it
   (Basecamp #10290032728, Torleiv 10.09.2026: "Når edit-mode legger
   tekst seg over header"). Measured in the browser: elementFromPoint
   inside the header band returned .lexxy-editor__content, not the
   header.

   `isolation: isolate` is the right tool and always was — it creates a
   stacking context unambiguously, per spec, WITHOUT entering the
   z-index ordering at all. The prompt menu's own 1000 is then scoped
   inside this editor (still painting above the editor's own text, which
   was the whole point of #10270911501), while the editor itself keeps
   its natural stacking position below the app chrome. Same probe after
   the change returns .page-header-grid. */
lexxy-editor {
    isolation: isolate;
}


} /* @layer overrides */

/* UTENFOR @layer, med vilje. Lexxys egen regel er ulagdelt, og ulagdelt
   CSS vinner over ALT lagdelt uansett spesifisitet — en kopi av dette
   inne i @layer overrides ble målt til rgba(0, 0, 0, 0) i nettleseren
   selv om selektoren var sterkere enn lexxys :where(). Samme felle som
   lexxy-toolbar-regelen rett over måtte ut av laget for. */
/* Torleiv, 21.09.2026 («mentions-krøll i leverandør-register», skjermbilde
   av hendelsesvarslingsrutinen på Basecamp-leverandøren): @-lista sto uten
   bakgrunn, så brødteksten under skinte rett gjennom navnene og de to
   blandet seg til uleselig grøt. Bare det markerte elementet var synlig,
   fordi det har sin egen bakgrunn.

   Årsaken er én variabel brukt til to formål. Lexxy tegner både editorens
   eget lerret og prompt-menyens bakgrunn med --lexxy-color-canvas, og
   .ui-document-rich-content-editor setter den til transparent
   (sand_ui/components/document.css) — med rette, for editoren SKAL smelte
   inn i siden. Men menyen rendres som direkte barn av <lexxy-editor> og
   arver da den samme transparenten, der den trenger det motsatte.

   Løsningen er å gi menyen sin egen bakgrunn i stedet for å røre
   variabelen: å sette --lexxy-color-canvas tilbake ville gitt editoren en
   hvit boks midt i dokumentet igjen. --card-bg følger temaet og er
   ugjennomsiktig i både lys og mørk modus.

   Spesifisitet er IKKE det som avgjør her, selv om lexxys regler ligger i
   :where() med spesifisitet 0. Lagrekkefølgen kommer først: ulagdelt slår
   lagdelt uansett hvor sterk selektoren er. Derfor står regelen utenfor
   @layer, ikke fordi klasseselektoren er sterk nok. */
.lexxy-prompt-menu {
    background-color: var(--card-bg);
}

/* Torleiv, 09.10.2026, med skjermbilde av IS-POL-02: «fargevelger må
   vises over andre elementer». Fargepaletten i verktøylinja sto uten
   bakgrunn, så brødteksten under skinte rett gjennom rutene.

   NØYAKTIG SAMME FEIL SOM @-LISTA OVER, ett år etter i samme fil: lexxy
   maler panelet med --lexxy-color-canvas, og
   .ui-document-rich-content-editor setter den til transparent fordi
   editoren skal smelte inn i arket. Panelet arver transparenten der det
   trenger det motsatte.

   Det er ikke et stablingsproblem, selv om det ser slik ut. Panelet har
   z-index: 3 fra lexxy og ligger foran teksten — det er bare
   gjennomsiktig. En z-index til ville ikke flyttet et eneste piksel.

   Gjelder alle nedtrekkene i verktøylinja, ikke bare farger:
   skriftstørrelse og «mer» deler attributtet.

   SELEKTOREN MÅ MATCHE LEXXYS EGEN, ikke bare stå utenfor @layer. Jeg
   skrev først et bart [data-dropdown-panel] her, etter mønsteret fra
   .lexxy-prompt-menu over — og målte at det ikke flyttet et eneste
   piksel: panelet sto fortsatt på rgba(0, 0, 0, 0). Lexxys regel er
   nestet under .lexxy-editor__toolbar-dropdown og er dermed mer
   spesifikk, og begge er ulagdelte, så her avgjør spesifisiteten.
   Lagrekkefølgen er bare det FØRSTE som avgjør; når to regler ligger i
   samme lag, er vi tilbake til vanlig spesifisitet. */
.lexxy-editor__toolbar-dropdown [data-dropdown-panel] {
    background-color: var(--card-bg);
}


/* Basecamp #10270931364 ("Editor-menyen må vise hele tiden når en
   skroller i dokumentet"): deliberately OUTSIDE any @layer, same reason
   as .person-mention in application.css. lexxy.css ships its own
   `:where(lexxy-toolbar) { position: relative; ... }`, and that file has
   no @layer of its own anywhere — an unlayered rule beats EVERY layered
   one regardless of specificity or source order, so a `position: sticky`
   written inside theme's own `@layer overrides` (as everything
   else in this file is) silently lost to lexxy's `position: relative`
   here — confirmed live via a system test: still `position: relative`
   in getComputedStyle after adding the layered version, tried first.
   Matching lexxy's rule as unlayered here is the only way to actually
   outrank it (see the .person-mention comment for the same fight over
   `a { color }` instead of `position`).

   What this fixes: lexxy's own lexxy.css never makes <lexxy-toolbar>
   sticky at all — it just scrolls away with the document body like any
   other in-flow content, confirmed live (a system test scrolled the
   window and watched the toolbar's own getBoundingClientRect().top go
   from +289px to -510px with no fix in place). Same sticky-below-the-
   app's-own-chrome pattern .document-page-header already established
   (theme/04_document_layout_and_sheet.css): --page-header-height
   (the app's own top bar) and --document-header-height
   (.document-page-header itself, 0px wherever that header doesn't
   exist — e.g. the comment/task/meeting/supplier Lexxy editors
   elsewhere in the app — see sticky_offset_controller.js/
   document_header_height_controller.js for how both are measured, not
   guessed) stack so the toolbar sits right below both instead of
   overlapping either. Unscoped to the bare <lexxy-toolbar> element —
   same reasoning as the button-size rule in
   06_document_history_and_toc.css ("the sizing/overflow problem it
   fixes has nothing to do with being inside a document specifically"):
   every Lexxy toolbar in the app should stay visible while its own
   surrounding content scrolls, not just the main document editor's.
   z-index only needs to clear this editor's own scrolling text
   (z-index: auto) — kept low relative to the mention picker's own 1000
   (var(--lexxy-z-popup), see the <lexxy-editor> rule inside
   @layer overrides above) so an open prompt menu still paints over the
   toolbar, not under it, on the rare frame where they'd otherwise
   overlap. background-color is necessary, not decorative: lexxy.css
   never gives <lexxy-toolbar> an opaque background of its own (only
   <lexxy-editor>, its parent, has one), so without this, scrolled text
   visibly showed through the "stuck" toolbar. */
/* AVGRENSET 30.09.2026 (#10355848778). Torleiv, med skjermbilde av
   kommentarfeltet: «fiks merkelig utseende på kommentar-editor» —
   verktøylinja lå midt i feltet, med tomt skrivefelt over og under.

   Regelen sto uten avgrensning, og begrunnelsen over sier hvorfor: hver
   Lexxy-verktøylinje i appen skulle holde seg synlig mens innholdet
   rundt den ruller. Det stemmer for et langt felt. Det stemmer ikke for
   et kort.

   Målt på kommentarfeltet før endringen: editoren er 203 px høy,
   skrivefeltet begynner 35 px ned, og verktøylinja ble malt 106 px ned i
   boksen — sticky hadde løsnet den fra toppen og lagt den oppå teksten.
   Og den vant ingenting på det: hele boksen er synlig uansett, så det
   finnes ikke noe å holde seg synlig FOR.

   De tre som står igjen er de lange: dokumentarket, selskapsseksjonen og
   leverandørens egenvurdering. Kommentarfeltet, oppgavetekst og
   leverandørens kompakte felt får linja der den hører hjemme — øverst,
   i vanlig flyt. Fortsatt utenfor @layer, av samme grunn som før:
   lexxy.css er ulaget og slår enhver laget regel.

   comment_editor_layout_test måler begge sidene — at kommentarfeltets
   linje ligger øverst, og at dokumentets fortsatt er sticky. */
.document-sheet lexxy-toolbar,
.company-section lexxy-toolbar,
.supplier-assessment-editor lexxy-toolbar {
    position: sticky;
    top: calc(var(--page-header-height, 60px) + var(--document-header-height, 0px));
    z-index: 2;
    background-color: var(--card-bg);
}

/* De korte editorene beholder flaten og lagdelingen — bare uten sticky.
   Uten bakgrunnen ville tekst som ruller under linja skinne gjennom, og
   det var den regelen over alt løste. */
lexxy-toolbar {
    z-index: 2;
    background-color: var(--card-bg);
}

/* Torleiv, 16.09.2026 (#10309415397, oppfølging): «vis godkjenn som grønn
   knapp (vis knappen alltid, ikke bare hover)».

   Godkjenn-knappen i versjonshistorikken var en ghost: ingen flate, ingen
   ramme i hvile. Den så ut som en lenke helt til pekeren traff den, og da
   fikk den en grå flate. Det er riktig for Avbryt og Se detaljer — ikke
   for handlingen raden faktisk handler om.

   Grønn, ikke Blekk: dette er den ene bekreftende handlingen på sida, og
   den skal skille seg fra Lagre ved siden av. Den sto rød en periode, og
   det var en ren feil — en danger-regel som svelget naboselektoren sin
   (#10309537047). Grønn er ikke en overkorrigering av den feilen, det er
   fargen en godkjenning skal ha.

   --solid-text-color, ikke hvit: samme grunn som .ghost.solid sin egen
   kommentar over — den følger temaet, en hardkodet hvit gjør ikke det. */
/* Beholder .ghost i klasselista, så geometrien (høyde, padding, radius,
   skriftstørrelse) er nøyaktig den samme som hver annen knapp i appen —
   her overstyres bare flaten og teksten. Å droppe .ghost ville gitt
   sand_ui sin egen pilleform tilbake på denne ene knappen. */
/* GODKJENN ER LYS GRØNN (Torleiv 16.10.2026: «godkjenn-knapp: lys og
   vårlig grønnfarge»).

   EGNE TOKENS OG IKKE --success-color, som den brukte før. Det tokenet
   maler også merker og statusfelt, og en knapp og et statusmerke har
   ikke samme jobb: knappen skal invitere, merket skal rapportere. Endret
   jeg tokenet, ville hvert «På plass»-merke i appen skiftet farge med.

   ÉN FARGE I BEGGE TEMAER, og det er trygt fordi knappen setter både sin
   egen bakgrunn og sin egen tekstfarge: kontrasten er selvbærende.
   --success-color måtte snu (#1e6b30 lys / #2f9c56 mørk) fordi den
   brukes på flater den arver; denne gjør ikke det.

   MØRK TEKST, ikke hvit. På en lys grønn gir hvit tekst 2,1:1 — under
   gulvet. #10210F gir 8,1:1, målt. Systemtesten måler det i begge
   temaer, så en seinere justering av grønnfargen ikke kan gli under i
   stillhet.

   DEN DELTE KLASSEN, ikke en ny ved siden av: Tiltak, Risiko, Avvik og
   Leverandør bruker alt .approve-button. Torleiv 16.10.2026: «de andre
   typene må også følge samme oppsett og logikk». Da skal det ikke
   finnes to grønne for den samme handlingen. */
:root {
    --godkjenn-color: #7CC47F;
    --godkjenn-dark: #68B06C;
    --godkjenn-text: #10210F;
}

.ghost.approve-button {
    background: var(--godkjenn-color);
    color: var(--godkjenn-text);
}

.ghost.approve-button:hover {
    background: var(--godkjenn-dark);
}

/* Kommentarer i oppgaver og på leverandører (Torleiv, 25.09.2026, med
   skjermbilde): «kommentarer i todoer må rammes inn og få hvit bakgrunn»,
   og «avstand mellom øverste teksteditor og Kommentarer-overskrift».

   sand_ui tegner .ui-comment som en strøm: gjennomsiktig bakgrunn med
   hårfine skillelinjer over og under. På Stomns sandfarge forsvinner den
   formen — kommentaren flyter rett på sida, mens skriveboksen rett under
   har både ramme og hvit flate. De to leses da som ulike slags innhold,
   enda det er det samme.

   Samme form som .ui-box ellers i appen (ramme, radius, --card-shadow), så
   en kommentar ser ut som et kort og ikke som en fjerde variant. Det er
   også grunnen til at fargene hentes fra de samme variablene og ikke
   skrives som #fff: mørk modus har to motorer i denne appen, og en
   hardkodet hvit ville stått igjen som et lysende kort i den ene av dem.

   Bare #comment-entries, ikke .ui-comment generelt: SKJEMAET for en ny
   kommentar bruker samme klasse, og det inneholder alt en redigeringsboks
   med egen ramme. Et kort rundt den ville gitt ramme inni ramme. */
#comment-entries .ui-comment {
    background-color: var(--ui-0);
    border: 1px solid var(--border-color);
    border-radius: var(--box-roundness, 7px);
    box-shadow: var(--card-shadow);
    margin-bottom: var(--space-4);
}

/* Skillelinjene hørte til strømmen. Med kort er mellomrommet skillet, og
   strekene blir en strek langs kortets egen ramme. */
#comment-entries .ui-comment:after,
#comment-entries .ui-comment:first-of-type:before {
    display: none;
}

/* Avataren og datokolonnen lå i utgangspunktet i venstremargen UTENFOR
   teksten. Nå er den margen innenfor kortet, så polstringen må ta igjen
   det de to står på — ellers henger de ut over kanten. */
#comment-entries .ui-comment .comment-avatar {
    inset-inline-start: var(--spaceing-md);
}

#comment-entries .ui-comment .comment-action {
    inset-inline-end: var(--spaceing-md);
}

@media (min-width: 600px) {
    #comment-entries .ui-comment .comment-meta-data {
        inset-inline-start: var(--spaceing-md);
    }

    #comment-entries .ui-comment .comment-avatar {
        inset-inline-start: calc(4 * var(--spaceing-lg));
    }
}

/* Overskrifta sto klistret til redigeringsboksen over, så de to leste som
   én blokk. .comment-thread hadde ingen egne stiler i det hele tatt. */
.comment-thread {
    margin-top: var(--space-8);
}

/* #10346447897 punkt 1, 28.09.2026: inne i en .controls-detail-boks skal
   tråden ha samme luft over seg som de andre seksjonene der, og de
   bruker .mt — altså --spaceing, ikke --space-8. Den frie varianten på
   oppgavesida beholder sin egen, større avstand: der er tråden en egen
   seksjon på sida og trenger å skille seg fra boksen over. */
.comment-thread--inline {
    margin-top: var(--spaceing);
}

/* Torleiv, 25.09.2026, med skjermbilde av kommentarfeltet: «hvit bakgrunn
   også når du skriver». Verktøylinja var hvit mens lerretet under var
   sandfarget, så boksen så halvferdig ut ved siden av kommentarkortene
   rett over.

   --lexxy-color-canvas settes til transparent av
   .ui-document-rich-content-editor (sand_ui/components/document.css), og
   det er RIKTIG der: på en dokumentside skal editoren smelte inn i arket.
   Kommentarfeltet er en annen sammenheng — det er et kort man skriver i,
   ikke et ark man redigerer.

   Derfor settes variabelen bare her, under selve skjemaet, og ikke globalt.
   --ui-0 er den samme flata kommentarkortene over har, og den følger temaet
   i stedet for å være en hardkodet hvit som ville lyst opp i mørk modus. */
/* 28.09.2026 (Torleiv, med skjermbilde av avvikssida): «kommentarer må
   rammes inn». Boksen hadde bakgrunn og runde hjørner, men ingen kant —
   og uten kant flyter verktøylinja og skrivefeltet i sida framfor å se ut
   som et sted å skrive. Samme kant som .ui-box bruker, så feltet leses
   som et kort på linje med kommentarkortene over. */
[id^="new_comment_for_"] .ui-document-rich-content-editor {
    --lexxy-color-canvas: var(--ui-0);

    background-color: var(--ui-0);
    /* --card-border er HELE shorthanden ("1px solid …"), ikke en farge —
       `1px solid var(--card-border)` ville blitt ugyldig og stille droppet. */
    border: var(--card-border);
    border-radius: var(--box-roundness, 7px);
    overflow: hidden;
}


/* MENYEN BAK «Sett inn register» (19.10.2026, #10412399059).

   EGEN KLASSE OG IKKE .lexxy-prompt-menu, og det er en lærdom fra
   kommentaren over: lexxy.css er ulagdelt og slår enhver lagdelt regel
   uansett spesifisitet. Lånte vi Lexxys klasse, ville vi arvet reglene
   som styrer NÅR den vises — og den vises bare når Lexxys egen prompt
   har åpnet den. Knappen her har ingen prompt bak seg (Torleiv valgte
   knapp framfor trigger), så menyen må eie sin egen synlighet.

   Plasseringen henger på verktøylinjeknappen, som allerede er
   posisjonert av .lexxy-editor__toolbar — derfor absolute mot den og
   ikke fixed: en fixed meny ville blitt stående igjen når verktøylinja
   klistrer seg oppover ved skrolling. */
@layer overrides {
    .register-embed-menu {
        position: absolute;
        z-index: 20;
        margin: 0.25rem 0 0;
        padding: 0.25rem;
        min-width: 14rem;
        list-style: none;
        background-color: var(--card-bg);
        border: 1px solid var(--border-color);
        border-radius: 0.5rem;
        box-shadow: 0 8px 24px rgb(0 0 0 / 0.12);
    }

    .register-embed-menu li {
        padding: 0.5rem 0.75rem;
        border-radius: 0.375rem;
        cursor: pointer;
        white-space: nowrap;
    }

    .register-embed-menu li:hover,
    .register-embed-menu li:focus-visible {
        background-color: var(--hover-bg, rgb(0 0 0 / 0.06));
        outline: none;
    }

    .register-embed-menu li:focus-visible {
        box-shadow: inset 0 0 0 2px var(--accent-color, currentColor);
    }
}