margins to 0, so paragraphs in rendered/editable email bodies (AI-drafted replies, manual drafts, received messages) collapse with no visual gap between them even though the underlying HTML correctly uses separate
tags. Restore normal
paragraph spacing wherever we render that kind of rich-text body. */
.email-rich-body p { margin: 0 0 0.85em 0; }
.email-rich-body p:last-child { margin-bottom: 0; }
/* ------------------------------------------------------------------
Rich-text formatting toolbar (bindRichToolbar() in app.js), shared by
every contenteditable body in the app: Reply, Forward, the shared
Draft editor, Compose, AI-Assist preview, and Internal Notes. Reported
directly by a teammate ("i don't have any options like to edit text,
size of letters or bolt etc..") -- none of these bodies had a visible
formatting toolbar before, even though they were already contenteditable
under the hood.
------------------------------------------------------------------ */
.rich-tb-btn {
width: 26px; height: 26px;
display: flex; align-items: center; justify-content: center;
border-radius: 6px;
color: #475569;
font-size: 12px;
}
.rich-tb-btn:hover { background: #e2e8f0; color: #0f172a; }
.rich-tb-btn.is-active { background: #dbeafe; color: #1d4ed8; }
.rich-tb-sep { width: 1px; height: 16px; background: #e2e8f0; margin: 0 3px; flex-shrink: 0; }
.rich-tb-fontsize {
font-size: 11px; border: 1px solid #e2e8f0; border-radius: 6px; padding: 3px 4px;
background: #fff; color: #475569; outline: none;
}
/* The toolbar bar sits flush above its contenteditable body (one visually
combined box, like Gmail's own compose toolbar) -- the body only rounds
its BOTTOM corners since the toolbar already rounds the top ones. */
.rich-editor-body { border-top-left-radius: 0 !important; border-top-right-radius: 0 !important; }
/* Placeholder text for an EMPTY contenteditable body (the equivalent of a
plain 's placeholder attribute, which contenteditable divs don't
support natively). Matches when the element has no content at all, or
when its only content is the single stray
some browsers leave
behind after the last character is deleted. */
.rich-editor-body[data-placeholder]:empty::before,
.rich-editor-body[data-placeholder]:has(> br:only-child):before {
content: attr(data-placeholder);
color: #94a3b8;
pointer-events: none;
}
/* Attachment chip list (staged, not-yet-sent files on Reply/Forward/
Compose, or already-uploaded files on an existing shared Draft) --
deliberately smaller/plainer than the full Gmail-style attachment CARD
used for a message that's already been sent/received (renderAttachments
in app.js), since these are still just "about to be attached" pills. */
.attach-chip-remove { color: #94a3b8; }
.attach-chip-remove:hover { color: #475569; }
/* ------------------------------------------------------------------
Button responsiveness (2026-09-16): comfortable tap targets on both
touch and mouse input, plus a visible "pressed" state so every click
feels immediate/tactile instead of only ever showing a hover color.
Kept as plain CSS rather than per-button Tailwind classes so it applies
uniformly to every one of the app's ~230 buttons (existing and future)
without having to hand-edit each one's class list.
------------------------------------------------------------------ */
/* Real mice/trackpads report `hover: hover`; touchscreens report
`hover: none`. Only touch devices get the bumped-up minimum hit area --
desktop keeps each button's own intentional (often deliberately
compact/dense, e.g. Compact list view) sizing since a precise pointer
doesn't need the extra padding a fingertip does. Buttons that opt out
(kept at their exact intentional size regardless of input type -- e.g.
the density toggle's two side-by-side pills, where growing either one
would break the paired layout) carry `data-tap-exempt`. */
@media (hover: none) and (pointer: coarse) {
button:not([data-tap-exempt]) {
min-height: 36px;
min-width: 36px;
}
}
/* Every real button gets a pointer cursor and a quick, tactile "pressed"
feedback (slight scale-down) on click/tap -- previously the only
feedback most buttons gave was a hover color change, which a touch
device never triggers at all and which even on desktop only confirms
the cursor is over the button, not that a click actually registered.
Excludes disabled buttons (no interaction to acknowledge) and any
button explicitly opted out via [data-tap-exempt] (e.g. buttons that
already define their own custom press animation). `:active` naturally
only applies for the brief duration of the mouse-down/touch, so this
never conflicts with the (separate) sustained ".is-busy" loading state
set by withButtonBusy() in app.js. */
button:not(:disabled):not([data-tap-exempt]) {
cursor: pointer;
transition: transform .08s ease, opacity .08s ease, background-color .12s ease, color .12s ease;
}
button:not(:disabled):not([data-tap-exempt]):active {
transform: scale(0.96);
}
button:disabled {
cursor: not-allowed;
}
/* Loading state applied by withButtonBusy() (see app.js) while a button's
click handler has an in-flight API call -- dims the button and forces
the "not-allowed" cursor so it reads as busy/disabled even for the
split second before the `disabled` attribute itself is reflected in
some browsers' style recalculation. */
button.is-busy {
opacity: 0.7;
cursor: not-allowed !important;
transform: none !important;
}
/* A handful of row-level action buttons (folder tree's add-subfolder/edit/
delete icons) are only revealed via `opacity-0 group-hover:opacity-100`
-- fine with a mouse (hovering the row reveals them before you can even
click), but on a touchscreen there IS no hover state, so these stayed
permanently invisible and effectively untappable. Force them visible
whenever the device can't hover, matching the same (hover: none) check
used for the tap-target sizing above. */
@media (hover: none) and (pointer: coarse) {
.group .group-hover\:opacity-100 {
opacity: 1 !important;
}
}