into a flex row and
pulls `td.flags` out of the flow on top of it. The date is a fixed string;
it is the sender that has room to give. */
.messagelist td.subject .date {
flex: 0 0 auto;
white-space: nowrap;
padding-left: 10px;
}
.messagelist td.subject .fromto {
flex: 1 1 auto;
min-width: 0;
}
/* `td.flags` is absolutely positioned at the right edge below 1024px (Elastic,
html.touch) with its flag hidden -- an invisible 35px box sitting over the
end of the row. The cell has to reserve it, or the date runs underneath. */
html.touch .messagelist td.subject,
html.layout-phone .messagelist td.subject {
padding-right: 38px;
}
/* ⚠ The toast stack is pinned to the bottom right of the window, which below
the desktop is where the tab bar is -- and at phone size Elastic stretches it
edge to edge, straight over it. Lifted clear.
⚠ THE SAME QUERY AS §2c, both halves of it. This is the bar's height read in
a second place; if the tab bar shows and this does not, the toast sits on top
of it. */
@media screen and (max-width: 1024px),
screen and (max-width: 1279px) and (pointer: coarse) {
#messagestack {
/* ⚠ In step with the tab bar's own height in §2c. */
bottom: calc(52px + .5em);
}
}
.messagelist td.subject span.subject {
font-size: 13.5px;
}
/* Rows: a FULL-BLEED band, edge to edge. The rounded-block treatment the
folder rail uses is right for a rail of short pills and wrong for a dense
list -- a radius at the right edge of every selected message reads as a
card that has come loose from the column.
⚠ `width: 100%` on the table, or the band stops wherever the columns happen
to end: Elastic lets .messagelist size to its content, so the fill ended
72px short of the column's right edge and "the whole row" was never marked. */
.messagelist {
width: 100%;
}
.messagelist tr.message > td {
border-bottom: 1px solid var(--line-2, #eee);
padding-top: 7px;
padding-bottom: 7px;
background: transparent;
}
.messagelist tr.message:last-child > td {
border-bottom: 0;
}
.messagelist tr.message:hover > td {
background: var(--hover, #f5f5f8);
}
.messagelist tr.message.selected > td {
background: var(--sel, #eceaf7);
border-bottom-color: transparent;
}
/* ⚠ The subject is a LINK, so Elastic paints it @color-link -- every row's
subject in the theme's brand colour. In the app the subject is body text and
only the accent-coloured things are actionable, which is what makes an
unread row's weight readable as the signal it is. */
.messagelist td.subject span.subject a {
color: var(--text, #222);
}
.messagelist tr.message.selected td.subject span.subject a {
color: var(--text-strong, #111);
}
.messagelist tr.unread td.subject span.subject a {
color: var(--text-strong, #111);
font-weight: 700;
}
/* Elastic reserves 1.5em of left padding on the sender for a flag slot the
app does not use, which leaves every row visibly indented from its date. */
.messagelist td.subject span.fromto {
padding-left: 0;
}
/* -------------------------------------------------------------- 6. search */
/* ⚠ THE ONE COLOUR IN THIS SKIN THAT WAS NEVER THEMED. Elastic marks the
focused row with
html:not(.touch) .listing li > a:focus,
html:not(.touch) .listing.focus tbody tr.focused > td:first-child, …
{ border-left: 2px solid #86d820 }
and that literal appears once in styles.css and NOT ONCE in themes.css: it
is not derived from any LESS colour variable, so the per-declaration diff
had nothing to map and the bar stayed Roundcube's green in all twelve
schemes -- including the three dark ones, where it is the only green pixel
on the screen.
⚠ `--marker`, which is `--compose-btn` on eleven of the twelve: the compose
button's fill is the one colour each theme uses to mean "this one", which is
what the marker says.
⚠ GREEN IS THE EXCEPTION, AND IT IS THE SAME EXCEPTION AS THE WORDMARK. Its
`--compose-btn` is #17293a navy -- the only theme whose "this one" colour is
not its own hue -- so the marker came out as a dark bar that read as a
border rather than a highlight. Green alone points `--marker` at #78be20,
the house green it now shares with "Quantum" (§8e) and with the selected
folder icon (§4a). This is a restoration: the marker WAS green here, and was
given up when the rule was unified on `--compose-btn`. The token is what
lets one theme differ without the other eleven being restated.
⚠ Why a token and not a scoped rule: `:root` IS `html`, so a green-only
override written there would cascade into all twelve. `test_selection_marker`
pins both halves.
⚠ The selector is Elastic's own, restated -- `html:not(.touch)` is (0,1,1)
plus the rest, so anything shorter loses.
⚠ AND `td.selection + td` IS THE ONE THAT ACTUALLY PAINTS. Roundcube renders
a selection column in the message and contact lists and Elastic HIDES it
while the list is not in selection mode, which is why its third selector
reads `.listing.focus:not(.withselection) tbody tr.focused > td.selection +
td` -- the marker sits on the cell AFTER the hidden one, flush at the row's
left edge, and `td:first-child` is a cell nobody can see. The first cut of
this rule restated only the first two selectors and the harness had no
selection cell, so the suite went green while every real install kept
Roundcube's green bar. Measured: `td:first-child` #4338ca, `td.selection +
td` #86d820, in the same row. */
/* ⚠ EXCEPT ON THE RAIL. `#layout-sidebar` is the folder list and the address
books, where the selected row is already a filled panel across its whole
width -- a second mark on its left edge read as a stray bracket, because
Elastic's 2px border sits inside a 9px radius and a rounded left border IS a
bracket. The colour is dropped, not the border: the 2px is what keeps every
row's text on the same left edge, marked or not.
⚠ Keyboard focus is unaffected -- that is the `:focus-visible` ring in §11,
a different mark for a different question. */
#layout-sidebar .listing li > a,
#layout-sidebar .listing li.selected > a,
#layout-sidebar .listing li > a:focus,
#layout-sidebar .treelist li > a,
#layout-sidebar .treelist li.selected > a,
#layout-sidebar .treelist li > a:focus {
border-left-color: transparent;
}
html:not(.touch) .listing li > a:focus,
html:not(.touch) .listing.focus tbody tr.focused > td:first-child,
html:not(.touch) .listing.focus li.focused:not(.selected) > a,
html:not(.touch) .listing.focus li.focused > div > a,
html:not(.touch) .listing.focus tbody tr.focused.selected > td:first-child,
html:not(.touch) .listing li.selected > a,
html:not(.touch) .listing tbody tr.selected > td:first-child,
html:not(.touch) .listing.focus:not(.withselection) tbody tr.focused > td.selection + td,
html:not(.touch) .listing:not(.withselection) tbody tr.selected > td.selection + td {
border-left-color: var(--marker, var(--compose-btn, var(--brand, #4f7f13)));
}
/* ⚠ THE BOX IS §8f's, not this rule's. `#layout > div > .searchbar` is (1,1,1)
against this (1,1,0) and states padding, border and background there; the
three declarations that used to be here were computed by nobody. What is
left is the row itself, which §8f does not set. */
#layout-list .searchbar {
display: flex;
align-items: center;
gap: 4px;
}
/* ⚠ THE ICONS NEED ROOM OF THEIR OWN. Elastic hangs the magnifier off the
form's `:before` with `margin: 0 0 0 .75rem` and gives the two buttons on the
right a `:before` of `width: 2rem; height: 36px` -- three glyphs with no box
and no gap, so the pair on the right sat hard against the panel's edge and
the magnifier crowded the pill. Each becomes a square target, the row gaps
them, and the field gives up the width. */
#layout-list .searchbar form {
display: flex;
align-items: center;
flex: 1 1 auto;
min-width: 0;
gap: 2px;
}
/* ⚠ NO MAGNIFIER, at either end. Elastic prints one as `form:before` and
ships a second as `a.button.search`; the field already says "Suchen …", and
two icons for one idea is what made this row six controls wide. Removing
`content` rather than the element keeps Elastic's own box arithmetic intact.
⚠ `a.search` is Elastic's SUBMIT, and it hides it too (`.searchbar a.reset,
.searchbar a.search { display: none }`) -- the blanket `> a` rule below is
what brought it back, so it is put down again explicitly. Enter still
submits the form. */
#layout-list .searchbar form:before {
content: none;
}
#layout-list .searchbar > a.search {
display: none !important;
}
/* ⚠ THE RESET SITS INSIDE THE FIELD, and it is a SIBLING of the form, not a
child -- Roundcube builds the row as `form, reset, options, search` and
ui.js splices the unread button in before options. So it is pulled back over
the field with a negative margin rather than positioned absolutely: 34px
wide against `-38px` (its width plus the row's 4px gap) advances the row by
exactly zero, so the buttons after it stand precisely where they would if it
were not there -- while the ✕ paints over the last 34px of the pill.
⚠ Only while there is something to reset. Elastic shows it on
`.searchbar.active`, which `searchbar_init()` maintains; the blanket `> a`
rule below out-ranked that and put an ✕ on an empty field. */
/* ⚠ `:not(.active)`, not a bare `a.reset`. The reset carries `button` in its
class list, so `.searchbar > a.button` below TIES with it on specificity
and wins on order -- an ✕ on an empty field, which is exactly the state
Elastic hides it in. The state class puts this rule a class ahead. */
#layout-list .searchbar:not(.active) > a.reset {
display: none;
}
#layout-list .searchbar.active > a.reset {
display: inline-flex;
position: relative;
z-index: 1;
margin-left: -38px;
}
#layout-list .searchbar > a.button,
#layout-list .searchbar > a {
display: inline-flex;
align-items: center;
justify-content: center;
flex: none;
width: 34px;
height: 34px;
border-radius: 9px;
color: var(--bar-ic, #444);
}
#layout-list .searchbar > a:hover {
background: var(--bar-ic-hover, var(--hover, #eef0f4));
color: var(--text, #222);
}
#layout-list .searchbar a:before {
width: auto;
height: auto;
margin: 0;
line-height: 1;
}
#layout-list .searchbar input {
height: 36px;
border-radius: 999px;
/* The app calls it --search-bd. (The plan document writes --search-line;
the stylesheet is the authority.) */
border: 1px solid var(--search-bd, var(--line, #ddd));
background: var(--search-bg, var(--app-bg, #fafafa));
/* ⚠ Room on the right for the ✕ that now sits inside the field -- and
stated as one shorthand, because a `padding-right` written before this
line would be reset by it. */
padding: 0 40px 0 14px;
font-size: 13.5px;
color: var(--text, #222);
}
#layout-list .searchbar input::placeholder {
color: var(--muted-2, #888);
}
/* ------------------------------------------------------- 7. reading pane */
/* ⚠ The reading pane is a FRAME. message.html renders inside
`` with no `#layout` wrapper, so every rule below is
written without one -- and `.frame-content`'s own 14px sits on top of
whatever this header pads, which is how the subject came to start 32px
below the toolbar. The frame supplies no padding of its own here; the
header and the body each state theirs. */
body.task-mail .frame-content {
padding: 0;
}
#message-header {
padding: 10px 20px 12px;
border-bottom: 1px solid var(--line-2, #eee);
margin: 0;
}
#message-header h2.subject {
font-size: 20px;
font-weight: 700;
line-height: 1.35;
color: var(--text-strong, #111);
margin: 0 0 12px;
}
#message-header .header {
display: flex;
align-items: flex-start;
gap: 12px;
/* Section 3 styles #layout > div > .header -- the column heads. This one is
nested inside the reading pane and must not inherit that 60px chrome. */
min-height: 0;
padding: 0;
border: 0;
background: transparent;
}
#message-header .contactphoto {
width: 40px;
height: 40px;
flex: none;
border-radius: 50%;
overflow: hidden;
background: var(--sel, #eceaf7);
}
#message-header .contactphoto img {
width: 100%;
height: 100%;
object-fit: cover;
}
#message-header .header-summary {
font-size: 13.5px;
color: var(--text, #222);
}
#message-header .header-summary .name {
font-weight: 500;
color: var(--text-strong, #111);
}
#message-header .header-headers,
#message-header .header-summary .date {
font-size: 12.5px;
color: var(--muted, #666);
}
#message-header .header-links a {
font-size: 12.5px;
color: var(--muted, #666);
}
#message-header .header-links a:hover {
color: var(--accent, #4a3fbf);
}
#message-content,
#messagebody {
padding: 4px 20px 20px;
}
/* ⚠ `@color-attachmentlist-background` and `-border` are LITERALS in Elastic's
colours.less (#fcfcfc / #f4f4f4) -- they derive from nothing the theme build
maps, so the per-declaration diff finds them identical in all twelve themes
and emits nothing. The strip stayed white on every dark theme, and the
attachment popup opening over it looked ringed in white. */
.attachmentslist {
background: var(--hover, #f5f5f8);
border-color: var(--line-2, #eee);
}
.attachmentslist .attachment-size {
color: var(--muted, #666);
}
/* ------------------------------------------------- 7b. framed documents ---
* Roundcube renders the reading pane, the contact card and every preferences
* section INSIDE an iframe. layout.html emits `` only when
* `!env:framed`, so in those documents there is no `#layout` at all and every
* `#layout …` rule in this file matches nothing.
*
* ⚠ That is not a cosmetic gap. Bootstrap's reboot puts `background:#fff` on
* body and `#212529` on `.form-control-plaintext`; Elastic's own colours come
* through the theme layer. Framed, the two halves disagreed -- themed text on
* an unthemed ground -- which is what made the preferences form unreadable in
* the dark themes. The frame has to be painted explicitly.
*/
html.iframe,
html.iframe body {
background: var(--panel, #fff);
color: var(--text, #222);
}
html.iframe .form-control,
html.iframe input.form-control,
html.iframe select.form-control,
html.iframe textarea.form-control {
border-radius: 8px;
border: 1px solid var(--line, #ddd);
background: var(--search-bg, var(--panel, #fff));
color: var(--text, #222);
font-size: 13.5px;
}
html.iframe .form-control:focus {
border-color: var(--accent, #4a3fbf);
box-shadow: none;
}
/* ⚠ `.form-control` IS PUT ON BY JAVASCRIPT, AND EVERY RULE ABOVE WAITS FOR IT.
Roundcube's PHP emits a bare `