/*
 * STORMMBOX brand overlay for Roundcube Elastic skin
 * M&M Holding graphic manual: dark green / red / lime, M&M Sans
 *
 * This file is loaded ON TOP of the compiled Elastic styles.css
 * (see mm_theme.php -> include_stylesheet). It does not touch any
 * Elastic core file, so `bin/updatecss.sh` / skin rebuilds are never
 * required and Roundcube core updates cannot break it.
 *
 * Sections are ordered to match how a designer would scan the UI:
 * tokens -> font -> login screen -> app chrome (taskmenu/header) ->
 * buttons & links -> lists/selection -> misc polish.
 */

/* ------------------------------------------------------------------ */
/* 1. Brand tokens (for reference / reuse within this file only —     */
/*    Elastic's own CSS is static, compiled from LESS, so these vars  */
/*    are NOT consumed by Roundcube core, only by the rules below)    */
/* ------------------------------------------------------------------ */
:root {
	--mm-green-dark:   #004137; /* primary chrome background */
	--mm-green-hover:  #072523; /* hover/pressed shade of the above */
	--mm-lime:         #BEF06E; /* accent: selection, focus, success state */
	--mm-lime-subtle:  #E9F4B7;
	--mm-red:          #F50037; /* action: primary buttons, links */
	--mm-red-hover:    #d40030;
	--mm-white:        #FFFFFF;
}

/* ------------------------------------------------------------------ */
/* 2. Typeface — M&M Sans everywhere, falling back to the system font */
/*    stack Elastic already ships if a weight fails to load           */
/* ------------------------------------------------------------------ */
@font-face {
	font-family: 'MM Sans';
	src: url('fonts/MMSans-Regular.woff2') format('woff2');
	font-weight: 400;
	font-style: normal;
	font-display: swap;
}
@font-face {
	font-family: 'MM Sans';
	src: url('fonts/MMSans-Medium.woff2') format('woff2');
	font-weight: 500;
	font-style: normal;
	font-display: swap;
}
@font-face {
	font-family: 'MM Sans';
	src: url('fonts/MMSans-Semibold.woff2') format('woff2');
	font-weight: 600;
	font-style: normal;
	font-display: swap;
}
@font-face {
	font-family: 'MM Sans';
	src: url('fonts/MMSans-Bold.woff2') format('woff2');
	font-weight: 700;
	font-style: normal;
	font-display: swap;
}

html, body, button, input, select, textarea,
.tabsbar, .listing, .toolbar, #message-objects {
	font-family: 'MM Sans', 'Google Sans', -apple-system, BlinkMacSystemFont, 'Segoe UI', sans-serif !important;
}

/* ------------------------------------------------------------------ */
/* 3. Login screen                                                    */
/* ------------------------------------------------------------------ */
body.task-login {
	background: radial-gradient(circle at 50% 30%, var(--mm-green-hover) 0%, var(--mm-green-dark) 60%, #01251f 100%) !important;
}
/* Roundcube's login.html has #logo and #login-form as SIBLINGS inside
   #layout-content — so the card background goes on the shared parent,
   not on the form alone, otherwise the logo floats outside the card.

   Centering: `position: fixed` + `left: 50%` + `translateX(-50%)` instead
   of flex/margin-auto centering. This positions purely relative to the
   viewport box itself, so it can't drift left/right depending on a
   sibling's width, a scrollbar appearing on one side, or how #layout's
   own flex/justify-content resolves — those all turned out NOT to be
   reliably neutral across real browsers even though several of them
   measured perfectly centered in automated headless testing here. */
body.task-login #layout-content {
	position: fixed !important;
	left: 50% !important;
	top: 6vh !important;
	transform: translateX(-50%) !important;
	margin: 0 !important;
	background: var(--mm-white);
	border-radius: 16px;
	padding: 40px 36px 28px;
	box-shadow: 0 24px 60px rgba(0, 0, 0, 0.35);
	width: calc(100% - 32px);
	max-width: 420px;
	max-height: 88vh;
	overflow-y: auto;
}
body.task-login #logo {
	/* Elastic's own styles.css sets `top: 16vh;` on .task-login #logo for
	   the original full-bleed page layout — cancel it now that logo+form
	   live together in one compact card. */
	top: 0;
	display: block;
	margin: 0 auto 28px;
	max-width: 220px;
	max-height: none;
	height: auto;
}
body.task-login #login-form {
	/* Elastic's own styles.css sets:
	     top: 20vh; position: relative; width: 95%; max-width: 320px; margin: 0 auto;
	   — designed for the form floating alone on an empty page. Once it's
	   inside our narrower card, that fixed 320px max-width no longer
	   matches the card's own content-box width, and centering with
	   `margin:0` (an earlier version of this rule) dropped the `auto`
	   that was compensating for it — so the form (and everything in it:
	   inputs, the submit button, the OAuth button) sat flush left with
	   all the leftover space dumped on the right. Filling the card's
	   full width removes the mismatch instead of re-centering a
	   narrower box inside it. */
	top: 0;
	width: 100%;
	max-width: none;
	margin: 0;
}
body.task-login #login-form .btn-primary,
body.task-login #login-form button[type="submit"] {
	background-color: var(--mm-green-dark) !important;
	border-color: var(--mm-green-dark) !important;
	font-weight: 600;
}
body.task-login #login-form .btn-primary:hover,
body.task-login #login-form button[type="submit"]:hover {
	background-color: var(--mm-green-hover) !important;
	border-color: var(--mm-green-hover) !important;
}
body.task-login #login-form input.form-control:focus {
	border-color: var(--mm-green-dark) !important;
	box-shadow: 0 0 0 0.2rem rgba(0, 65, 55, 0.25) !important;
}
body.task-login #login-footer,
body.task-login #login-footer a {
	color: rgba(255, 255, 255, 0.75) !important;
}

/* Secondary auth action — Roundcube's own built-in OAuth login button
   (core functionality, shown whenever oauth_auth_uri + oauth_provider are
   configured; see program/include/rcmail_output_html.php). Real markup,
   confirmed against a running instance:
     <div class="oauthlogin"><a id="rcmloginoauth" class="button oauth {provider}">...</a></div>
   Style ONLY the inner <a> as the button — styling both it and its
   ".oauthlogin" wrapper (as an earlier version of this file did) produces
   a button-inside-a-button look. */
body.task-login #login-form .oauthlogin {
	margin-top: 12px;
}
body.task-login #login-form .oauthlogin a.button,
body.task-login #login-form #rcmloginoauth {
	display: block;
	background: var(--mm-white) !important;
	border: 1.5px solid var(--mm-green-dark) !important;
	color: var(--mm-green-dark) !important;
	border-radius: 7px;
	font-weight: 600;
	text-align: center;
	padding: 9px 10px;
}
body.task-login #login-form .oauthlogin a.button:hover,
body.task-login #login-form #rcmloginoauth:hover {
	background: var(--mm-lime-subtle) !important;
}

/* ------------------------------------------------------------------ */
/* 4. App chrome — task sidebar (mobile: slide-in menu) + top headers */
/* ------------------------------------------------------------------ */
#layout-menu,
#layout-menu .popover-header,
#taskmenu,
#taskmenu .special-buttons {
	/* .special-buttons (Tmavý režim / O programu / Odhlásit) has its own
	   explicit background in Elastic's core CSS — it doesn't just inherit
	   #taskmenu's, so it needs naming here too or it stays Elastic's
	   default gray-navy instead of following the rest of the rail. */
	background-color: var(--mm-green-dark) !important;
}
/* Elastic's own "Tmavý režim" (dark.less, html.dark-mode) is a SEPARATE
   feature from our theme — it repaints the app for low-light viewing,
   unsets #layout-menu's background entirely, and explicitly forces
   .special-buttons transparent (with its own !important), which just
   exposes Elastic's default dark gray on each individual link. Since our
   brand chrome is already dark, re-assert it at matching specificity so
   toggling "Tmavý režim" doesn't undo the rail's color. */
html.dark-mode #layout-menu,
html.dark-mode #taskmenu,
html.dark-mode #taskmenu .special-buttons {
	background-color: var(--mm-green-dark) !important;
}
html.dark-mode #taskmenu .special-buttons a {
	background-color: transparent !important;
}

/* The 1px column divider between sidebar/list/preview panes reads as a
   stark white line wherever it crosses our dark green header bars —
   Elastic's own border color is a light gray meant for a white page. */
#layout-sidebar,
#layout-list,
#layout-menu {
	border-color: rgba(0, 0, 0, 0.18) !important;
}
/* Same divider, dark mode: a dark, low-opacity line meant to read as a
   subtle seam on a WHITE page is close to invisible on dark mode's
   near-black one — needs to go light instead of dark to still read as a
   seam there. Runs the panel's full height either way (it's the column's
   own border, not tied to how many rows/messages exist inside it). */
html.dark-mode #layout-sidebar,
html.dark-mode #layout-list,
html.dark-mode #layout-menu {
	border-color: rgba(255, 255, 255, 0.16) !important;
}
/* The draggable column-resize handle sits in a 6px gap *outside* each
   panel's own box (position:absolute; right:-3px), so it paints
   whatever is behind it — the panel's plain white background — with no
   background of its own. Where it crosses a dark green `.header` bar
   that shows as a thin white seam cutting through the header. Capping
   the resizer's own background at the header's height (58px = Elastic's
   @layout-header-height) covers exactly that seam and nothing below it,
   so the rest of the divider stays invisible against the white list/
   preview body like before. */
.column-resizer {
	background: linear-gradient(var(--mm-green-dark), var(--mm-green-dark)) top / 100% 58px no-repeat !important;
}
/* App-chrome logo: just the M&M mark (logo.svg), no "Holding" wordmark —
   the full lockup doesn't leave room to read at this width. Elastic's
   own CSS caps the logo <img> at `max-width: @layout-menu-width` (78px,
   matching the icon-rail's own width) — a first version of this rule
   removed that cap, which just let the logo overflow the 78px-wide rail
   and get clipped by whatever sits to its right, instead of growing it.
   The rail itself is only that narrow on desktop (min-width:1025px is
   Elastic's own matching breakpoint, @screen-width-medium+1 — narrower
   layouts use a different width and must stay untouched), so growing
   the logo for real means growing the rail at that same breakpoint. */
@media screen and (min-width: 1025px) {
	#layout-menu {
		width: 100px !important;
	}
	#layout-menu .popover-header #logo {
		/* Sized to leave real margin on both sides of the 100px rail —
		   at 84px it nearly touched the rail's own edges, which is what
		   read as a stray seam/gap right at the header. */
		max-width: 60px !important;
		max-height: 40px !important;
		padding: 0 !important;
	}
	/* The actual cause of that "everything's off to the left" look,
	   found by comparing box positions: Elastic's nav buttons
	   (Napsat/E-mail/Kontakty/…) have a hard `width: 78px` sized for the
	   rail's ORIGINAL width, left-aligned inside it rather than filling
	   it — so once the rail became 100px they sat flush-left with 22px
	   of dead space on the right, no longer centered under the logo
	   above them (measured centers: logo at the true 50px middle, icons
	   at 39px — an 11px mismatch, exactly the "shift" being pointed at). */
	#taskmenu a,
	#taskmenu .action-buttons a {
		width: 100% !important;
		max-width: none !important;
		min-width: 0 !important;
		box-sizing: border-box !important;
	}
	/* .special-buttons (Tmavý režim/O programu/Odhlásit) is `position:
	   absolute; bottom:0; left:0` in Elastic's own CSS — a % width (or
	   display:block, tried first) resolves against whatever ITS
	   containing block turns out to be, which is NOT reliably #taskmenu's
	   100px, and sent the whole group flying to the far bottom-right of
	   the page instead of just widening it. A fixed px width sidesteps
	   that ambiguity entirely. */
	#taskmenu .special-buttons,
	#taskmenu .special-buttons a {
		width: 100px !important;
		max-width: none !important;
		box-sizing: border-box !important;
	}
}

/* Real markup (confirmed against a running instance — templates/includes/
   menu.html): these are plain <a class="mail">, <a class="contacts">,
   <a class="compose">, <a class="mail selected"> etc. — there is no
   generic "button" or "task-menu-button" class to hook into on desktop
   (that's a mobile-only class Elastic adds at a narrower breakpoint), so
   selectors built around it silently never matched. `#taskmenu a`
   covers every nav item uniformly instead of guessing at per-item
   classes. */
#taskmenu a {
	color: var(--mm-white) !important;
}
/* :hover and :focus deliberately share ONE declaration — they used to
   differ (focus was transparent + outline only), and hovering an item
   that also still holds focus (e.g. right after a click) let the two
   rules fight over the same specificity, so whichever was later in the
   file won — which could paint the button transparent-on-transparent
   and read as blank. Elastic's dark.less also carries its own
   `html.dark-mode #taskmenu a:hover` rule at that same specificity, so
   it's repeated here too rather than trusting !important + source order
   alone to beat it in dark mode. */
#taskmenu a:hover,
#taskmenu a:focus,
html.dark-mode #taskmenu a:hover,
html.dark-mode #taskmenu a:focus {
	background-color: var(--mm-lime) !important;
	color: var(--mm-green-dark) !important;
	outline: none !important;
}
/* Lime = "you are here" — the ONE nav item matching the current task/
   action (Mail, Kontakty, Nastavení, or Napsat while actually composing)
   gets it, via Elastic's own "selected" class. It's a state, not a
   permanent color on any one button. */
#taskmenu a.selected {
	background-color: var(--mm-lime) !important;
	color: var(--mm-green-dark) !important;
}
#taskmenu a.selected:hover {
	background-color: #aee85c !important;
}
#taskmenu a.logout {
	color: var(--mm-red) !important;
}
#taskmenu a.logout:hover {
	background-color: var(--mm-red) !important;
	color: var(--mm-white) !important;
}

/* Panel headers (folder title bar, message subject bar, mobile top bar).
   NOTE: ".header-title" on its own (an earlier version of this rule) is
   NOT safe to use unscoped — Roundcube reuses that exact class name for
   the label cells of the message headers table (From/To/Date — see
   program/actions/mail/show.php), which is a completely unrelated table
   deep inside the message preview, not a panel header. Unscoped, it
   turned every "Odesílatel / Adresát / Datum" label into a dark green
   block. Only style it as a panel title when it's actually inside one of
   our panel `.header` bars. */
#layout > div > .header,
#layout-content > .header,
#layout-list > .header {
	background-color: var(--mm-green-dark) !important;
	color: var(--mm-white) !important;
}
#layout > div > .header a,
#layout-content > .header a,
#layout-list > .header a,
#layout > div > .header .header-title,
#layout-content > .header .header-title,
#layout-list > .header .header-title {
	color: var(--mm-white) !important;
}
#layout > div > .header .button:hover,
#layout-content > .header .button:hover,
#layout-list > .header .button:hover,
#layout > div > .header a.sortcol:hover {
	background-color: var(--mm-lime) !important;
	color: var(--mm-green-dark) !important;
}

/* Toolbars (Vybrat/Možnosti/Obnovit above the list, Odpovědět/Přeposlat/
   Smazat above a read message) — hover state to lime, matching every
   other interactive chrome element instead of Elastic's barely-there
   default gray hover. */
.toolbar a.button:not(.disabled):hover,
.toolbar li a:not(.disabled):hover,
#toolbar-list-menu a:not(.disabled):hover,
#toolbar-menu a:not(.disabled):hover,
#message-menu a:not(.disabled):hover,
html.dark-mode .toolbar a.button:not(.disabled):hover,
html.dark-mode .toolbar li a:not(.disabled):hover,
html.dark-mode #toolbar-list-menu a:not(.disabled):hover,
html.dark-mode #toolbar-menu a:not(.disabled):hover,
html.dark-mode #message-menu a:not(.disabled):hover {
	/* dark.less carries its OWN hover rule for these same elements
	   (`.menu a:not(.disabled):hover { background: @color-dark-list-
	   selected-background }`, a flat gray) scoped under html.dark-mode —
	   repeating our selector under that same scope, the way the taskmenu
	   fix above already does, instead of trusting !important alone to
	   beat it. */
	background-color: var(--mm-lime) !important;
	color: var(--mm-green-dark) !important;
}
/* The background rule above was taking effect but not the text color —
   something with higher specificity than a plain class selector (an
   id-scoped Elastic rule, most likely) was still pinning it to white,
   invisible against lime. Forcing it on every icon glyph inside too,
   since those are separate elements (<span>/pseudo-element) that don't
   automatically inherit a `color` change on their `:hover`-ed parent. */
.toolbar a.button:not(.disabled):hover *,
.toolbar li a:not(.disabled):hover *,
#toolbar-list-menu a:not(.disabled):hover *,
#toolbar-menu a:not(.disabled):hover *,
#message-menu a:not(.disabled):hover *,
html.dark-mode .toolbar a.button:not(.disabled):hover *,
html.dark-mode .toolbar li a:not(.disabled):hover *,
html.dark-mode #toolbar-list-menu a:not(.disabled):hover *,
html.dark-mode #toolbar-menu a:not(.disabled):hover *,
html.dark-mode #message-menu a:not(.disabled):hover * {
	color: var(--mm-green-dark) !important;
}
/* A dropdown trigger ("Více"/More, "Odpovědět…", etc.) only had the lime
   look while the mouse stayed over it — as soon as the pointer moves
   down into its own open menu, :hover on the trigger ends and it fell
   back to Elastic's plain gray "toggled" look, even though the menu is
   still open. [aria-expanded="true"] would be the correct signal for
   that but Roundcube never actually flips it here (confirmed live — it
   stays "false" the whole time the popup is open). What Bootstrap's
   popover JS *does* add while open is `aria-describedby="popoverNNNNNN"`
   on the trigger, so key off that instead.
   Scope: the labeled toolbar triggers (Více/Vybrat/Možnosti and the
   .dropbutton split-buttons like Odpovědět.../Přeposlat), PLUS the ⋮
   account-actions trigger next to "as@localhost" above "Příchozí
   pošta" (id="rcmbtn110", class includes "sidebar-menu"). An earlier
   version excluded that one on request — icon-only felt like a
   shapeless block — then was asked back in for consistency, so it's
   targeted directly by class rather than broadening the .toolbar scope
   (it isn't inside a .toolbar, so it needs its own selector either way,
   and this keeps any OTHER icon-only trigger from picking it up by
   accident). */
.toolbar a[aria-describedby^="popover"],
.toolbar a[aria-describedby^="popover"] *,
a.sidebar-menu[aria-describedby^="popover"],
a.sidebar-menu[aria-describedby^="popover"] *,
a.sidebar-menu:hover,
a.sidebar-menu:hover *,
html.dark-mode a.sidebar-menu:hover,
html.dark-mode a.sidebar-menu:hover * {
	background-color: var(--mm-lime) !important;
	color: var(--mm-green-dark) !important;
}
/* Split buttons (.dropbutton — "Přeposlat"/Forward etc.) are TWO
   sibling <a>: the main action and a separate caret. Only the caret is
   the actual popup trigger and gets aria-describedby when open, so with
   just the rule above the caret went lime while the main label right
   next to it stayed in its washed-out default — light gray, unreadable
   against dark green. Style the whole wrapper when either child is the
   open trigger, so both halves read as one consistent lime button. */
.toolbar .dropbutton:has(> a[aria-describedby^="popover"]),
.toolbar .dropbutton:has(> a[aria-describedby^="popover"]) *,
.toolbar .dropbutton:hover,
.toolbar .dropbutton:hover *,
html.dark-mode .toolbar .dropbutton:hover,
html.dark-mode .toolbar .dropbutton:hover * {
	/* Same story, different trigger: hovering the caret ALONE (before any
	   click) also counts as :hover on their shared .dropbutton parent —
	   Elastic's own `.dropbutton:not(.disabled):hover` then paints that
	   wrapper flat light gray (confirmed live, both light and dark mode)
	   while our own hover rule was separately turning just the caret
	   lime, so the two halves visibly disagreed the moment you moved the
	   mouse onto the arrow, not only once the menu was actually open. */
	background-color: var(--mm-lime) !important;
	color: var(--mm-green-dark) !important;
}

/* ------------------------------------------------------------------ */
/* 5. Buttons & links (chrome only — message iframes are a separate   */
/*    document and are never touched by this stylesheet)              */
/* ------------------------------------------------------------------ */
a {
	color: var(--mm-red);
}
a:hover {
	color: var(--mm-red-hover);
}
/* Bootstrap's `.btn-link` (e.g. compose's "Otevřít v novém okně") sets
   its own blue via a class selector, which outranks the plain-element
   rule above. NOTE: an earlier version made the base `a` rule itself
   `!important`, meaning to catch just this one case — instead it beat
   every other color rule for links anywhere, including message list
   subjects and popup-menu items, turning entire read/unread inboxes and
   dropdown menus red. Scope the !important to .btn-link specifically. */
a.btn-link {
	/* Dark green, not red — these (e.g. "Otevřít v novém okně") are
	   neutral utility links, not calls to action, and red reads as
	   "do this now" in a way that's misleading for a plain window-open
	   toggle. */
	color: var(--mm-green-dark) !important;
}
a.btn-link:hover {
	color: var(--mm-green-hover) !important;
}

.btn-primary,
.button.mainaction,
button.mainaction,
a.button.create {
	background-color: var(--mm-red) !important;
	border-color: var(--mm-red) !important;
	color: var(--mm-white) !important;
}
.btn-primary:hover,
.button.mainaction:hover,
button.mainaction:hover,
a.button.create:hover {
	background-color: var(--mm-red-hover) !important;
	border-color: var(--mm-red-hover) !important;
}

/* Focus ring — brand lime instead of the default blue, everywhere
   (Bootstrap's default focus box-shadow is blue too — not just the
   outline — so both need overriding, app-wide, not just on the login
   screen's inputs). */
a:focus-visible,
button:focus-visible,
.button:focus-visible,
input:focus-visible,
textarea:focus-visible,
select:focus-visible {
	outline-color: var(--mm-lime) !important;
}
.form-control:focus,
input.form-control:focus,
textarea.form-control:focus,
select.form-control:focus,
.form-control.focus {
	/* The compose recipient field (To/Cc/Bcc) isn't a plain input — it's
	   a <ul class="form-control recipient-input …"> that Roundcube's own
	   JS toggles a literal ".focus" CLASS on, not :focus the pseudo-
	   class, so it needs its own selector alongside the real :focus one. */
	border-color: var(--mm-green-dark) !important;
	box-shadow: 0 0 0 0.2rem rgba(0, 65, 55, 0.25) !important;
}

/* TinyMCE (the HTML compose editor) is its own widget with its own skin,
   not a plain .form-control, and draws its focus ring in cyan by
   default — cover every element that plausibly carries that border/
   box-shadow rather than chasing TinyMCE's exact internal selector. */
.tox-tinymce,
.tox-tinymce:focus-within,
.tox-edit-area,
.tox-edit-area__iframe {
	border-color: var(--mm-green-dark) !important;
}
.tox-edit-area::before {
	box-shadow: 0 0 0 2px var(--mm-green-dark) !important;
}

/* Roundcube's own blue (@color-main, #37beff) shows up in popup/dropdown
   menus (e.g. the folder-switcher opened from the "Příchozí pošta"
   title, toolbar "Možnosti" menu) as the hover/active background —
   replace with lime, everywhere, no blue anywhere in the app. */
.popupmenu a:not(.disabled):hover,
.popupmenu .dropbutton:not(.disabled):hover,
.popupmenu a.dropdown:hover {
	background-color: var(--mm-lime) !important;
	color: #0D0D0D !important;
}

/* Every one of these dropdowns (folder-switcher from "Příchozí pošta",
   "Vybrat", "Možnosti", "Více", the account menu, "Akce se složkou…")
   turned out to be the SAME mechanism — a Bootstrap `.popover` wrapping
   a `.popupmenu`. The menu items were already lime-on-hover via the
   rule above, but the popover chrome around them (confirmed live:
   `.popover-header` reading "Akce se složkou…") is untouched Bootstrap
   default — plain white/gray, which is what still shows as soon as the
   menu opens instead of just on hover. */
.popover {
	border-color: var(--mm-green-dark) !important;
	box-shadow: 0 12px 32px rgba(0, 65, 55, 0.28) !important;
}
.popover .popover-header {
	background-color: var(--mm-green-dark) !important;
	color: var(--mm-white) !important;
	border-bottom-color: var(--mm-green-hover) !important;
}
.popover .arrow::before,
.popover .arrow::after {
	border-top-color: var(--mm-green-dark) !important;
	border-bottom-color: var(--mm-green-dark) !important;
}

/* Some dropdowns (e.g. the "Přeposlat" split-button's submenu,
   #forward-menu) render their .popupmenu WITHOUT the Bootstrap .popover
   wrapper above — confirmed live, its real parent chain is
   li > ul.menu.listing > div.popupmenu, no .popover anywhere — so it
   falls back to Elastic's bare default look (thin gray border, flat),
   which reads as an unstyled gray box next to everything else that's on
   brand. Giving .popupmenu its own consistent chrome covers both cases
   instead of depending on which wrapper happens to be present. */
.popupmenu {
	background-color: var(--mm-white);
	border: 1px solid var(--mm-green-dark) !important;
	border-radius: 8px;
	box-shadow: 0 12px 32px rgba(0, 65, 55, 0.28);
}

/* ------------------------------------------------------------------ */
/* 6. Lists — selection & unread accents                              */
/* ------------------------------------------------------------------ */
.listing tr.selected,
.listing tr.selected td,
#contacts-table tr.selected,
.listing li.selected,
.listing li.selected > a {
	/* Both the folder tree (.treelist.listing — "Příchozí pošta" etc.) and
	   the Settings section list (ul#settings-menu.listing, no .treelist
	   class) mark their selected item on an <li>, not a <tr> like every
	   other listing in the app — Roundcube doesn't use one consistent
	   element type for "selected", so each list needs checking against
	   real markup rather than assumed. */
	background-color: var(--mm-lime-subtle) !important;
	color: #0D0D0D !important;
}
.listing tr.unread .subject,
.listing tr.unread .fromto {
	color: var(--mm-green-dark) !important;
	font-weight: 600 !important;
}
/* Dark green text (unread) and near-black text (selected row) both read
   fine on our light-mode lime backgrounds, but Elastic's "Tmavý režim"
   repaints the page near-black — dark green-on-near-black and near-
   black-on-near-black both disappear, which is what made the list
   unreadable there. */
html.dark-mode .listing tr.selected,
html.dark-mode .listing tr.selected td,
html.dark-mode .listing li.selected,
html.dark-mode .listing li.selected > a {
	/* Dark green here was readable but visually merged into the sidebar
	   rail sitting right next to it — same brand color, hard to tell
	   "this is the selected folder" from "this is just chrome". Lime
	   reads as a distinct accent against dark mode's near-black surfaces
	   the way it already does in light mode. */
	background-color: var(--mm-lime) !important;
	color: #0D0D0D !important;
}
html.dark-mode .listing tr.unread .subject,
html.dark-mode .listing tr.unread .fromto {
	color: var(--mm-lime) !important;
}
/* A row that's BOTH selected AND unread needs the "selected" text color
   to win over the "unread" one — otherwise the two rules above collide
   and neither may end up applying to the actual <a>, which stays at its
   unstyled default link blue (confirmed live: exactly what was showing,
   in both modes, and especially unreadable on dark mode's lime). Anchors
   don't inherit `color` from an ancestor's rule the way plain text does,
   so this has to target the <a> itself, not just the row/cell. */
.listing tr.selected a {
	color: #0D0D0D !important;
}
html.dark-mode .listing tr.selected a {
	color: #0D0D0D !important;
}
/* Row separators (the thin line between each message) — Elastic's dark
   mode sets them to a near-black rgb(44,55,58), barely a shade off the
   near-black row background itself, so rows visually run together with
   almost no seam. A lighter, actually-visible line. */
html.dark-mode .listing tbody td,
html.dark-mode .listing tbody tr {
	border-color: rgba(255, 255, 255, 0.14) !important;
}
/* (Tried continuing the same stripe as a repeating background past the
   last real row, so an inbox with only a few messages wouldn't leave a
   big dead-looking gap below them — asked to revert: it read as a row
   of phantom empty messages rather than "just empty space", which is
   worse. Real row borders above only, nothing implied past the last
   actual <tr>.) */
.listing tr.selected .uid.unread .status-icon,
.list-message-icon .status-icon.msgicon-unread {
	color: var(--mm-red) !important;
}
/* Selected/keyboard-focused row indicator — a 2px left border, blue by
   default (@color-list-focus-indicator). Dark green, not lime: this is a
   "you're here" marker sitting right next to the light lime row
   background, so it needs to be the darker brand tone to read as a
   distinct accent rather than disappearing into the lime. */
.listing.focus tbody tr.focused > td:first-child,
.listing.focus:not(.withselection) tbody tr.focused > td.selection + td {
	border-left-color: var(--mm-green-dark) !important;
}

/* Badges (unread counters, folder counts). Real class confirmed against
   a running instance is ".unreadcount" (not ".badge"/".itemcount" as an
   earlier version of this rule assumed — those matched nothing, which is
   why the count pill stayed Elastic's default blue). */
.badge,
.itemcount,
.unreadcount {
	background-color: var(--mm-red) !important;
	color: var(--mm-white) !important;
}

/* ------------------------------------------------------------------ */
/* 7. Misc polish                                                     */
/* ------------------------------------------------------------------ */
::selection {
	background-color: var(--mm-lime);
	color: #0D0D0D;
}
::-webkit-scrollbar-thumb {
	background-color: rgba(0, 65, 55, 0.4);
}
::-webkit-scrollbar-thumb:hover {
	background-color: var(--mm-green-dark);
}

/* Checkboxes/radios (Settings → Vlastnosti etc.) — native accent-color
   covers modern browsers outright; Bootstrap's custom-styled variant
   (native input hidden, a ::before/::after pair painted instead) needs
   its own override since accent-color doesn't reach into that. */
input[type="checkbox"],
input[type="radio"] {
	accent-color: var(--mm-green-dark);
}
.custom-control-input:checked ~ .custom-control-label::before {
	border-color: var(--mm-green-dark) !important;
	background-color: var(--mm-green-dark) !important;
}
.custom-control-input:focus ~ .custom-control-label::before {
	box-shadow: 0 0 0 0.2rem rgba(0, 65, 55, 0.25) !important;
}