@import './variables.css';
@import './layout.css';
@import './components.css';
@import './availability.css';
@import './modals.css';

*,
*::before,
*::after {
  box-sizing: border-box;
  margin: 0;
  padding: 0;
}

/* WKWebView (Tauri) paints native <select> with the macOS aqua "glass"
   vibrancy chrome; Chromium rendered them flat. Reset appearance on
   every select so they inherit the app's flat dark styling. */
select {
  -webkit-appearance: none;
  appearance: none;
}

/* Custom dropdown caret + room for it, shared by the app's styled selects.
   (.availability-timezone carries its own copy in availability.css.) The
   element-qualified selectors outrank each class's `background` shorthand so
   the caret image survives. */
select.account-input,
select.user-mgmt-role,
select.proposal-field {
  background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' width='8' height='5' viewBox='0 0 8 5'%3E%3Cpath fill='%23999999' d='M0 0h8L4 5z'/%3E%3C/svg%3E");
  background-repeat: no-repeat;
  background-position: right 8px center;
  padding-right: 22px;
}

html,
body,
#root {
  height: 100%;
  overflow: hidden;
}

body {
  background: var(--bg-app);
  color: var(--text-primary);
  font-family: var(--font-ui);
  font-size: 12px;
  -webkit-font-smoothing: antialiased;
  /* Nothing is text-selectable by default — chrome, buttons, labels, and the
     file trees should never highlight on a drag. WKWebView needs the -webkit-
     prefix here: without it, it ignores the rule and lets you drag-select the
     entire app (Chromium honored the unprefixed form, which is why
     this regressed after the Tauri switch). Genuine copyable content opts back
     in below. */
  -webkit-user-select: none;
  user-select: none;
}

/* Only real, copyable text is selectable. Because everything around these
   fields is unselectable, a drag can't bleed out of them into adjacent chrome
   (e.g. from a member's status into the next member's name). Inputs/textareas
   must stay selectable to work at all. */
input,
textarea,
.console-modules,
.col-description,
.member-status,
.availability-meeting-subject,
.availability-meeting-time,
.help-faq-answer,
.revision-modal-description,
.revision-file-path {
  -webkit-user-select: text;
  user-select: text;
}

/* Minimal pill scrollbars everywhere, via the -webkit-scrollbar pseudo-elements.
   Do NOT set the standard `scrollbar-width`/`scrollbar-color` here: modern
   WebKit (Tauri's WKWebView) supports those properties, and the moment
   `scrollbar-width` is set it renders the NATIVE thin scrollbar and IGNORES
   every ::-webkit-scrollbar rule below — which is the native bar that expands,
   chunky and off-theme, on hover. Chromium prioritized the
   pseudo-elements, so this only regressed after the Tauri switch. Leaving
   scrollbar-width at its default keeps the fully custom scrollbar in all three
   Tauri engines (WebKit, WebView2, WebKitGTK). */
*::-webkit-scrollbar {
  -webkit-appearance: none;
  width: 8px;
  height: 8px;
  background: transparent;
}

/* Style EVERY part transparent, not just the track. When you only scroll, WebKit
   shows the thumb alone (thin). But clicking/dragging the scrollbar renders the
   full legacy chrome — the track-piece (the run above/below the thumb) and the
   end buttons — and any part left unstyled defaults to a solid white bar in
   WKWebView. Painting them all transparent and hiding the buttons keeps the
   thin pill in every state. */
*::-webkit-scrollbar-track,
*::-webkit-scrollbar-track-piece,
*::-webkit-scrollbar-corner {
  background: transparent;
  background-color: transparent;
  box-shadow: none;
  border: none;
}

*::-webkit-scrollbar-button {
  display: none;
  width: 0;
  height: 0;
}

*::-webkit-scrollbar-thumb,
*::-webkit-scrollbar-thumb:hover,
*::-webkit-scrollbar-thumb:active,
*::-webkit-scrollbar-thumb:window-inactive {
  background-color: var(--outline);
  background-clip: content-box;
  border: 2px solid transparent;
  border-radius: 999px;
}

#app {
  display: flex;
  flex-direction: column;
  height: 100vh;
}
